企业Agent协作平台赛道地图：从单Agent到多角色协同的工程实践

把 AI 当同事管理——企业 Agent 协作平台赛道地图

这两年做 AI 应用的团队，基本都经历了一个相似的路径：先做出一个聊天机器人，发现只能问答不够用；然后升级成能调用工具的 Agent，发现单个 Agent 还是撑不起真实业务；最后被逼无奈开始研究多个 Agent 怎么协作，也就是把 AI 当同事来管理。这个转变不是概念炒作，而是场景逼出来的。企业里的正经流程，几乎没有哪个是一条直线走完的：一个需求要经过客服、分析、产品、研发、法务多个角色，每个角色有自己的专长、上下文和交接标准，AI Agent 要真正进入生产环境，就必须解决"多个智能体如何像团队一样协作"的问题。

这篇文章我想把企业 Agent 协作平台这个赛道完整梳理一遍。会覆盖为什么需要协作平台、Agent 角色怎么设计、核心技术模块有哪些、国内外主流框架和平台怎么选，以及我实际落地过程中的踩坑记录。适合正在做 Agent 应用开发、或者准备在公司里引入多 Agent 体系的读者参考，不管你是技术负责人、AI 工程师还是产品经理，应该都能找到对自己有用的部分。

1. 先搞清楚一个前提：为什么单 Agent 不够用

很多人第一次接触 Agent 协作时，第一反应是"炫技"或者"过度设计"：一个 Agent 加一堆工具不是也能干活吗？为什么要搞多个 Agent 互相协作？这个疑问很正常，但真实跑过复杂场景之后，你会明白单 Agent 的瓶颈是物理性的，不是工程上偷懒就能绕过去的。

1.1 单 Agent 的瓶颈其实很具体

第一个瓶颈是上下文窗口的物理限制。现在主流大模型的上下文虽然越做越长，但长上下文不等于长记忆，更不等于高精度。实测下来，上下文超过一定阈值之后，模型对早期信息的关注度和准确率都会明显下降，而且 token 成本呈线性甚至超线性上升。一个 Agent 如果把调研、分析、撰写、审核全包了，它要么得把大量中间结果塞进上下文，要么就得反复压缩总结，每次压缩都在丢信息。

第二个瓶颈是单一模型的能力边界。同一个模型，写作能力强的不一定代码能力强，推理强的未必擅长结构化输出。单个 Agent 背后是一个模型实例，你很难让它同时具备"行业专家+优秀工程师+严谨审核员"三种互斥特质。而多个 Agent 各配各的模型、各配各的提示词和工具，本质上是在做能力路由：什么活交给什么模型干，比逼着一个模型干所有事要靠谱得多。

第三个瓶颈是职责不清带来的失控。单个 Agent 一旦承担过多步骤，中间任何一步出错，排查都非常痛苦。到底是提示词问题、工具调用问题还是模型幻觉问题？没有清晰的职责边界，就没有清晰的排错边界。多 Agent 架构强制你把流程拆成节点，每个节点职责单一，出问题能快速定位到具体某个 Agent——这在生产环境里是巨大的维护优势。

1.2 企业流程天然是"多角色协作"的

再换个视角看企业真实的业务流程。一个市场活动从策划到落地，要经过活动策划、物料设计、渠道投放、数据回收、复盘总结，每个环节的人掌握的信息不同、专业判断不同、交付物标准不同。你不可能让一个人从策划一路干到渠道执行再自己写复盘报告，即便能，质量也堪忧。

企业流程本质上就是一个角色分工、信息流转、逐级审核的协作网络。Agent 协作平台要做的，就是把这个网络用软件的方式还原出来：每个 Agent 对应一个专业角色，负责一段明确的职责，按照预设的协作协议把工作交接给下一个角色。这样做的好处不只是"看起来像团队"，而是让整个流程变成可编排、可监控、可回滚的工程系统。

