Appearance
56. 如何设计类 Manus 通用智能体？
难度 P0 必背 · 岗位 应用 · 频率 ★★★ · 预计阅读 5 min
👔面试官：如何设计类 Manus 通用智能体？
🙋♂️我：能调用各种工具，完成复杂任务。
👔面试官：太笼统。回到 Agent 最小骨架：模型+工具集+运行循环+当前状态。类 Manus 是把这四层扩展到长任务链和复杂任务空间。需要任务理解、工具调度、状态记忆、执行反思、安全治理。你能展开吗？
TL;DR 速记
- 是什么：类 Manus 通用智能体是面向长任务的 Agent 系统，不只是“工具更多”。
- 关键点：核心是任务规划、工具调度、状态记忆、执行反思和安全治理。
- 怎么答：强调长期推进任务、管理复杂状态、失败恢复和可观测，而不是只列工具清单。
图解
类 Manus 长任务循环
💡 简要回答
五模块设计：
| 模块 | 职责 |
|---|---|
| 任务理解与规划 | 把目标拆成可执行步骤 |
| 工具调度 | 统一接搜索、浏览器、代码执行、文件系统 |
| 状态与记忆 | 维护任务上下文、待办、阶段成果 |
| 执行与反思 | 根据中间结果继续执行、修正或重试 |
| 安全与治理 | 权限控制、日志、失败恢复、人工接管 |
核心区别：不是"工具更多"，是需要长期推进任务、管理复杂状态、维持长链路稳定性。
常见踩坑与反例
- 踩坑 1：把类 Manus 等同于“接很多工具”。工具只是手脚，真正难点是长任务规划和状态推进。
- 踩坑 2：没有任务状态模型。只靠上下文文本记进度，任务一长就漂移；应有待办、阶段产物、完成条件和检查点。
- 踩坑 3：缺少失败恢复。长链路里工具失败很常见，要支持重试、换策略、降级和人工接管。
- 踩坑 4：权限边界太宽。浏览器、文件、代码执行等工具必须最小授权，关键动作要确认。
- 踩坑 5：不可观测。没有轨迹、日志和中间产物，出错后无法复盘，也很难调优。
面试官可能继续追问
- 追问 1：怎么避免长任务跑偏？ 用目标约束、阶段验收、完成条件、定期反思和人工确认点。
- 追问 2：状态记忆怎么设计？ 区分短期上下文、任务状态、长期偏好和工具经验，不要混在一个 Prompt 里。
- 追问 3：工具调度怎么统一？ 用标准 Tool Schema、权限声明、返回结构和错误码，让调度层可治理。
- 追问 4：如何评估类 Manus 系统？ 看任务完成率、步骤成功率、人工接管率、成本、耗时和可复盘性。
📝 详细解析
类 Manus 与普通 Agent 的本质区别
普通 Agent（如单轮工具调用）只需要处理「一次请求 → 若干工具调用 → 一个答案」。类 Manus 面对的是「完成一个需要数十步、跨越分钟到小时的复杂任务」：
普通 Agent：用户问 → 搜索 → 回答（2-3步，10秒内）
类 Manus：用户说"帮我调研并撰写一份AI芯片行业报告"
→ 规划研究提纲（10个子任务）
→ 搜索各子任务（30+次检索）
→ 撰写各章节、生成图表
→ 整合、校对、输出报告
（50+步，30分钟+）任务状态模型设计
长任务最大的挑战是「状态漂移」——随着步骤增加，上下文越来越长，模型开始忘记目标或偏离原始计划。解决方案：
python
class TaskState:
goal: str # 原始用户目标（始终保持）
plan: List[SubTask] # 分解的子任务列表
completed: List[str] # 已完成子任务
current: SubTask # 当前正在执行的子任务
artifacts: Dict # 已产出的成果（文件、数据）
checkpoints: List # 检查点（可恢复点）
budget: Budget # 剩余预算（步数、Token、费用）每步执行后更新状态，而不是靠模型从对话历史推断进度。
工具调度的统一设计
类 Manus 的工具集通常包括：搜索、浏览器、文件读写、代码执行、数据库查询、邮件/日历 API 等。关键是统一的工具 Schema：
json
{
"name": "web_search",
"description": "搜索互联网信息",
"parameters": {"query": "string", "max_results": "integer"},
"returns": {"results": "array", "sources": "array"},
"requires_auth": false,
"risk_level": "low"
}高风险工具（risk_level: high）调用前需要人工确认。
🎯 面试总结
回到 Agent 骨架，扩展到长任务链。关键是状态管理和长链路稳定性。