# 探索 Manus 交付业务需求的新范式：OneAgent + MCPs 实战教程 本文将带你从零开始，理解如何用 **OneAgent + MCPs** 模式快速构建单领域智能体（Agent），让复杂业务需求在分钟级内自动交付。无论你是技术开发还是业务专家，都能从中找到清晰的落地路径。 --- ## 一、Agent 发展简史：从简单调用到智能协作 ### 1. 单一 LLM 调用 最初，LLM 被当作一个“文本万能接口”，用于完成摘要、分类、翻译等单一任务。虽然交互简单，但这是当前所有 AI 系统的基础。 ### 2. Workflow LLM 编排 当任务变复杂后，单一 LLM 不够用，于是出现了 **Workflows** 模式：通过编排多个预定义的 LLM 调用（或工具调用）来执行一系列步骤。核心是**拆解大任务为子任务**，按预设逻辑顺序执行。例如： ``` 意图识别 → 资料收集 → 阶段资料分析 → 汇总资料分析 → 报告产出 ``` 这相当于利用 LLM 增强或自动化传统 SOP（标准作业流程），达到类似 RPA 的效果。但缺点也很明显：每个业务场景都需要重新搭建 Workflow，难以覆盖大量长尾场景。 ### 3. Multi-Agent 系统 随后，Workflow 节点中的简单 LLM 调用升级为 **Agent 调用**，形成了多智能体系统（Multi-Agent）。lilianweng 提出了 Agent 的核心概念： 与此同时，多智能体框架（如 AutoGen、Crew AI、LangGraph、AgentUniverse）蓬勃发展。但实践中，Agent 的表现受限于模型能力（如缺乏 COT、few-shot）且稳定性不足。 Antropic 的 Barry Zhang 则提出了更简洁的 Agent 定义：**在循环（Loop）中使用工具的模型**。代码抽象如下： ```python env = Environment() tools = Tools(env) system_prompt = "Goals, constraints, and how to act" user_prompt = get_user_prompt() while True: action = llm.run(system_prompt + user_prompt + env.state) env.state = tools.run(action) ``` 这其实是 ReAct 框架的变体，我们称之为 **Loop 框架**。 ### 4. OneAgent + MCPs – 新范式诞生 从泄露的 Manus 源码来看，Manus 是 Loop 框架的典型代表： ```xml You are Manus, an AI agent created by the Manus team. ... You are operating in an agent loop, iteratively completing tasks through these steps: 1. Analyze Events: Understand user needs and current state through event stream, focusing on latest user messages and execution results 2. Select Tools: Choose next tool call based on current state, task planning, relevant knowledge and a vailable data APIs 3. Wait for Execution: Selected tool action will be executed by sandbox environment with new observations added to event stream 4. Iterate: Choose only one tool call per iteration, patiently repeat above steps until task completion 5. Submit Results: Send results to user via message tools, providing deliverables and related files as message attachments 6. Enter Standby: Enter idle state when all tasks are completed or user explicitly requests to stop, and wait for new tasks ``` Manus 因此被称为“世界上第一个通用智能体”。AI Coding 插件 Cline 也采用类似的 Loop 框架。 这启发了我们：**如果将 Manus 和 Cline 的开发范式在企业内部落地**，并将 Manus 的 29 个 function 换成企业内部领域内的 MCP Server，那么企业内部也能拥有“通用智能体”，可以完成风控策略部署、保险产品精算、营销方案策划等业务需求。而这正是 **OneAgent + MCPs 范式**。 > **小提示**：OneAgent + MCPs 的目标不是创造全能的 God Agent，而是**基于一个强大的基础 Agent 派生领域 Agent**，结合知识类 MCP / Planner 来落地。 --- ## 二、OneAgent + MCPs 范式核心架构 ### 1. OneAgent 的定义 OneAgent 是每个闭环领域内的一种 Agent 智能落地实践。各个领域或组织涌现出自己的 Agent 后，可以进一步通过 A2A（Agent-to-Agent）协议实现跨领域协作。 ### 2. OneAgent + MCPs 的组成部分 从第一性原理出发：人类接到任务后，会思考用什么工具、制定计划、请教专家。基于此，OneAgent 系统需要以下组件： | 组件 | 说明 | |------|------| | **OneAgent 本体** | Web 端的 MCP Client | | **分身（Profile）** | 每个领域/特殊任务的自定义 Agent，经过调教的提示词 + 自带 MCP | | **MCPBridge** | 将存量 HTTP / TR / HSF 服务桥接为 MCP Server | | **MCP0** | 推荐 MCP 的 MCP（第一个使用的 MCP） | | **MCP-Registry** | 注册与展示 MCP 的注册中心 | | **KnowledgeMCP** | 领域知识 MCP，补充 LLM 预训练知识的盲区 | #### 新建 OneAgent 分身过程示例： > **常见问题**：MCP0 和 KnowledgeMCP 有什么区别？ > **回答**：MCP0 负责**推荐与安装其他 MCP**，当 OneAgent 发现现有 MCP 不满足需求时，会调用 MCP0 来发现新 MCP。KnowledgeMCP 则提供**领域知识**，当 OneAgent 遇到知识盲区（如精算定价规则）时，会请教 KnowledgeMCP 获取专业指导。 ### 3. Planner 模块 Manus 中关键的 Planner 模块，对应人类的分层规划。例如你去仙本那旅游：子目标“去机场” → 子子目标“打车去机场” → “乘电梯下楼” → “站起来开门”。当子目标足够简单，就不需要再规划。Planner 模块可以用后训练的小模型替代 KnowledgeMCP，但本文暂不深入。 ### 4. OneAgent + MCPs 执行流程 经典执行步骤如下： 1. OneAgent 的子 Agent 执行任务时，先尝试自己理解语义，规划 to-do； 2. 发现知识盲区时，询问 KnowledgeMCP，更新 to-do； 3. 基于 to-do 结合已知 MCP Server 不断循环（Loop）； 4. 根据 MCP Server 返回信息，不断更新 to-do 或推进进度； 5. 当已知 MCP Server 不满足时，调用 MCP0 推荐新 MCP； 6. 持续 Loop，直到任务完成或被用户取消。 流程示意图： --- ## 三、实战案例：OneAgent + 精算 MCPs 实现自动化定价方案 以保险精算为例，OneAgent 只需几分钟就能交付精算定价方案。 1. **理解需求**：为定价方案寻找纯风险保费小于 100 的属性组合。 2. **请教 KnowledgeMCP**：获取精算业务知识补充和初步规划。 3. **规划 to-do**：OneAgent 思考后生成详细计划。 4. **调用精算 MCP**：按 to-do 调用相关 MCP。 5. **记录更新**：收到 MCP 回复后记录必要信息，更新 to-do。 6. **交付结果**：完成所有 to-do，输出定价方案。 > **小提示**：OneAgent 的 to-do 质量直接决定最终效果。好的 to-do 应像说明书一样清晰：目标明确、接口先行、功能详述、上下文给足、结构清晰。 --- ## 四、OneAgent + MCPs 实现细节 ### 1. MCP Server 封装原则 MCP 不仅是 Function Call 的标准化封装，更应该是**多个原子能力的服务包装（SAAS）**。例如，对一个实体对象的 CRUD 操作，不应单纯暴露 CRUD 接口，而应暴露能完成简单闭环业务操作的组合接口。这样可以避免 Tool 不断膨胀，并维护领域内能力。 MCP 本身也可以封装 Agent，Agent 之间也可以交互。这标志着从 **Software-as-a-Service** 向 **Service-as-a-Software** 的转变。 ### 2. Loop 框架与 to-do 管理 Loop 框架核心即 Barry Zhang 的抽象。而 to-do 是长流程 LLM 执行不偏离任务的关键。生成 to-do 应遵循： - **目标明确**：产品目标、核心功能、用户场景说清楚。 - **接口先行**：先定义接口、数据结构、表 Schema。 - **功能详述**：用大白话描述每个功能点，无歧义。 - **上下文给足**：引用相关代码文件路径、UI 库、现有模式、设计图链接。 - **结构清晰**：用 Markdown 标题、列表方便机器解析。 to-do 的更新维护规则（来自 Manus 的 todo_rules）： ```xml - Create todo.md file as checklist based on task planning from the Planner module - Task planning takes precedence over todo.md, while todo.md contains more details - Update markers in todo.md via text replacement tool immediately after completing each item - Rebuild todo.md when task planning changes significantly - Must use todo.md to record and update progress for information gathering task - When all planned steps are complete, verify todo.md completion and remove skipped items ``` ### 3. MCP Server 调用 Prompt OneAgent 在会话发起时默认加载 MCP0、KnowledgeMCP 等。system prompt 中需包含 MCP 调用规则，例如： ```json { "mcpRules": { "mcpUse": { "servers": ["MCP推荐、发现与安装"], "description": "如果你不确定当前 MCP 是否合适，请求推荐MCP的MCP" }, "knowledgeGet": { "servers": ["xxx知识获取 MCP"], "description": "如果你不完全清楚用户意图，将完整用户问题请教Knowldge MCP" } }, "defaultBeha vior": { "priorityOrder": ["mcpUse", "knowledgeGet"], "fallbackBeha vior": "提示没有找到合适的 MCP,请求用户帮助" } } ``` > **常见问题**：为什么需要区分 domain terms？ > **回答**：不同领域（如风控、精算、营销）的 MCP 可能同名但含义不同。OneAgent 必须严格隔离领域，防止跨领域调用导致错误。 --- ## 五、当前实践：保险科技团队落地案例 保险科技团队通过 OneAgent + MCPs 方案加速 Agent 应用。当前链路组件： - **mcp-registry**：承栽 MCP 元数据，结合 MCP Bridge 转化 HTTP 和内部 RPC（TR/HSF）接口为 MCP。 - **mcpbridge**：将存量 HTTP REST 接口转化为 MCP Server。 - **mcp0**：推荐与安装 MCP，基于标签匹配和 HNSW 向量索引实现推荐逻辑。MCP 描述越丰富正确，推荐效果越好。长期可引入监督微调的小模型优化。 Web 端 MCP Client 上的 OneAgent 分身示例： --- ## 六、当前不足与发展方向 ### 当前不足 1. **to-do 质量的强依赖性**：高质量 to-do 需要经验丰富的人工注入到 KnowledgeMCP，限制了自主性和扩展性。 2. **MCP 管理与交互挑战**： - **错误传递与累积**：单个 MCP 失败可能影响最终结果，尤其在长链条调用中。 - **上下文传递困境**：信息过少或过多都会影响 MCP 理解。 - **MCP 发现与选择局限性**：注册信息不完善或推荐算法不智能会导致找不到最优 MCP。 3. **状态管理与鲁棒性**： - **状态管理复杂**：全局任务状态维护困难，尤其在异步嵌套时。 - **死循环风险**：LLM 理解偏差可能导致无效循环。 - **任务中断与恢复缺失**：缺乏优雅的中断恢复机制。 4. **知识整合与运用深度**：KnowledgeMCP 的知识覆盖度、时效性和检索效率是持续挑战。 ### 发展方向 1. **构建标准化 MCP/Agent 交互生态**：推动 MCP 接口标准化（能力描述、输入输出、错误码），实现即插即用和互操作性。 2. **提升鲁棒性、弹性和可观测性**：精细化错误处理、任务持久化与可恢复工作流、增强日志追踪。 3. **优化 MCP 调用与管理**：异步并发调用、智能上下文管理、MCP 性能与成本感知。 4. **系统智能提升**： - **强化学习（RL）应用**：优化 MCP 选择、参数调整、任务序列规划。 - **知识库动态构建与更新**：OneAgent 将新学到的知识反馈给 KnowledgeMCP，实现持续进化。 > **小提示**：正如 Richard S. Sutton 在《苦涩的教训》中指出的，长期来看，依靠计算（搜索和学习）而非人工注入知识才是突破的关键。因此，OneAgent + MCPs 的未来方向是让 Agent 通过 RL 从环境中自主探索和学习。 --- ## 七、Agent 系统智能提升：强化学习与 MCP 调用 ### 1. 什么是强化学习（RL）？ 强化学习是三种主要机器学习范式之一。与监督学习（给出正确答案）和自监督学习（预测文本内部依赖）不同，强化学习中系统不知道正确答案，只得到“好或坏”的反馈，类似于人类学骑自行车。 ### 2. 强化学习如何应用于 Agent？ 通过**强化微调（Reinforcement Fine-Tuning, RFT）**，可以教会模型将 MCP 作为推理链的一部分来使用。这与 Loop 框架的区别在于：Loop 是“指示模型按 to-do 使用 MCP”，而 RFT 是“教模型自己学会如何用 MCP”。 ### 3. 如何做强化微调？以 ReSearch 框架为例 ReSearch 基于 GRPO 算法，通过采样多个推理链（rollouts），优化模型生成更高奖励的推理链。 - 模型先生成思考过程（``），然后决定是否需要搜索（``），搜索结果（``）反馈给模型继续推理。 - 例如，回答“《国富论》出版那年中国皇帝是谁？”： ```xml 我需要先确定《国富论》的出版年份。 国富论出版年份 《国富论》由亚当·斯密于1776年出版。 现在需要查找1776年对应的中国皇帝。 1776年清朝皇帝 1776年是清朝乾隆四十一年，当时在位的皇帝是乾隆帝（爱新觉罗·弘历）。 答案是\boxed{乾隆帝（Qianlong Emperor）}。 ``` - 奖励信号分两部分： - **答案奖励**：通过 F1 分数计算最终答案正确性。 - **格式奖励**：检查推理链是否符合预定义格式。 > **常见问题**：强化微调需要大量数据和计算资源，如何在小规模业务中应用？ > **回答**：可以先从关键领域（如精算、风控）的小数据集开始，利用 RLVR（Reinforcement Learning from Verifiable Rewards）算法，通过真实环境反馈让模型自我学习，减少对人类标注数据的依赖。 --- ## 八、展望：未来之路 OneAgent + MCPs 不是 God Agent。它致力于**快速落地领域 Agent**，基于一个“基类”快速搭建，让业务人员也能通过 prompt 编排完成长尾任务，而不是每个场景都手工编排 Workflow。随着 MCP 生态成熟、RL 技术进步，Agent 将真正成为我们工作中的同事。 围绕本文提到的不足与发展方向，我们仍在持续探索。期待你的参与和实践！