这也是为什么我说"把 AI 当同事管理"不是比喻，而是工程方法论。你管理一个人类同事，要想清楚他的职责、他需要什么信息、他的产出质量怎么评估、他什么时候该向上汇报；管理一个 AI 同事，逻辑完全一样，只是把岗位说明书换成了 system prompt，把工作交接换成了结构化消息传递，把绩效评估换成了自动化评测指标。

2. 把 AI 当同事：角色设计与协作关系怎么定

如果你已经决定上多 Agent 架构，第一个要做的不是选框架，而是先回答一个问题：这个"AI 团队"里到底有哪些角色？我在好几个项目里见过同一种翻车方式——大家兴冲冲搭了五六个 Agent，结果跑起来发现互相抢活干、相互覆盖、上下文乱传，整个系统像个失控的群聊。问题根源就是角色设计没做扎实。

2.1 先给 Agent 写"岗位说明书"

给 Agent 设计角色，事实上就是在写岗位说明书。一份合格的 Agent 岗位说明书至少要包含四部分：角色定位（他是谁，具备什么专业背景）、职责边界（他负责做什么，更重要的是不做什么）、输入输出规范（他接收什么格式的信息，产出什么格式的结果）、协作上报规则（什么情况自己处理，什么情况必须转给其他 Agent 或上报人类）。

拿一个很典型的场景举例：给销售团队做一个客户线索处理系统。你可以设计三个角色：线索清洗 Agent 负责去重和补全信息，线索评分 Agent 负责按规则打分，策略建议 Agent 负责给出跟进建议。三个角色各管一段，输出格式统一为 JSON，通过共享的数据结构传递结果。这时候你会发现，每个 Agent 的提示词都非常聚焦，调优起来很容易，出问题也很好定位——是清洗逻辑有问题还是评分规则有问题，跑一遍数据就能看出来。

我个人的实践心得是，岗位说明书里最容易被忽略的是"不做什么"。"不做什么"写清楚了，才能避免多个 Agent 之间出现职责重叠。比如线索评分 Agent 绝对不去修改原始数据，只输出评分和理由；建议 Agent 不直接生成跟进邮件全文，只输出策略要点。边界清晰之后，协作自然就顺了。

2.2 三种协作模式怎么选

Agent 之间的协作关系，抽象下来其实就三种模式，搞清楚它们各自的适用场景，能少走很多弯路。

第一种是管理者-执行者模式，也叫编排模式。一个主控 Agent 负责拆解任务、分发给多个执行 Agent，再汇总结果。这种模式最直观，适合任务层次分明、子任务相对独立的场景，比如写一份行业报告，拆成资料搜集、数据分析、图表生成、文字撰写几个子任务并行推进。优点是结构清晰、容易控制，缺点是主控 Agent 容易成为瓶颈，而且如果子任务之间有强依赖，并行收益会大打折扣。

第二种是对等协作模式，也叫群聊模式。多个 Agent 地位平等，通过一个共享的上下文互相讨论、互相补全，比如一个产品设计讨论组里，市场 Agent、技术 Agent、法务 Agent 各自发表意见，最终由人类总结决策。这种模式适合头脑风暴、方案评审类任务，灵活度高，但可控性差，跑着跑着容易偏题，必须有明确的终止条件。

第三种是流水线模式，也叫管道模式。每个 Agent 只负责一个环节，前一个的输出就是后一个的输入，像工厂流水线一样。这种模式最适合流程稳定、环节清楚的业务，比如工单处理、内容审核、数据处理链路。优点是每个环节都高度可测、可替换，缺点是整个链路耗时等于各环节之和，而且一处出错可能全链路重跑，需要做好中间结果的缓存和断点恢复。

没有哪种模式是绝对最好的，一个复杂系统往往是三种模式嵌套使用：外层用管理者-执行者拆任务，内层某些子流程用流水线，某个创意环节再用群聊。关键是你得知道自己每个环节在用什么模式，而不是糊里糊涂混在一起。

2.3 人类在协作回路里的位置

