1. 从 Manus 到 OpenManusAgent 任务分解到底难在哪Manus 这类通用 Agent 产品最让人上头的地方不是它能聊天而是它真的会“动手”——自己规划步骤、自己调工具、自己看报错、自己改方案最后把一份完整结果甩到你面前。很多人第一次体验完的第一反应是这不就是个套壳的聊天机器人吗但真去拆它的执行日志就会发现背后是一套相当克制的 Prompt 编排 任务分解机制在撑着。我自己在复刻 OpenManus 的过程中踩过最大的坑不是模型不够聪明而是 Prompt 没把“规划-执行-反思”这个循环讲清楚。模型要么一口气把二十步全规划完然后卡在第三步要么每步都重新规划导致上下文爆炸。Manus 的聪明之处在于它做了两层规划粗粒度全局规划 增量式细粒度拆解。这个设计思路在 OpenManus 的源码里能找到影子也是本文要重点拆解的部分。这篇文章面向三类人想搞懂 Agent 调度逻辑的开发者、想自己搭一个类 Manus 工作流的工程师、以及被各种 Agent 框架绕晕想找个能跑通的最小实现的人。我会用 OpenManus 作为复刻对象把 Prompt 模板、配置骨架、本地验证步骤全部给出来你跟着敲就能跑起来。核心检索词就三个Manus 技术实现原理、OpenManus Prompt 编排、ReAct Agent 任务分解。先说结论Manus 类 Agent 的本质是一个带工具调用能力的 ReAct 循环外面套了一层任务规划器。规划器负责把用户的一句话需求拆成可执行的步骤列表ReAct 循环负责逐步执行并在每步之后做反思。难点不在模型在于怎么用 Prompt 把“什么时候该规划、什么时候该执行、什么时候该反思”这三件事的边界划清楚。2. TaoToken 前置准备给 Agent 循环接一个稳定的模型入口在动手写 Agent 之前得先解决模型调用的问题。OpenManus 默认走的是 OpenAI 兼容接口你需要一个能稳定提供 function calling 能力的模型端点。我实测下来用 TaoToken 的 API 接入是最省事的路径因为它直接兼容 OpenAI 的请求格式OpenManus 的 config.toml 里改个 base_url 就能用。TaoToken 在这里扮演的角色是模型网关——它把不同厂商的模型统一成 OpenAI 兼容接口你的 Agent 代码不需要为每个模型写适配层。对于 Agent 场景来说这点很关键因为 ReAct 循环对 function calling 的格式要求很严格如果每个模型返回的 tool_calls 结构不一样你的解析代码会写到崩溃。你需要准备三样东西一个 API Key、一个 Base URL、一个支持 function calling 的 Model ID。API Key 在控制台的 API Keys 页面创建Base URL 固定是https://taotoken.net/apiModel ID 根据你的场景选——做 Agent 循环建议选指令遵循能力强的模型因为 ReAct 对格式的容错率很低。这里有个细节要注意OpenManus 的配置文件里 base_url 的写法有坑。如果你直接填https://taotoken.net/api有些版本的 OpenAI SDK 会自动拼接/chat/completions但有些版本不会。稳妥的写法是填https://taotoken.net/api/v1这样无论 SDK 怎么拼都能命中正确的端点。这个坑我踩过报错是 404 Not Found排查了半天才发现是路径拼接问题。另外Agent 场景的 token 消耗比普通对话大得多。一个五步的任务每步都要把完整的对话历史 工具定义 系统提示词重新发一遍实际消耗可能是普通对话的 10 到 20 倍。所以选模型的时候不要一上来就用最贵的先用便宜模型把流程跑通确认 Prompt 编排没问题了再换强模型。TaoToken 的 Coding Plan 适合这种需要反复调试 Agent 循环的场景因为调试阶段请求量大但单次消耗小。3. 可复制的 Agent 配置骨架与 Prompt 模板这一节是全文的核心我会把 OpenManus 的配置骨架和 Prompt 模板完整拆开讲。先给配置文件再给 Prompt最后解释每个部分为什么这么设计。3.1 config.toml 配置骨架OpenManus 的配置文件在config/config.toml你需要改的是 llm 部分。下面是我实测能跑通的配置[llm] model your-model-id base_url https://taotoken.net/api/v1 api_key sk-your-api-key max_tokens 4096 temperature 0.0 api_type openai api_version [llm.model_config] function_calling truetemperature 设成 0.0 是关键。Agent 循环需要确定性输出如果模型每次返回的 tool_calls 格式都不一样你的解析逻辑会疯掉。max_tokens 设 4096 是因为 Agent 的单步输出可能包含较长的思考过程 工具调用参数设太小会被截断导致 JSON 解析失败。3.2 系统提示词模板OpenManus 的 SYSTEM_PROMPT 比较简洁但真正驱动 Agent 循环的是 NEXT_STEP_PROMPT。我把这两个 Prompt 拆开分析并给出一个增强版的模板。系统提示词负责定义 Agent 的身份和能力边界SYSTEM_PROMPT You are OpenManus, an all-capable AI assistant, aimed at solving any task presented by the user. You have various tools at your disposal that you can call upon to efficiently complete complex requests. Whether its programming, information retrieval, file processing, or web browsing, you can handle it all.这个 Prompt 很短但信息密度不低。它做了三件事定义身份OpenManus、声明能力范围编程/检索/文件/浏览、暗示工具调用at your disposal。注意它没有说“你必须一步步来”或者“先规划再执行”这些约束放在 NEXT_STEP_PROMPT 里。NEXT_STEP_PROMPT 才是驱动循环的核心NEXT_STEP_PROMPT You can interact with the computer using PythonExecute, save important content and information files through FileSaver, open browsers with BrowserUseTool, and retrieve information using GoogleSearch. PythonExecute: Execute Python code to interact with the computer system, data processing, automation tasks, etc. FileSaver: Save files locally, such as txt, py, html, etc. BrowserUseTool: Open, browse, and use web browsers. If you open a local HTML file, you must provide the absolute path to the file. GoogleSearch: Perform web information retrieval Based on user needs, proactively select the most appropriate tool or combination of tools. For complex tasks, you can break down the problem and use different tools step by step to solve it. After using each tool, clearly explain the execution results and suggest the next steps.这段 Prompt 的设计逻辑值得细品。它先列出所有可用工具及其描述然后给出行为指令主动选择工具、复杂任务分步解决、每次工具调用后解释结果并建议下一步。最后一句“suggest the next steps”是驱动循环的关键——它让模型在每次执行后主动思考下一步而不是等外部调度器来问。3.3 规划提示词模板如果你想要 Manus 那种“先出全局计划再执行”的效果需要额外加一个 Planning Prompt。MetaGPT 的 Planning 模块给了一个很好的参考PLANNING_SYSTEM_PROMPT You are an expert Planning Agent tasked with solving problems efficiently through structured plans. Your job is: 1. Analyze requests to understand the task scope 2. Create a clear, actionable plan that makes meaningful progress with the planning tool 3. Execute steps using available tools as needed 4. Track progress and adapt plans when necessary 5. Use finish to conclude immediately when the task is complete Available tools will vary by task but may include: - planning: Create, update, and track plans (commands: create, update, mark_step, etc.) - finish: End the task when complete Break tasks into logical steps with clear outcomes. Avoid excessive detail or sub-steps. Think about dependencies and verification methods. Know when to conclude - dont continue thinking once objectives are met.这个 Prompt 的精髓在于它把“规划”本身也变成了一个工具。模型通过调用planning工具来创建和更新计划而不是在自然语言里描述计划。这样做的好处是计划结构化了可以被程序解析和展示也方便后续的进度追踪。3.4 工具定义与 function calling 配置Agent 能调什么工具取决于你在请求里传了哪些 function 定义。OpenManus 的工具定义在app/tool/目录下每个工具是一个类需要实现name、description、parameters三个属性。下面是一个最小化的工具定义示例class PythonExecute(BaseTool): name: str python_execute description: str Execute Python code to interact with the computer system, data processing, automation tasks, etc. parameters: dict { type: object, properties: { code: { type: string, description: The Python code to execute. } }, required: [code] }这个定义会被转成 OpenAI 的 function calling 格式随请求一起发给模型。模型返回的 tool_calls 里会包含工具名和参数你的 Agent 循环负责解析并执行。4. 本地运行验证从零跑通一个 DNS 诊断 Agent配置和 Prompt 都准备好了现在来验证。我用一个真实的场景来测试让 Agent 诊断一个邮箱域名的 MX、TXT、CNAME 解析是否有问题。这个任务的好处是它需要多步执行、需要根据中间结果调整策略、而且结果可验证。4.1 环境准备先把 OpenManus 拉下来git clone https://github.com/mannaandpoem/OpenManus.git cd OpenManus pip install -r requirements.txt然后把上面写的 config.toml 放到config/目录下。注意 OpenManus 默认会读config/config.toml如果你放在别的地方需要改环境变量。4.2 运行 Agent启动命令很简单python main.py然后在交互界面输入任务这个 testcasealiyun.com 邮箱无法收发信请帮我实际诊断一下这个邮箱域名的 MX 解析、TXT 解析、CNAME 解析是否有问题4.3 观察执行日志Agent 启动后会进入 ReAct 循环。你会看到类似这样的对话日志{ role: assistant, content: 要诊断一个邮箱域名的MX解析、TXT解析和CNAME解析是否有问题我们可以通过执行DNS查询来获取相关信息。我们可以使用Python中的dns.resolver模块来执行这些查询。, tool_calls: [ { id: call_362e5954bc614652b98971, type: function, function: { name: python_execute, arguments: {\code\:\import dns.resolver\\n\\ndef query_dns_records(domain, record_type):\\n try:\\n answers dns.resolver.resolve(domain, record_type)\\n records [str(rdata) for rdata in answers]\\n return records\\n except Exception as e:\\n return str(e)\\n\\ndomain \\\aliyun.com\\\\\nmx_records query_dns_records(domain, MX)\\ntxt_records query_dns_records(domain, TXT)\\ncname_records query_dns_records(domain, CNAME)\\n\\nprint(\\\MX Records:\\\, mx_records)\\nprint(\\\TXT Records:\\\, txt_records)\\nprint(\\\CNAME Records:\\\, cname_records)\} } } ] }注意模型选择用 PythonExecute 而不是直接调 DNS 工具因为 OpenManus 默认没有提供 DNS 查询工具。这恰好展示了 Agent 的灵活性——它会用现有工具组合出解决方案。4.4 验证结果工具执行后你会看到返回的 DNS 记录MX Records: [10 mx2.mail.aliyun.com.] TXT Records: [kqpmfrf0schjrfhv52j66tgl1dn2pb01, _globalsign-domain-verificationRslTn-OhDMh5TgCw7-aKKz3IY25h2UwWfwG0TbplyM, vspf1 ip4:115.124.30.0/24 ip4:121.0.18.0/23 ip4:121.0.30.0/24 ip4:42.120.70.0/23 ip4:47.88.44.32/27 ip4:59.82.0.0/23 ip4:47.90.199.0/24 -all, google-site-verificationzEkDfQfI5fc3VhAFyUCbLxv2vCyoo4wJjiLgfV-UG8k] CNAME Records: The DNS response does not contain an answer to the question: aliyun.com. IN CNAME然后模型会基于这些结果给出分析根据DNS查询的结果我们可以看到以下信息 MX记录存在指向mx2.mail.aliyun.com所以从DNS解析的角度来看邮箱服务器配置正确。 存在多个TXT记录包括SPF记录这表明域名所有者已经采取措施来保护其域名不被滥用发送垃圾邮件。 没有找到CNAME记录这说明aliyun.com没有被设置为其他域名的别名。 如果testcasealiyun.com邮箱仍然无法收发信那么问题可能不在DNS记录上而是可能与邮件服务器配置、网络连接性、防火墙规则、或者邮箱账户本身的设置有关。到这里一个完整的 ReAct 循环就跑通了分析任务 → 选择工具 → 执行 → 观察结果 → 给出结论。整个过程没有人工干预模型自主完成了任务分解和工具调用。4.5 加上规划层如果你想要 Manus 那种先出全局计划的效果可以在系统提示词里加上 Planning Prompt并注册一个 planning 工具。这样模型在开始执行前会先调用 planning 工具创建一个步骤列表然后逐步执行并更新进度。这个改造不难但会让 Agent 的行为更接近 Manus 的体验。5. 常见报错排查401、local proxy failed 与 choices 解析失败Agent 跑不起来的时候报错信息往往很模糊。我把复刻过程中遇到的高频错误整理出来对照着排查能省不少时间。5.1 401 Unauthorized这是最常见的错误原因通常是 API Key 没配对。检查三个地方config.toml 里的 api_key 是否填了完整的 key有些平台需要加sk-前缀、base_url 是否写成了https://taotoken.net/api/v1、以及你的 key 是否有权限访问你选的 model。如果三个都确认没问题还是 401可能是 key 被禁用或者额度用完了。去控制台看一眼 key 的状态和余额。5.2 local proxy failed / Connection error这个报错通常出现在 base_url 配置错误的时候。OpenManus 底层用的是 OpenAI SDK如果你填的 base_url 少了/v1或者多了路径SDK 会尝试连接一个不存在的端点报错信息可能是 connection refused 或者 local proxy failed。正确的 base_url 是https://taotoken.net/api/v1。注意末尾不要加/chat/completionsSDK 会自己拼。5.3 Error parsing choices / JSONDecodeError这个报错说明模型返回的内容不是合法的 JSON导致解析 tool_calls 失败。原因通常有三个模型的 function calling 能力不支持或者不稳定、temperature 设太高导致输出格式漂移、max_tokens 太小导致 JSON 被截断。排查顺序先把 temperature 设成 0.0再把 max_tokens 调到 4096 以上如果还报错就换一个 function calling 能力更强的模型。有些模型虽然支持 function calling但在多轮对话中格式会漂移这种就不适合做 Agent 循环。5.4 OAuth / authentication 相关报错如果你用的是某些需要 OAuth 认证的模型端点可能会遇到 token 过期或者 scope 不足的问题。TaoToken 的 API Key 认证方式不存在这个问题因为它是静态 key不需要刷新 token。如果你在别的地方遇到 OAuth 报错检查一下 token 的有效期和权限范围。5.5 工具调用死循环Agent 反复调用同一个工具、每次都返回相同结果、然后继续调用——这是 Prompt 编排的问题。通常是 NEXT_STEP_PROMPT 里没有明确告诉模型“如果结果没有变化就换策略”。解决办法是在 Prompt 里加一句如果连续两次工具调用返回相同结果停止当前策略并尝试替代方案。5.6 三件套检查清单遇到任何连接问题先检查这三样Base URL 是否是https://taotoken.net/api/v1、API Key 是否完整且有效、Model ID 是否支持 function calling。这三样确认无误后再去看 Prompt 和代码逻辑。6. 把 Agent 循环接到你的业务里跑通最小复刻只是第一步真正有价值的是把这套机制用到实际业务场景里。Manus 类 Agent 最适合的场景有两个特征任务需要多步探索、单次执行不需要人工介入。比如技术客服场景下的复杂问题诊断、数据采集与报告生成、代码仓库的自动化审查。接入的时候有几个工程上的点要注意。第一是沙箱隔离Agent 执行的命令和代码必须在隔离环境里跑不能直接操作生产系统。OpenManus 默认用本地环境执行生产环境需要换成容器沙箱。第二是超时控制Agent 循环可能跑很久需要设置单步超时和总超时避免卡死。第三是结果校验Agent 的输出不一定可靠关键决策点需要人工确认或者加校验逻辑。如果你想把 Agent 循环接到自己的应用里最直接的方式是用 TaoToken 的 API 做模型调用层然后在你的业务代码里实现 ReAct 循环。核心逻辑就是一个 while 循环调模型 → 解析 tool_calls → 执行工具 → 把结果塞回对话历史 → 继续调模型直到模型返回 finish 或者达到最大步数。调试阶段建议用模型对话页面手动测试 Prompt 效果确认模型能稳定返回正确的 tool_calls 格式后再接入代码。长期跑 Agent 任务的话Coding Plan 的额度模型更适合这种高频调用的场景。接入文档里有完整的 API 参数说明和示例代码照着改就能用。最后说一个我踩过的坑不要一上来就追求 Manus 那种 29 个工具的完整形态。先用 3 到 4 个核心工具命令执行、文件读写、搜索、浏览把循环跑通确认 Prompt 编排没问题了再逐步加工具。工具越多模型选择困难症越严重反而容易在简单任务上绕弯路。