1. OpenManus 的 Prompt 到底藏在哪从一次工具调用失败说起如果你最近在折腾 OpenManus大概率会遇到一个很迷惑的现象明明config.toml里模型名字填对了工具也注册上了可 agent 就是不肯调用浏览器工具或者规划模块给出的步骤里 agent 名字是空的。我一开始以为是模型能力问题换了好几个模型都一样后来把app/prompt/目录翻了一遍才明白OpenManus 的 Prompt 管理是「分散定义 运行时组装」的结构工具描述、系统提示、下一步提示分别来自不同地方任何一处没对齐模型看到的上下文就是残缺的。这篇就聚焦 OpenManus 工具调用与规划模块的 Prompt 管理机制把配置结构和调用链路拆开讲清楚然后给出可复制的config.toml骨架以及用 TaoToken 统一 Key 接入的完整实践。适合两类人一是想在本地复现 OpenManus 并搞懂它 Prompt 流向的开发者二是手里有多个模型渠道、想用一个统一 Key 打通所有请求的人。读完你应该能做到知道每个 Prompt 文件负责什么、知道to_param()生成的工具描述长什么样、知道规划模块三个阶段的 Prompt 分别在什么时候生成并且能自己发一条验证请求确认链路走通。2. 拆解 OpenManus 的 Prompt 管理机制2.1 工具 Prompt 的来源与组装链路OpenManus 把 Prompt 按 agent 和场景拆成了多个文件放在app/prompt/下。常见的有toolcall.py、mcp.py、manus.py、swe.py、planning.py、browser.py、visualization.py。每个文件里通常定义两个多行字符串SYSTEM_PROMPT和NEXT_STEP_PROMPT前者描述 agent 的身份和可用工具后者描述「下一步该干什么」的交互规则。以ToolCallAgent为例它在app/agent/toolcall.py里直接引用app/prompt/toolcall.py的这两个常量。到了think方法执行时system_prompt被塞进 system messagenext_step_prompt被塞进 user message再和历史消息、工具描述一起打包发给 LLM。这里有个容易忽略的点next_step_prompt是每轮都会重新拼进去的它不是一次性上下文而是持续影响模型决策的「方向盘」。工具描述则是另一条线。每个工具继承app/tool/base.py的BaseTool带有name、description、parameters三个属性。调用to_param()后工具会被转成标准 function 格式{ type: function, function: { name: self.name, description: self.description, parameters: self.parameters, } }这些 dict 会作为tools参数传给 LLM。最终在app/llm.py的LLM.ask_tool方法里system_msgs、messages、tools三部分被组装后一起发出。所以模型能不能正确调工具取决于三件事同时成立system prompt 说清楚了工具存在、to_param()生成的描述准确、历史消息里没有互相矛盾的指令。2.2 规划模块的三阶段 Prompt 生成时机规划模块在app/flow/planning.py它的 Prompt 不是静态常量而是分三个阶段动态生成。第一阶段是初始规划由_create_initial_plan负责。它先写死一段基础系统消息说明「你是一个规划助手创建简洁可执行的计划聚焦关键里程碑」。然后遍历self.executor_keys把每个可用 agent 的name和description收集成agents_description列表。如果 agent 数量大于 1就往系统消息里追加一段说明告诉模型「我们有这些 agent创建步骤时请用[agent_name]格式指定执行者」。用户消息则是把任务请求拼进去。第二阶段是步骤执行由_execute_step负责。它先调_get_plan_text()拿到当前计划状态再取出当前步骤文本拼成一段包含CURRENT PLAN STATUS和YOUR CURRENT TASK的 prompt明确要求「只执行当前这一步完成后给出总结」。这段 prompt 的关键在于它把计划状态实时注入模型每步看到的都是最新进度而不是一开始的静态计划。第三阶段是计划总结由_finalize_plan负责。系统消息变成「你的任务是总结已完成的计划」用户消息带上最终计划状态要求给出完成情况总结和最终想法。三个阶段对应三个时机用户输入任务时生成初始规划、每个步骤执行前生成执行 prompt、所有步骤完成后生成总结 prompt。配合PlanningTool的计划创建与状态管理、PlanStepStatus的步骤状态定义未开始、进行中、已完成、阻塞以及_generate_plan_text_from_storage的格式化输出整个规划系统才能做到动态调整、实时跟踪、多 agent 协作。3. TaoToken 前置统一 Key 与 config.toml 骨架搞清楚了 Prompt 流向接下来是接入层。OpenManus 默认走 OpenAI 兼容接口所以只要把base_url和api_key指向统一通道就行。TaoToken 提供的就是这样一个 OpenAI 兼容入口官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api 注意 API 地址不带 UTM 参数。先去控制台创建 Key入口是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite Key 管理页在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。拿到 Key 之后OpenManus 的config.toml骨架可以这样写[llm] model claude-sonnet-4-20250514 base_url https://taotoken.net/api api_key sk-你的TaoToken密钥 max_tokens 8192 temperature 0.0 [llm.vision] model claude-sonnet-4-20250514 base_url https://taotoken.net/api api_key sk-你的TaoToken密钥 [browser] headless false disable_security true这里有几个参数值得说明。temperature 0.0是因为工具调用和规划都要求稳定输出温度高了模型容易在[agent_name]格式上乱写。max_tokens给到 8192 是为了容纳规划模块注入的完整计划状态计划步骤多的时候上下文会明显变长。base_url末尾不要加/v1OpenManus 内部会自己拼路径加了反而会 404。如果你用的是 Claude 系列模型OpenManus 也支持 Anthropic 原生协议对应配置入口在 https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeutm_campaignrewrite 但大多数场景下 OpenAI 兼容模式已经够用。4. 可复制配置与验证请求4.1 环境准备与依赖安装先把仓库拉下来装依赖。Python 版本建议 3.11 以上低版本在异步工具调用上会有兼容问题。git clone https://github.com/FoundationAgents/OpenManus.git cd OpenManus python -m venv venv source venv/bin/activate pip install -r requirements.txt然后把上面那段config.toml放到项目根目录的config/下或者直接放根目录OpenManus 会按优先级查找。放好后确认一下文件权限别让 Key 被误提交到 git。4.2 验证请求是否走通最直接的验证方式是跑一个最小任务观察日志里模型请求是否成功返回。启动命令python main.py进入交互后输入一个简单任务比如「用浏览器打开 example.com 并告诉我页面标题」。如果链路走通你会在日志里看到类似这样的输出INFO LLM.ask_tool: sending request to https://taotoken.net/api/chat/completions INFO ToolCallAgent.think: system_prompt loaded from app/prompt/toolcall.py INFO ToolCallAgent.think: tools param count 5 INFO LLM.ask_tool: response received, finish_reason tool_calls重点看三行请求地址是不是指向taotoken.net/api、tools param count是不是大于 0、finish_reason是不是tool_calls。如果finish_reason是stop而不是tool_calls说明模型没打算调工具多半是 system prompt 或工具描述没对齐。另一个验证规划模块的方式是跑一个多步骤任务比如「先搜索 OpenManus 的 GitHub 仓库再总结它的目录结构」。观察日志里_create_initial_plan是否被调用、agents_description是否非空、步骤文本里有没有出现[MANUS]这类 agent 标记。如果 agent 标记是空的回去检查self.executor_keys和self.agents的注册逻辑。想单独验证模型对话是否正常可以直接用模型对话入口发一条测试消息https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 。如果那边能正常返回说明 Key 和通道没问题问题就出在 OpenManus 的 Prompt 组装上。5. 本篇常见错排查5.1 工具调用返回 401 或 403先确认api_key有没有多余空格TOML 里字符串不会自动 trim。再确认base_url是不是写成了https://taotoken.net/api/v1多出来的/v1会导致路径拼接错误。如果都正常去 Key 管理页确认这个 Key 有没有被禁用或额度耗尽。5.2 模型不调用工具只输出文本这是最常见的 Prompt 对齐问题。检查app/prompt/toolcall.py里的SYSTEM_PROMPT有没有被改动过特别是工具列表部分。如果工具描述里description写得太模糊模型会倾向于不调用。另外确认to_param()返回的parameters是合法的 JSON Schema字段类型写错会导致模型无法解析。5.3 规划步骤里 agent 名字为空回到_create_initial_plan看agents_description的收集逻辑。如果self.executor_keys是空的说明 agent 没注册上。检查app/flow/planning.py里 executor 的初始化顺序确保在创建计划之前 agent 已经注册完毕。还有一种情况是 agent 数量等于 1此时代码不会追加 agent 说明这是设计如此不是 bug。5.4 请求超时或响应截断max_tokens设太小会导致规划模块的长上下文被截断模型输出到一半就停了。把max_tokens提到 8192 或更高。如果还是超时检查网络到taotoken.net的连通性可以用curl直接打一下 API 端点确认延迟。curl -X POST https://taotoken.net/api/chat/completions \ -H Authorization: Bearer sk-你的TaoToken密钥 \ -H Content-Type: application/json \ -d {model:claude-sonnet-4-20250514,messages:[{role:user,content:ping}]}如果这条 curl 能返回正常 JSON说明通道没问题问题在 OpenManus 内部。6. 长期编码与 Agent 场景的接入建议如果你只是偶尔跑一下 OpenManus 验证 Prompt 机制按上面的配置就够了。但如果你打算把 OpenManus 当成日常的编码或 Agent 工具长期用建议走 Coding Plan 通道入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 它在长会话和工具调用密集场景下的稳定性更好。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有各语言的完整示例。最后说一个我踩过的坑OpenManus 的 Prompt 文件是纯字符串没有模板引擎所以任何动态内容都得靠代码拼接。改 Prompt 的时候别直接改字符串常量尽量在调用处拼否则多个 agent 共用同一个常量时会互相污染。规划模块的_execute_step就是正确示范它把动态的计划状态拼在调用处而不是塞进planning.py的常量里。