很多团队做多 Agent 协作，容易走另一个极端：想全自动化，把所有环节都交给 Agent 闭环。我的建议是，在企业落地的现阶段，一定要在关键节点保留人类审核位。你不需要人类参与每一个环节，但必须在有资金操作、对外发布、法务承诺等高风险动作之前，设置人工审批闸口。

这里可以套用权限管理里的"最小授权"思路：Agent 能做的动作，以不产生不可逆后果为边界。可以生成内容，但不能直接发布；可以算报价，但不能直接签合同；可以写代码，但不能直接合并到主干。把这些边界固化到协作流程里，人类在这个系统里的角色就不是"操作员"，而是"审批人"和"异常处理人"。这才是"把 AI 当同事"的正确姿态——你不是在替它干活，你是在做它做不了的决定。

还有一个经验分享：人类审批环节不是越多越好，每多一道人工，系统就多一分延迟和成本。一定要把人工审批点压到最少，同时保证每个审批点都是必要且信息完整的。比如审批界面不只是给人类看一个"是否通过"的按钮，要把 Agent 的推理过程、引用来源、相关数据都展示出来，这样人类才能在几秒钟内做出高质量判断，而不是被迫盲审。

3. Agent 协作平台的核心技术模块拆解

不管选哪家框架、哪个平台，企业级 Agent 协作系统绕不开几个核心技术模块。这些模块解决的是协作的底层问题：任务怎么编排、上下文怎么共享、工具怎么接入、过程怎么观测。把这几个模块吃透了，你再看任何平台或框架，都能快速判断它的设计优劣。

3.1 编排层：从 Chain 到 Graph 再到 Swarm

编排层是 Agent 协作平台的心脏，决定了任务如何在多个 Agent 之间流转。最早的概念是 Chain，也就是链式调用，一个接一个按固定顺序执行；后来出现 Graph，也就是图编排，允许分支、循环、并行，LangGraph 就是典型代表；再往上是 Swarm 或 Crew 这一类偏"群体智能"的编排方式，Agent 之间可以动态协商、互相委托任务。

我对编排层的建议是：能用图编排解决的事，别急着上群体智能。Graph 的优势在于结构显式可控，每个节点、每条边的逻辑都是可审查的，这在企业环境里非常重要。群体智能虽然听起来先进，但动态协商意味着不确定性，你不知道整个流程最终会长成什么样，这在生产环境是灾难。先把流程固化下来，把不确定性控制在局部，等系统稳定了再考虑引入更灵活的协作机制。

具体到技术选型，图编排已经成了事实标准。你需要关注一个图的几个能力：条件分支是否支持复杂判断、并行节点是否容易配置、循环是否有限制、断点续跑是否支持。这几个点直接决定了你能不能把真实业务流程跑起来，而不是停留在 demo 阶段。

3.2 记忆与上下文共享是协作的地基

多个 Agent 协作，最大的难点不是"各自干活"，而是"怎么让彼此理解自己干了什么"。每个 Agent 的上下文窗口是独立的，如果没有一套共享机制，信息就会在交接过程中丢失或扭曲。这是协作系统里最容易被低估、也最容易出问题的模块。

现在主流做法是分两层解决。短期记忆用共享工作区（比如一个共享的向量数据库或者结构化存储），每个 Agent 把产出写入工作区，后续 Agent 按需读取，避免把大量中间结果全塞进上下文。长期记忆用外部记忆库，沉淀的是跨任务的结构化知识，比如客户偏好、项目历史决策、组织规范，让 Agent 不是每次从零开始。

我的实操经验是：不要让 Agent 自己决定写什么进共享区，要让流程定义好每个节点的读写权限。比如线索清洗 Agent 只能写清洗结果表，评分 Agent 只能读清洗结果表并写评分表，不许越界。这样数据流就是清晰的，排查问题的时候你能沿着数据流一路看下去，很快就能定位是哪一环的数据出了问题。如果让 Agent 自由读写，共享区很快就会变成一锅粥。

3.3 工具调用与 MCP 生态

