夜雨聆风从单一 AI 助手到一支 AI 团队的工程实践
Managed Agents 架构到底解决了什么问题？
文章较长，建议收藏阅读。
写在前面
很多人第一次听到多 Agent 协作，脑子里想到的是：
“是不是同时开十几个 AI 聊天窗口？”
这个理解不能说错，但还停留在很浅的一层。真正有价值的多 Agent 架构，不是简单地把 AI 数量变多，而是把一个混在一起的 AI 助手，拆成一套能分工、能恢复、能并发、能审计、能持续运行的任务系统。
如果说单个 AI 助手像一个很聪明的实习生，那么 Managed Agents 更像是一套小型组织：
• 有人接需求 • 有人查资料 • 有人写代码 • 有人跑测试 • 有人做复盘 • 有人负责调度这些人
接下来让我们从一个故事出发，彻底讲明白多agent协作时遇到哪些问题，如何解决！
故事的开始
小明在一家中小型 SaaS 公司做技术负责人。
公司有一个产品，叫“灯塔”（ps：代号而已，不比较真）。它是一个给商家用的经营分析系统，能看订单、库存、会员、优惠券、财务报表。
随着客户越来越多，客服团队每天都会收到大量工单：
• “为什么今天的销售额和昨天对不上？” • “导出 Excel 报表失败了。” • “会员积分扣错了。” • “这个按钮点了没反应。” • “我想知道上个月哪些商品复购率最高。”
这些工单有的只是使用问题，有的涉及数据查询，有的是产品 bug，还有的需要研发查日志、复现、修代码、发补丁。
小明一开始的想法很简单：
“我能不能做一个 AI 工单助手，帮客服自动看问题？”
勤奋的小明开始了996的工作。
第一幕：一个聪明的聊天机器人
小明做了第一个版本。
架构非常简单：
用户工单 -> AI 助手 -> 回复建议小明把产品文档、常见问题、客服话术都喂给 AI。客服复制用户问题，AI 给出回答。
上线第一天，小明很兴奋。
小明：“梦三千，你看，这个 AI 已经能回答大部分使用问题了。比如用户问怎么导出报表，它马上就能告诉用户入口在哪里。”
梦三千：“那如果用户说，导出报表失败了呢？”
小明：“它会告诉用户刷新页面、检查权限、换浏览器。”
梦三千：“如果真的是后端接口 500 呢？”
小明沉默了。
是啊，这个版本只能回答知识库里的问题。它不知道系统现在的状态，也看不到日志，更不能复现问题。
它像一个熟读说明书的客服，但不是一个能解决真实问题的工程师。
目前已解决的问题是：
• FAQ 自动回复 • 文档检索 • 客服话术生成
但新的问题也出现了：
• 它不能查真实数据 • 它不能看日志 • 它不能判断是不是 bug • 它不能执行任何动作
小明意识到：只会聊天，不够。
第二幕：给 AI 装上工具
小明继续改造，开始给 AI 加工具。
它可以：
• 查知识库 • 查订单数据库 • 查用户权限 • 查接口日志 • 查 Git 提交记录 • 调用测试环境复现接口
新架构变成这样：
用户工单 -> AI 助手 -> 知识库 -> 数据库 -> 日志系统 -> Git 仓库 -> 测试环境 -> 回复建议这次效果明显好了很多。
有一天，客户发来工单：
“我导出 4 月销售报表的时候一直失败，但是 3 月可以。”
AI 查了日志，发现 4 月数据量特别大，导出接口超时。它又查了最近代码，发现导出任务仍然是同步执行。
小明很开心。
小明：“现在它已经不只是客服了，它能查日志、查数据库，还能看代码。”
梦三千：“那它是不是快变成一个真正的工程师了？”
小明：“差不多。”
梦三千：“那你让它同时处理十个工单试试。”
小明试了一下，问题马上来了。
AI 的上下文里塞满了各种东西：
• A 客户的订单数据 • B 客户的日志 • C 工单的代码分析 • D 工单的客服话术 • 历史修复方案 • 中间推理过程
它开始混淆客户、混淆日期、混淆接口。更糟糕的是，一个工单查出来的错误判断，会影响后面几个工单。
梦三千说：
“你现在不是给 AI 装了工具，你是让一个人背着十几个工具箱，边跑边修飞机。”
目前已解决的问题是：
• AI 能接触真实系统 • AI 能做简单诊断 • AI 能从“回答问题”升级到“分析问题”
但新的问题出现了：
• 工具太多，角色混乱 • 上下文越来越脏 • 不同任务互相污染 • 一个 Agent 既要查资料，又要写结论，又要做判断
小明意识到：工具越多，单个 Agent 越容易失控。
第三幕：一个 Agent 干所有事，迟早会崩
有一天，小明遇到了一个真实的生产事故。
一个大客户反馈：
“会员积分扣错了，而且只发生在使用优惠券的订单里。”
这个问题不简单。AI 需要做很多事：
1. 读工单 2. 查客户订单 3. 查积分流水 4. 查优惠券规则 5. 查最近代码 6. 复现问题 7. 判断根因 8. 写修复建议 9. 给客服生成回复
一开始 AI 表现不错。
它先查到了异常订单，又定位到积分计算模块，还找到了最近一次优惠券逻辑改动。
但做到后面，它开始变得奇怪。
它忘了最开始的客户 ID。它把测试环境的数据当成生产数据。它把优惠券折扣和积分抵扣混在一起。它还建议修改一个已经废弃的函数。
小明看着屏幕叹气。
小明：“它刚开始很聪明，后面怎么越来越糊涂？这降智也太离谱了吧。”
梦三千：“因为你让它一边侦查现场，一边写代码，一边当客服，一边当测试，一边当项目经理。”
小明：“人也会这样。”
梦三千：“对。所以人类公司才会分工。（来自某银行的客户经理吐槽：我们特么的不分工！我们啥都要干！）”
这句话点醒了小明。
不是模型不够聪明，而是组织方式不对。
第四幕：小明手动组织了一个“AI 小组”
小明决定拆分角色。
他开了四个 AI 窗口：
窗口 1：工单分析 Agent窗口 2：代码排查 Agent窗口 3：测试复现 Agent窗口 4：客服回复 Agent每个窗口只做一件事。
这次效果好了很多。
工单分析 Agent 只负责理解用户问题。代码排查 Agent 只负责看相关模块。测试复现 Agent 只负责写复现步骤。客服回复 Agent 只负责把技术结论翻译成用户能听懂的话。
小明感觉自己打开了新世界。
小明：“这不就是多 Agent 协作吗？”
梦三千：“不完全是。”
小明：“为什么？”
梦三千：“因为现在真正的 Coordinator 是你。”
小明愣住了。
确实如此。
是小明在复制粘贴上下文。是小明在决定谁先做、谁后做。是小明在判断哪个 Agent 的结论可信。是小明在把测试结果反馈给代码 Agent。是小明在汇总最终回复。
四个 Agent 看起来在协作，但中间的调度全靠人。
目前已解决的问题是：
• 角色分工更清楚 • 上下文更干净 • 每个 Agent 更专注
但新的问题也很明显：
• 人类成了调度中心 • 信息传递靠复制粘贴 • 没有统一任务状态 • 无法稳定复现流程 • 很难扩展到十个、二十个 Agent
梦三千总结：
“你不是缺更多 Agent，你缺一个能管理 Agent 的系统。”
第五幕：Agent 和 Session 必须分开
小明开始重新设计。
他发现，自己之前一直把两个概念混在一起：
Agent = 角色能力Session = 某次任务过程比如“代码排查 Agent”是一个角色模板：
• 使用哪个模型 • 有哪些工具 • 能访问哪些仓库 • 系统提示词是什么 • 输出格式是什么
但“排查会员积分 bug”是一次具体任务。它应该有自己的上下文、日志、文件、结论和中间状态。
于是小明把它拆开：
Agent：我是谁Session：我正在做什么这一步非常关键。
新架构变成：
Agent Template -> Session A：排查积分 bug -> Session B：排查导出失败 -> Session C：排查库存异常同一个 Agent 模板，可以同时跑很多个 Session。
每个 Session 都是独立的，不互相污染。
梦三千问：
“这和以前开多个窗口有什么不同？”
小明说：
“以前窗口就是窗口，状态散在聊天记录里。现在 Session 是系统里的正式对象，可以保存、恢复、复制、回滚。”
梦三千点头：
“也就是说，你终于把一次任务变成了可管理的东西。”
这一阶段解决的问题是：
• 同一个 Agent 可以处理多个任务 • 不同任务上下文隔离 • 任务状态可以被系统记录 • 后续可以做恢复、复制、审计
这是 Managed Agents 的地基之一。
第六幕：执行环境不能当宠物养
小明继续往前走。
他让代码 Agent 可以进入测试环境执行命令、跑脚本、改代码。
一开始很爽。
但很快出事了。
某个 Agent 为了复现 bug，装了一个临时依赖。另一个 Agent 改了环境变量。第三个 Agent 跑测试时生成了一堆缓存文件。第四个 Agent 不小心切错了 Git 分支。
测试环境越来越脏。
最后，一个本来已经修好的问题，又因为环境污染复现不出来。
小明很崩溃。
小明：“我是不是应该给每个 Agent 配一台长期机器？”
梦三千：“千万别。你这是把执行环境当宠物养。”
小明：“什么意思？”
梦三千：“宠物坏了你会心疼，会修，会迁就它。但在这种架构里，执行环境应该像临时工位。坏了就扔，重新开一个干净的。”
小明明白了。
模型的大脑和执行代码的环境，不能绑死。
于是他引入了 Sandbox/Worker。
Agent 大脑：负责思考、规划、决策Worker/Sandbox：负责执行命令、跑代码、查文件Worker 是无状态的。
它可以随时创建，也可以随时销毁。
一个 Worker 里依赖装坏了，没关系，扔掉。代码跑崩了，没关系，扔掉。环境变量乱了，没关系，扔掉。
重新拉一个干净 Worker，继续从 Session 里恢复任务。
这一阶段解决的问题是：
• 环境污染 • 执行状态不可控 • 任务失败后难以恢复 • 多个 Agent 共用环境带来的冲突
它带来的核心变化是：
Agent 不再等于一台机器Agent 不再等于一个工作目录Agent 不再等于一段混乱的聊天历史Agent 只负责“怎么想”。Worker 只负责“怎么做”。
这就是大脑和双手解耦。
第七幕：Session Store 让上下文可以被调度
小明又遇到了一个更细的问题。
代码排查 Agent 通常有一个“黄金状态”。
什么叫黄金状态？
就是它刚刚读完代码、刚刚理解业务、刚刚找出关键模块，但还没有被后续大量细节污染的时候。
这个时候，它最清醒。
但传统聊天模式里，这个状态留不住。你只能继续往下聊。越聊越长，越聊越乱。
梦三千问：
“如果你能把这个清醒时刻存下来，会怎样？”
小明想了想：
“我可以从这个点分叉。”
于是 Session Store 出现了。
它保存的不只是聊天记录，而是任务状态：
• 已读过哪些文件 • 已确认哪些事实 • 当前判断是什么 • 中间产物在哪里 • 关联的日志、代码片段、测试结果是什么 • 当前可以从哪个步骤继续
有了 Session Store，小明可以做几件事：
保存快照恢复上下文复制 Session回滚到早期状态从同一个状态 fork 出多个探索方向比如会员积分 bug 这个任务。
代码 Agent 已经定位到两个可能原因：
• 方案 A：优惠券折扣后积分基数算错 • 方案 B：退款订单重复扣减积分
以前只能让一个 Agent 继续往下查。
现在可以这样：
Session Snapshot：已定位积分模块和异常订单 -> Worker A：验证方案 A -> Worker B：验证方案 B -> Worker C：检查最近提交记录三个 Worker 并发探索，互不干扰。
最后 Coordinator 汇总结果。
这一阶段解决的问题是：
• 长任务上下文衰减 • 无法回到关键状态 • 无法并发探索多个假设 • 无法复用已经理解过的上下文
这一步之后，Session 不再只是记录，而变成了调度资源。
第八幕：Coordinator 正式登场
到这里，小明已经有了：
• Agent 模板 • 独立 Session • 无状态 Worker • Session Store
但还差一个东西。
谁来决定任务怎么拆？谁来决定哪个 Agent 先做？谁来决定失败后重试还是换方案？谁来判断最终结果够不够好？
答案是 Coordinator。
Coordinator 是一个指挥官 Agent。
它不一定亲自写代码，也不一定亲自查日志。它负责调度。
用户目标 -> Coordinator -> 分析任务 -> 拆解步骤 -> 创建 Session -> 分配 Worker -> 收集结果 -> 判断下一步 -> 输出最终结论梦三千问：
“Coordinator 和普通 Agent 有什么区别？”
小明说：
“普通 Agent 做事，Coordinator 管事。”
梦三千：
“更准确地说，普通 Agent 对局部负责，Coordinator 对全局负责。”
小明点头。
比如用户提交工单：
“4 月销售报表导出失败，但 3 月正常，请尽快处理。”
Coordinator 会拆成这样：
1. 工单理解 Agent：提取客户、时间、功能、严重程度2. 日志 Agent：查询导出接口异常日志3. 数据 Agent：检查 4 月数据规模和异常字段4. 代码 Agent：查看导出模块近期变更5. 复现 Agent：在沙盒里构造 4 月报表导出6. 修复 Agent：提出代码修改7. 测试 Agent：验证 3 月和 4 月都正常8. 回复 Agent：生成给客服和客户的说明如果日志 Agent 找不到异常，Coordinator 会让复现 Agent 加强输入。如果测试 Agent 发现回归，Coordinator 会把结果打回修复 Agent。如果代码 Agent 不确定根因，Coordinator 可以 fork 两个 Session 并发验证。
这才是真正的多 Agent 协作。
不是一群 Agent 同时说话，而是一个系统在组织它们工作。
第九幕：任务图让协作可重复
小明又进一步抽象。
很多任务都有固定流程。
比如 bug 修复：
理解工单 -> 查日志 -> 定位代码 -> 复现 -> 修复 -> 测试 -> 生成说明比如数据分析：
明确问题 -> 拉取数据 -> 清洗数据 -> 统计分析 -> 生成图表 -> 写结论比如产品需求：
理解需求 -> 查竞品 -> 评估影响 -> 拆技术方案 -> 估算工作量 -> 生成 PRD于是小明把 Coordinator 的调度，变成了任务图。
这一步的价值非常大。
因为任务从“聊天”变成了“流程”。
流程意味着：
• 可以并发 • 可以重试 • 可以暂停 • 可以恢复 • 可以审计 • 可以统计成本 • 可以持续优化
梦三千说：
“到这里，你做的已经不是 AI 工单助手了。”
小明问：
“那是什么？”
梦三千说：
“是一个面向任务的 Agent 操作系统。”
最终架构：Managed Agents 到底长什么样
小明最终的系统，大概长这样：
这套架构里，每一层都有明确职责。
它解决了什么核心问题
总结下来，这套架构解决的不是一个问题，而是一组问题。
1. 上下文污染
以前所有信息都塞进一个聊天窗口。
现在不同任务有不同 Session，不同角色只拿自己需要的上下文。
结果是：
• 更少混淆 • 更少幻觉 • 更容易定位错误
2. 长任务衰减
以前任务越做越长，Agent 越做越糊涂。
现在可以在关键节点保存 Session 快照。
结果是：
• 可以回滚 • 可以 fork • 可以从最清醒的状态继续
3. 环境污染
以前 Agent 和执行环境绑死。
现在 Worker/Sandbox 是临时的。
结果是：
• 环境坏了直接重建 • 并发任务互不影响 • 失败成本更低
4. 人类调度成本
以前人要复制粘贴、分配任务、汇总结论。
现在 Coordinator 接管调度。
结果是：
• 人从操作员变成审核者 • 多 Agent 可以规模化 • 流程可以自动运行
5. 成本和模型浪费
以前所有步骤都用同一个大模型。
现在不同任务可以选择不同模型。
比如：
结果是：
• 成本更低 • 响应更快 • 强模型用在真正难的地方
一个完整任务如何运行
现在我们回到那个报表导出失败的问题。
用户说：
“4 月销售报表导出失败，但 3 月正常。”
系统内部会这样跑：
1. Coordinator 接收目标2. 工单理解 Agent 提取关键信息：客户、时间、功能、紧急程度3. 日志 Agent 查询 4 月导出接口错误4. 数据 Agent 对比 3 月和 4 月数据量5. 代码 Agent 检查导出模块6. 复现 Worker 在干净沙盒里构造相同条件7. 修复 Worker 修改异步导出逻辑8. 测试 Agent 验证 3 月、4 月和边界数据9. Review Agent 检查是否引入新风险10. 回复 Agent 生成客服说明和技术复盘最终输出可能是：
根因：4 月订单量超过同步导出接口处理上限，导致请求超时。修复：将大报表导出改为异步任务，并增加进度查询。验证：3 月小数据量、4 月大数据量、空数据报表均已通过测试。客服说明：问题已定位为报表数据量过大导致的导出超时，已完成修复。注意，这里最重要的不是“AI 会写这段话”。
真正重要的是，这段结论背后的整个过程是可追踪、可重跑、可分工、可恢复的。
后续会怎么演变
我认为这套架构还会继续往几个方向演变。
1. 从聊天窗口走向任务系统
未来我们不会一直盯着一个聊天框。
我们会提交目标：
修复这个 bug生成这份报告完成这个需求审查这次发布然后系统自动拆成任务图，调度不同 Agent 完成。
2. 沙盒会越来越轻
现在很多系统还会用 Docker 级别的容器。
但未来更理想的是毫秒级启动的轻量沙盒。
因为 Agent 的工作方式会变成：
创建沙盒 -> 执行一个小任务 -> 保存结果 -> 销毁沙盒沙盒越轻，Agent 协作越自然。
3. Session 会成为核心资产
模型可以换，工具可以换，但一个组织积累下来的任务上下文、解决路径、业务记忆，会变得非常值钱。
谁能管理好 Session，谁就能让 Agent 真正长期工作。
4. 权限和审计会变得极其重要
当 Agent 能查数据库、改代码、发邮件、开 PR、甚至部署系统时，权限必须非常细。
未来企业级 Agent 系统一定会关心：
• 谁授权的 • 哪个 Agent 做的 • 用了哪些工具 • 访问了哪些数据 • 改了哪些文件 • 为什么这么决策 • 出错后怎么回滚
5. 人类角色会升级
人不再是复制粘贴上下文的调度员。
人会变成：
• 目标定义者 • 风险审批者 • 结果验收者 • 流程设计者
也就是说，人类从“亲自搬砖”，变成“设计一支 AI 团队怎么干活”。
最后总结
Managed Agents 架构的本质，不是多开几个 AI。
它真正做的是三件事：
把角色拆开把状态管住把执行环境变成可替换资源单 Agent 时代，我们追求的是：
“这个 AI 聪不聪明？”
多 Agent 架构时代，我们开始追求：
“这套 AI 系统能不能稳定完成复杂任务？”
这两个问题完全不同。
前者关心模型能力。后者关心系统工程。
小明最后对梦三千说：
“我终于明白了。以前我想做一个更聪明的 AI 助手，现在我想做一支可管理的 AI 团队。”
梦三千笑了笑：
“这就对了。真正的变化，从来不是多了几个 Agent，而是用组织的方式管理智能。”
本篇文章受益于Anthropic的近期更新而衍生出来的思考，在真实的企业环境多agent协作到底该如何落地。
看到这里的读者希望对你也能有所启发，创作不易，如果您觉得有帮助的话不妨点赞收藏下，非常感谢~