Agent 要真正干活，必须能调用外部工具，比如查数据库、调 API、发邮件、操作内部系统。工具调用这一层，现在最值得关注的是 MCP（Model Context Protocol）的兴起。MCP 相当于给 Agent 生态做了一个标准化的"USB 接口"，通过统一协议把各类工具接入 Agent，大大降低了工具集成的重复开发成本。

这两年的变化很明显：前年做 Agent 工具集成，基本是每个工具写一套 function calling 的适配代码，工具越多，维护越痛苦；现在越来越多的工具直接提供 MCP Server，Agent 框架原生支持 MCP Client，接入一个新工具变成了一句配置的事。MCP 本质上是在解决"工具生态碎片化"的问题，对 Agent 协作平台的意义在于：不同 Agent 可以共享一套工具注册中心，按权限各取所需，而不是每个 Agent 单独对接。

不过我也要泼一盆冷水：MCP 暂时还没有解决工具调用的可靠性问题。工具返回的格式不规范、网络超时、鉴权过期，这些都是高频事故。所以工具调用层的设计，一定要考虑失败重试、超时降级、结果校验，并且把工具调用的输入输出完整记录到日志里。没有工具调用日志，你根本没法排查 Agent 为什么给出错误结论。

3.4 可观测性：没有追踪就没有管理

多 Agent 协作系统一旦部署到生产，最核心的工程问题就是可观测性。一个任务经过三四个 Agent、十几次工具调用，中间任何一环出错，如果没有完整追踪，你只能对着最终的错误结果干瞪眼。这也是协作平台和单体 Agent 应用最大的工程差异：单体出错好查，分布式协作出错难查。

可观测性至少要覆盖三层：链路追踪（一次任务的完整流转轨迹，每个 Agent 的输入输出、耗时、token 消耗）、质量指标（每个环节的成功率、重试次数、人工介入率）、成本指标（每个 Agent 的 token 消耗和工具调用费用）。企业里引入 Agent 协作平台，管理层必然要问"投入产出比"的问题，没有成本指标，你连账都算不清。

有个细节很多人会忽略：要给每个 Agent 的输出加版本号。Agent 的提示词、模型、工具配置一旦调整，输出就会变，如果没有版本管理，你根本不知道线上跑的是哪个版本的行为，出了问题也无法回滚。我把 Agent 的配置看作代码的一部分，全部走 Git 管理，每次调整都记录变更原因。这个习惯帮我省了无数排查时间。

4. 赛道地图：主流框架与平台怎么选

现在市面上能用来搭 Agent 协作系统的工具，大概可以分成三类：开源框架、低代码平台、商业企业级平台。它们各有各的适用场景，不存在"一个打所有"的选项。这一节我把三类都盘一遍，给你一个可以直接照着选型的地图。

4.1 开源框架四巨头怎么对比

开源圈里做 Agent 协作最活跃的框架，首推 LangGraph、AutoGen、CrewAI 和 Semantic Kernel，这四个基本代表了不同的设计哲学。

我的选型建议很简单：如果你的业务是流程明确的，选 LangGraph，它把流程控制权完全交给你；如果是偏探索式的研究场景，AutoGen 的对话式多 Agent 能给你更多灵活度；如果团队没有专职 AI 工程师，CrewAI 的概念最贴近业务语言；如果公司技术栈是微软系，Semantic Kernel 值得优先考虑。

不过要提醒一句，框架选型不要只看 demo 效果，要看你实际业务里最容易出问题的地方：状态管理复不复杂、断点续跑支不支持、日志完整度高不高、社区活跃度如何。这几个维度比"开箱效果"重要得多。

4.2 低代码平台适合什么人

低代码 Agent 平台（比如 Dify、Coze、Flowise 以及各家云厂商的 Agent 构建服务）这两年发展很快，它们的特点是：可视化编排、内置大量工具和模板、对普通业务人员友好。如果你的目标是快速验证一个 Agent 协作想法、或者搭建内部效率工具，低代码平台的性价比非常高。

我实际用下来，低代码平台最适合两类场景：一是业务侧的"AI 工作流"搭建，让熟悉业务的同事自己把流程拖出来；二是原型验证，用一周时间跑通一个多 Agent 协作的 PoC，验证可行性之后再决定要不要用代码重构。低代码平台在编排灵活性、私有化部署、深度定制上仍然比不过开源框架，但胜在快，这个优势在早期尤其宝贵。

踩过的坑也分享一下：低代码平台最容易出问题的是"看起来快，后期改不动"。可视化编排一旦节点多起来，维护成本急剧上升，debug 工具又不如代码层面灵活。所以我的经验是，低代码平台适合做"固定流程"，不适合做"频繁变化流程"。如果业务方隔三差五就要改流程，你还是老老实实用代码编排，把流程变更纳入版本管理。

4.3 商业企业级平台的取舍

这两年各大软件厂商都推出了自己的企业级 Agent 平台，比如 Salesforce 的 Agentforce、微软的 Copilot Studio，以及国内云厂商的各类 Agent 开发平台。它们的共同点是：和自家生态深度绑定，开箱即用，企业级安全和运维能力比较完善，但定制空间相对受限，而且和具体厂商的云服务绑定较深。

企业级平台的真正价值不在于"Agent 能力多强"，而在于"和现有系统的集成多顺"。如果你的公司已经在某个生态里投入很深，选同生态的 Agent 平台，集成成本最低；如果是绿地项目，没有历史包袱，我更推荐用开源框架自建，保留最大的灵活度。另外，商业平台对企业来说最大的吸引力是"有人兜底"，出了运维问题、安全问题有厂商支持，这在预算充足的头部企业是很重要的考量。

选型归根结底是一道权衡题：速度、灵活性、可控性、集成度、成本，每家公司对这些维度的权重不同，答案自然不同。我的建议是拿一个真实业务场景，用三种方案各做一遍 PoC，对比的维度包括：搭建时间、运行稳定性、改造成本、可观测性、总体成本。比完你就清楚了，不用拍脑袋。

5. 企业落地中绕不开的治理与评估问题

技术选型搞定之后，真正的硬仗才开始：怎么让多 Agent 系统在企业里安全、稳定、可负责任地运行。这一节聊的全是"技术之外但决定成败"的问题，也是和总部领导汇报时一定会被问到的问题。

5.1 权限设计的底线思维

单 Agent 时代，权限问题还不突出，因为一个 Agent 通常只接一类系统；多 Agent 协作时，不同 Agent 要访问不同系统，权限管理的复杂度成倍上升。这里的核心原则只有一个：最小权限。每个 Agent 只拥有完成自己职责所必需的最小工具权限和数据访问范围，而不是给所有 Agent 一把万能钥匙。

具体落地时可以这么设计：为每个 Agent 创建独立的服务账号，账号权限按角色职责配置，比如数据分析 Agent 只能读数据仓库的特定表，内容生成 Agent 只能写内容库，邮件 Agent 只能调用发信接口且带有审批前置条件。所有 Agent 的调用行为都要有审计日志，确保出了问题能追溯到具体是哪个 Agent、哪个账号、哪次调用。

这条经验非常关键：权限设计一定要和角色设计同步做，不要等系统跑通了再补。我曾经在一个项目里为了赶进度先放开权限跑通全流程，后续补权限机制时发现流程里到处都是隐性的越权调用，改起来比一开始设计要痛苦好几倍。权限这东西，越早做越省钱。

5.2 评估体系：别只看准确率

很多团队评估 Agent 系统的标准，还是停留在"准确率"这个单一指标上，这对生产系统来说远远不够。一个多 Agent 协作系统能不能上线，至少要看四类指标：任务成功率（整个协作流程从头到尾跑通的比例）、步骤有效率（每个环节一次性通过的比例）、人工介入率（多少任务需要人类介入才能完成）、单位成本（每完成一个任务的平均 token 消耗和时间成本）。

我见过最离谱的案例是，一个团队汇报 Agent 系统"准确率 97%"，结果上线后发现每个任务平均要人工介入三次，员工比不用 Agent 还累。准确率再高，如果人工介入率居高不下，系统在生产环境的实际价值就是负的。所以评估体系一定要围绕"真实业务效果"来设计，而不是围绕"模型的学术指标"。

评估的另一面是持续监控。Agent 系统的输入分布会随着时间漂移，模型行为也可能变化，今天跑得好不代表下周还好。我通常会给线上系统建一套每日跑批的监控任务，每天早上自动抽取前一天的数据，重新计算成功率、人工介入率、成本曲线，如果指标比基线差超过阈值就自动告警。这样才能避免"系统悄悄变坏"的情况。

5.3 安全测试与监督机制

企业引入 Agent 协作平台，安全团队最关心的是：恶意提示词注入、数据泄露、权限滥用、输出内容合规风险。这些不是危言耸听，多 Agent 系统因为链路长、交互多，攻击面比单 Agent 大得多。尤其是提示词注入攻击——攻击者通过输入内容操纵 Agent 执行非预期操作——在协作系统里可能沿着数据流从一个 Agent 传播到另一个 Agent，危害被放大。

我的建议是把安全测试纳入常规开发流程。每次更新 Agent 提示词或工具配置，都要跑一遍安全回归测试，包括：恶意指令注入、越权访问尝试、敏感信息探测、输出内容合规检查。有些团队会觉得这样做太重了，但以现在的监管环境和安全风险，这个成本是必须付的。

监督机制上，除了前面说的人工审批闸口，还要有"异常行为熔断"机制。比如某 Agent 短时间内调用工具频率异常、访问了不该访问的数据、或者输出内容触发了敏感词规则，系统要能自动暂停该 Agent 的运行并通知管理员。熔断机制不复杂，但能防止小问题演变成大事故。

6. 实操实录：跑通一个最小协作团队的完整过程

前面讲了一堆理论和框架，这一节分享一个我最近做过的真实项目，把从场景拆解到上线的完整过程走一遍。这个案例比较有代表性，是做面向企业内部的"市场情报周报生成系统"，三个 Agent 协作：信息搜集 Agent、情报分析 Agent、周报撰写 Agent，外加一个负责审核的人类编辑。

6.1 从一个具体场景开始

项目背景是这样：市场部每周要花一整天时间搜集竞品动态、行业新闻、客户反馈，汇总成一份周报。搜集环节重复性高、信息源多，分析环节需要专业判断，撰写环节讲究结构清晰。我接手后做的第一件事不是写代码，而是把现有的人工流程完整拆了一遍：他们从哪些渠道搜集信息、按什么标准筛选、分析着重看哪些维度、周报的固定结构是什么、谁审核、审核改哪些地方。

这个过程非常重要。流程拆得越细，Agent 角色设计和编排设计就越有依据。最后我们确定了三节点流水线：搜集 Agent 每天自动抓取指定信息源并去重，分析 Agent 读取搜集结果按照竞品、行业、客户三个维度做结构化分析，撰写 Agent 把分析结果按照周报模板生成稿子，再由市场部编辑审核发布。

这个案例的启发是：不要先选框架再想场景，一定是先拆流程再选工具。流程拆清楚了，你会发现技术选型就是水到渠成的事，因为你已经知道每个环节需要什么能力、数据怎么流动、哪里需要人工干预。

6.2 关键参数与配置怎么定

技术实现上，我选的是 LangGraph 做编排，三个 Agent 节点串成流水线，共享一个结构化存储区。这里有几个关键的配置决策值得展开说说。

第一个是模型选型。搜集 Agent 用的是中等规模模型，因为它的任务就是抓取和去重，不需要太强推理；分析 Agent 用最强模型，因为分析质量直接决定周报价值；撰写 Agent 也用强模型，但加了严格的输出格式约束。这个配置组合比三个 Agent 全用最强模型，成本大约省了 40%，效果几乎没有差别。这个经验很重要：按角色复杂度配模型，而不是一刀切。

第二个是上下文控制。三个 Agent 之间不直接传递大段文本，而是全部通过结构化存储中转：搜集 Agent 写入原始信息列表，分析 Agent 只读摘要字段，撰写 Agent 只读分析结果。每个 Agent 的上下文窗口都很干净，不会被无关信息污染。这个设计让整个系统在长跑之后依然稳定，不会因为上下文累积而质量下滑。

第三个是人工审批点设计。系统只设了一个审批点：周报生成后，在发布前需要编辑在系统里点一下确认。这个审批界面把三个 Agent 的信息都汇总展示：信息来源列表、分析结论摘要、生成稿全文，编辑确认或者修改后发布。我们实测下来，编辑平均花 10 分钟能完成审核，相比之前一整天的搜集整理，效率提升非常显著。

6.3 实测踩坑与排查实录

这个项目上线初期踩了不少坑，挑几个典型的分享，都是能直接复用的经验。

第一个大坑是分析 Agent 的输出格式跑偏。最开始我要求分析 Agent 输出 JSON，但模型偶尔会在 JSON 里夹带说明文字，导致下游解析失败。这个问题看似简单，但在多 Agent 协作里影响会被放大，因为下游 Agent 也被带偏了。解决方案是做了一层"输出校验器"，在分析 Agent 和撰写 Agent 之间加一道自动校验，格式不对就触发重试，重试超过三次就降级为人工处理。这层校验器几乎是所有多 Agent 流水线的必需品。

第二个坑是信息搜集 Agent 抓到了脏数据。有些信息源偶尔会返回错误页或者重复内容，搜集 Agent 不识别，把脏数据写进了共享区，分析 Agent 基于脏数据给出了错误结论，周报撰写 Agent 又把错误结论写得特别漂亮。这个事故给我们的教训是：每个 Agent 的输出都需要做质量校验，尤其是上游 Agent 的输出，不能默认可信。后来我们在共享区写入端加了规则校验，比如 URL 格式、内容长度、重复度检查，拦住了大部分脏数据。

第三个坑是成本失控。上线第一周，token 成本比预估高了 60%，排查发现是搜集 Agent 在抓取时反复重试失败请求，每次重试都在消耗 token。解决方案是给工具调用加超时和重试上限，并且对每次调用的 token 消耗做实时统计，超过单任务预算就触发告警。成本这东西，不盯就失控，每天看一遍成本报表是必须的。

7. 一些掏心窝的经验，以及接下来值得关注的方向

项目做了几个之后，最大的体会其实是心态层面的转变：做 Agent 协作系统，最有用的思维工具不是技术框架，而是"管理一个团队"的直觉。每次设计一个新的协作流程，我都会问自己几个管理向的问题：这个角色需不需要单独存在？他需要什么资源才能干活？他的产出怎么验收？他和上下游的交接清晰吗？这些问题想清楚了，落到技术实现上反而很快。

几个踩过坑之后沉淀下来的个人经验，再强调一遍：角色设计先于技术选型，权限设计同步于角色设计，输出校验和可观测性从第一天就做，成本监控常态化。这几点做到了，多 Agent 系统就算不能保证绝对稳定，至少能在出问题时快速定位、快速恢复，不至于变成生产事故的定时炸弹。

至于赛道接下来会走向哪里，我个人的观察是三个方向值得重点关注：一是 MCP 生态会继续壮大，工具接入的标准化程度会越来越高；二是评估和安全会从"辅助功能"变成"平台标配"，没有成熟评估体系的 Agent 平台很难进入中大型企业；三是 Agent 协作会从"预设流程"逐步走向"半自主协商"，但这需要更成熟的安全和控制机制兜底，短期内在企业生产环境还是会以显式编排为主。

最后分享一个实用的小技巧：刚开始做多 Agent 项目时，别贪多求全，先拿一个业务价值明确、流程边界清晰的场景做最小闭环，跑通上线再横向复制。我见过太多团队死在"想一次做个大平台"的陷阱里，而真正能落地的，往往都是从小场景切入、逐步扩展的务实路线。