我把这段时间做多智能体协作项目的经验整理了一下。如果你也在关注 AI Agent，肯定知道agency-agents这个热词——它的核心思路不是“造一个全能的超级 Agent”，而是把一群各有所长的 Agent 组织起来，像一家小型数字机构那样分工协作：有负责拆解任务的“主管”，有负责写代码的“程序员”，有负责验收的“测试员”，还有兜底的“项目经理”。这套模式解决了单个 Agent 上下文爆炸、任务一复杂就失控的问题，特别适合自动化工作流、批量内容生产、代码审查、研究报告生成这类场景。不管你是刚接触 Agent 开发的初学者，还是已经在用 AutoGen、CrewAI、LangGraph 的进阶玩家，这篇文章应该都能给你一些可落地的参考。

1. Agency Agents 的本质：从单体智能到群体协作

先把这个概念掰开揉碎。Agency Agents 直译过来是“代理机构型 Agent”，但它并不是某个具体框架的名字，而是一种架构模式。它的核心思想是：用多个角色化、专业化、可独立运行的 Agent，组成一个临时的“虚拟团队”，通过明确的分工和层级化的汇报关系，去完成单个 Agent 难以独立承担的大型任务。

这套思路和真实世界的公司运转逻辑一模一样。你不可能要求一个员工同时精通市场、研发、财务、客服，但你可以设计一个组织架构，让不同部门各司其职、协同运转。Agency Agents 就是把这种“组织学智慧”迁移到了 AI 系统里。

结合我自己的实操经验，Agency Agents 真正流行起来，是因为传统的单 Agent 模式有几个绕不过去的坎：

1. 上下文窗口的物理极限。单个 Agent 处理长文本时，上下文窗口很快就会被填满。比如让它“调研一个行业并输出报告”，它可能读了几十篇资料之后，早就忘了最初的任务约束是什么。多 Agent 架构下，每个 Agent 只负责一个环节，它只需要在自己的上下文窗口里处理与自己相关的信息，压力和混乱程度都大幅下降。

2. 单点故障导致的“失控螺旋”。让一个大模型 Agent 连续执行 20 步复杂任务，每一步都有误差累积的风险。到了第 15 步，它可能已经偏离了原始目标，而且没有“其他人”能及时拉它回来。而 Agency Agents 里有“主管”角色负责拆解目标和监控进度，有“审查员”角色负责检查中间产出，任何一个环节跑偏都能被及时发现和修正。

3. 提示词工程的复杂度爆炸。单个 Agent 如果把所有角色要求、任务规则、输出格式写进一个提示词里，那个提示词会变成几百行的“缝合怪”。Agency Agents 把大提示词拆分成多个小提示词，每个 Agent 只需要专注于自己的角色设定和任务说明，维护性和可调试性好很多。

所以 Agency Agents 解决的问题非常明确：任务复杂度的增长已经超出了单 Agent 的能力边界，我们需要用系统架构的方法论去构建 AI 应用。

2. 为什么“团队模式”比“单体模式”更稳：设计与取舍

可能有人会问：一个超级 Agent 加上完善的工具调用能力，不是也能搞定所有事吗？为什么要引入多个 Agent 的复杂架构？这个问题的答案是：单体能力的提升有物理上限，而架构层面的提升几乎没有上限。

先说说单体 Agent 的正面价值。确实，在任务链路短、目标单一、容错率高的场景下，单体 Agent 是更好的选择。比如“把这段英文翻译成中文”“帮我把这封邮件改写得更正式”，单个 Agent 两秒搞定，完全没必要上多 Agent 架构。架构是手段，不是目的——一上来就堆一堆 Agent，反而会因为协调开销太大而拖慢效率。

但当任务的复杂度上升之后，单体模式就暴露出几个实际问题了。

第一，能力与角色的冲突。同一个模型去扮演“头脑风暴的发散者”和“严格的审查者”，这两种思维模式是互斥的。发散要求跳跃、联想、允许不完美；审查要求严谨、细节控、揪错不放。让同一个 Agent 在这两种模式之间来回切换，它会“精神分裂”，效果两头都做不好。Agency Agents 允许你用不同的模型或者不同的参数设置分别定义角色，让各自专注于自己的思维模式。

第二，评估反馈链条的缺失。单体 Agent 自己干完活自己检查，很容易“自我感觉良好”。如果你在提示词里强调“必须进行自我检查”，它确实会检查，但那不过是同一套思维模式下的二次生成，很难发现真正的漏洞。Agency Agents 中让不同的 Agent 做交叉检查（比如带不同模型、不同温度参数），能引入真正的多样性，从而更容易暴露问题。

第三，可插拔性的巨大优势。团队模式你随时可以换掉一个角色而不影响其他部分。比如你觉得“代码审查员”用 GPT-4o 效果不好，直接换成 Claude 或本地模型，审查逻辑微调一下即可；但如果是一个单体 Agent，任何一点改动都可能影响其他所有能力。

还有一个非常容易被忽略的点：多 Agent 架构天然提供了流程可视化和断点续跑的能力。每个 Agent 的输入输出都是相对独立、可记录的，一旦某一环出了问题，你可以直接定位到失败的那个 Agent，甚至从这个断点继续执行，而不是从头再来。对自动化流水线来说，这个特性极其重要。

当然，团队模式也有代价。最明显的就是 token 成本比单体模式高不少，多个 Agent 之间的通信会带来大量的额外调用；其次是延迟，原本一次调用能出结果，现在可能需要五六个 Agent 接力，耗时自然上升；最后是调试复杂度，系统的 bug 不再集中在提示词里，而是分散在角色定义、通信协议、任务分配逻辑等多个方面。这些都是你入坑之前需要想清楚的取舍。

3. 核心组件与架构设计：搭好 Agency 的四梁八柱

一个成熟的 Agency Agents 系统，从结构上看基本包含四个核心层次：用户交互层、编排控制层、角色执行层、工具资源层。我分别拆开讲一下，包括每个层次该用什么、为什么这么设计。

3.1 编排控制层：团队的“大脑中枢”

编排层是整个系统的核心骨架，它定义了一件事：Agent 之间怎么通信、任务怎么流动。目前市面上的主流方案有三类：

• 图结构编排（如 LangGraph）：把任务流程拆成节点和边，每个节点是一个 Agent 或工具。优点是流程完全可控、可预测，出错容易定位；缺点是灵活性差，流程一旦定死，遇到计划外的分支就需要人工干预。
• 对话式/层级式编排（如 AutoGen）：Agent 之间可以自由对话，由 Manager 动态决定下一步让哪个 Agent 干活。优点是灵活度高，能处理很多非结构化的流程；缺点是容易陷入死循环，或者发生多轮对话之后偏离原始目标。
• 角色组队式编排（如 CrewAI）：预设一组角色（比如 Research、Writer、Critic），定义他们的任务和交接方式。优点是概念直观、代码量小，适合快速落地；缺点是团队规模大了之后，角色之间的依赖关系会变得很乱，需要额外的管理机制。

我的建议是，如果任务有清晰的常规流程（比如“调研->写稿->审查->修改”），优先用图结构或角色组队式编排，稳定胜于灵活；如果任务是高度开放的探索型任务（比如“帮我做一个竞品分析”），对话式编排会表现得更好，但你需要在 Manager 的提示词里下足功夫，明确收敛条件。

3.2 角色执行层：每个 Agent 的“职责边界”

Agent 的角色定义是整个系统效果的重中之重。一个合格的 Agent 定义应该包含四个要素：职责范围、输入规格、输出规格、完成标准。职责范围要写清楚“这个 Agent 管什么，绝对不管什么”，避免越权；输入规格要明确这个 Agent 期待什么样的输入格式；输出规格要固定输出的结构（比如 JSON 或者 Markdown 标题层级）；完成标准则是它的“退出条件”，让它知道做到什么程度就算干完了，不用无限优化。

实际做的时候，我的建议是给每个 Agent 加上“身份设定+专业背景+公司内部行话”，这样生成的内容会更贴合真实工作场景。比如让一个“资深技术总监”Agent 去审查架构方案，它的语言风格和关注点，会明显区别于一个“初级程序员”Agent。

3.3 工具资源层：Agent 的“手脚”

光有脑子不行，Agent 还得能调用外部工具。常见的工具包括：网络搜索 API、代码解释器、数据库查询接口、文档解析器、图像生成 API 等等。这里我特别想说一个设计原则：工具越多，越要克制。给一个 Agent 塞 20 个工具，它在每次决策时都要花大量 token 去筛选合适的工具，而且选错工具的概率也不低。我通常的做法是：先分析清楚这个 Agent 的角色到底需要哪些工具，然后只挂上那三五个最必要的。能给 Agent 写“专用小工具”（比如一个封装好的、只做 HTML 转 Markdown 的函数），就不要让它自己去网页浏览器里折腾。工具接口越窄、越单一，Agent 越容易稳定使用。

3.4 通信协议与记忆管理：团队的“协作语言”

设计 Agency 时最容易被忽略的，就是 Agent 之间的通信协议。每个 Agent 的输出，最终会成为另一个 Agent 的输入。如果我们不在系统层面统一通信格式，就会出现 A 输出了一段文字、B 却期待一段 JSON，最后的计算结果自然是一塌糊涂。

我的做法是定义一个统一的消息结构，包含：发送者 ID、接收者 ID、消息类型（任务分配、进度汇报、结果提交、问题反馈）、消息正文、附带的元数据（比如时间戳、token 消耗数）。在任务开始前，给所有 Agent 一个公共的“协议说明”片段，让它们都知道消息结构长什么样。这种设计思路，等于在模仿真实团队中的“会议纪要文化”——先定好讨论框架，再让所有人朝同一个方向发力。

记忆管理也是一个不能回避的问题。Agency Agents 中每个 Agent 都可以有短期记忆（当前会话上下文）和长期记忆（跨会话的偏好、历史结论）。短期记忆由框架自动维持，长期记忆我建议用向量数据库来存，比如 Chroma 或 FAISS。在执行任务时，相关记忆会被检索出来，注入 Agent 的上下文里，让它在做决策时“有据可依”。

4. 从零搭建一个 Agency Agents 系统：全流程实操

下面进入实操环节。我用一个常见的业务场景来举例：搭建一个“行业调研报告自动生成系统”。它包含四个 Agent：项目经理（Task Manager）、资深研究员（Researcher）、数据分析师（Analyst）、内容撰写与校对（Writer/Editor）。整个流程是：项目经理拆解任务、派发出去；研究员搜集资料；分析师整理数据并形成结论；写稿人输出报告；最后项目经理做终审。下面是具体的构建步骤。

4.1 步骤一：定义角色与任务目标

用 Python 脚本的方式定义系统配置（这里我推荐直接用 JSON 或 YAML 做配置，方便后续可视化调整）：

project_name: "market_research_report" manager_agent: task_breakdown: true final_review: true context: "你是项目经理，负责将用户的调研目标拆解为可执行的子任务，分配给研究员、分析师、写稿人，并在最后进行报告终审。" researcher_agent: task_type: "information_collection" context: "你是资深行业研究员，精通信息检索和资料筛选，输出结构化的资料清单。" analyst_agent: task_type: "data_analysis" context: "你是数据分析师，擅长从数据和资料中提炼趋势和结论，输出要点式分析。" writer_agent: task_type: "content_writing" context: "你是内容撰写兼校对，负责把分析结论扩展为完整报告，并修正逻辑和错漏。" tools: researcher_tools: ["web_search", "url_reader"] analyst_tools: ["calculator", "code_interpreter"] writer_tools: ["text_editor"]

这一步的核心是：把大目标拆成小目标，给每个小目标配置合适的角色和工具。很多人会偷懒不给 Agent 写“角色说明书”，但这一步恰恰最影响最终质量。角色说不需要写得像小说，重点在于“边界感”和“专业感”。

4.2 步骤二：选择实现框架与构建核心循环

这一步我用 CrewAI 为例演示，因为它的角色组队式抽象跟 Agency Agents 模式最贴近。核心代码如下：

from crewai import Agent, Task, Crew, Process from crewai_tools import SerperDevTool, ScrapeWebsiteTool search_tool = SerperDevTool() scrape_tool = ScrapeWebsiteTool() # 定义研究员 Agent researcher = Agent( role="资深行业研究员", goal="全面收集并筛选与调研主题相关的有效信息", backstory="你有十年行业研究经验，擅长在海量信息中快速定位高质量数据源", tools=[search_tool, scrape_tool], verbose=True, allow_delegation=False ) # 定义分析师 Agent analyst = Agent( role="数据分析师", goal="根据研究员收集的信息提炼核心趋势和洞察", backstory="你精通统计分析，善于从零散数据中发现结构性变化", verbose=True, allow_delegation=False ) # 定义写稿 Agent writer = Agent( role="内容撰写与校对", goal="将分析师的结论撰写为结构化、可读性强的专业报告", backstory="你是资深商业写手，善于将复杂信息转化为清晰表达", verbose=True, allow_delegation=False ) # 定义各环节的 Task research_task = Task( description="围绕主题 '{topic}' 调研市场规模、竞争格局、用户需求、技术趋势，输出5-10条带来源的结构化资料", expected_output="结构化调研资料清单", agent=researcher ) analysis_task = Task( description="基于调研资料提炼关键结论，包括市场趋势、机会和风险，输出3-5条核心洞察", expected_output="分析要点列表", agent=analyst ) writing_task = Task( description="基于核心洞察撰写完整的调研报告，包含摘要、正文、建议、附录，字数不少于2000字", expected_output="完整调研报告", agent=writer ) # 组装 Crew，按顺序执行 crew = Crew( agents=[researcher, analyst, writer], tasks=[research_task, analysis_task, writing_task], process=Process.sequential, # 顺序执行模式 verbose=True ) result = crew.kickoff(inputs={"topic": "2025年东南亚跨境电商趋势"}) print(result)

跑起来之后，这套系统会自动完成“调研->分析->输出”的全流程。你可以直接把它接入定时任务、Slack 机器人，或者做一个简单的 Web 界面。

4.3 步骤三：加入反馈闭环与分支处理

上面的顺序流程是版本 1，实际业务中会遇到很多意外情况，比如研究员搜到的资料太少、写稿人写出的报告数据过时、分析师提出的洞察不完整。这时候就需要把“顺序执行”改造成“带反馈闭环的循环执行”。

在 CrewAI 中，你可以为 Task 增加condition参数，控制它是否要返工。我最常用的一种做法是：在每个 Task 后面追加一个“审查 Agent”，专挑毛病。它审查通过才会进入下一环节，否则打回重做。这个“审查 Agent”本质上就是你的 Manager，只是它的权限不是分配任务，而是把关质量。

如果你用的是 LangGraph，可以更精细地控制流程。你可以把“研究员”“分析师”“写稿人”定义为三个节点，再用“审查员”定义一个条件节点，判断结果是否通过，不通过就回退到上一个节点，并附上修改意见。这种流程建模方式，像极了真实公司的质量控制体系：初稿提交、评审打回、修改重提。

4.4 步骤四：引入并行执行与多团队扩展

一个 Agency 里的 Agent 不一定都要串行工作。比如在行业调研场景里，研究员可以同时开三路：一路查市场规模，一路查竞品动态，一路查用户评论。这三路互不依赖，完全并行可以提高数倍效率。在实现上，你可以把一个大研究任务拆成多个子任务，每个子任务绑定独立的 Agent 实例，用异步调用同时启动，最后汇聚结果。

并行带来了一个新问题：结果汇总时的冲突。两个研究员可能从不同信息源推出了相反的结论。这时候需要一个“仲裁整合器”——一般就是 Manager 或 Analyst Agent——负责过滤矛盾、统一口径、合并同类项。我在实操中倾向于，并行 Agent 的输出都统一为“观点+证据链”的结构，仲裁者便于对比，也容易发现谁的信息更可信、谁的数据来源更权威、哪条证据链有硬伤。

4.5 步骤五：接入外部系统并做可观测性设计

到这一步，Agency Agents 就已经不是做一个 demo 了，而是要接进真实业务链条。这时候必须考虑三件事：任务持久化、日志追踪、失败恢复。我用 LangChain 全家桶时，会通过LangSmith平台保存每次执行的完整 trace；如果用自建方案，建议至少把每个 Agent 的输入输出完整写入日志文件，并保存成 JSON。记录中要包含 Agent 名称、模型、参数、耗时、token 消耗等信息。这样后期优化时，你才查得到“到底是谁写的中间结论害了全流程”。

当然还要考虑与外部系统的集成方式。比较简单的方式是用 Webhook 暴露系统的输入输出接口，也可以把整个 Agency 包装成一个函数接口，由主程序异步调用。如果业务要求高可用，建议把任务队列放到 Redis 或 RabbitMQ 里，消费者由 Agent 团队担任，保证高并发下任务不丢失。

5. 编排模式与提示词设计：让 Agent 们真正协作起来

框架搭好了，Agent 也定义清楚了，但一个系统能不能真正干出漂亮活，最关键还是看编排模式和提示词设计。这两样东西如果搞不好，前面的架构再漂亮也没用。

5.1 编排模式的选型逻辑

我把常见的编排模式分成四种，分别对应不同的业务场景：

顺序流水线优先级最低，也最容易理解；层级分发是最接近“传统公司”的模式，Manager 负责拆任务和汇总结论；协作讨论会适合开放性问题，但成本高且需要明确收敛机制（比如“讨论 5 轮后必须输出结论”）；竞速模式适合筛选创意，但别把它当作常规方案。

我个人强烈建议，不要一上来就搞协作讨论会。开放式的多 Agent 对话很容易跑偏，而且非常烧 token。实际的系统里，第一次最好是顺序流水线，跑通之后再考虑往某个节点里加入少量并行或分支。等确认收益大于成本，再逐步扩展复杂模式。

5.2 提示词设计的六个经验准则

Agency Agents 的提示词跟单体 Agent 的提示词有一个本质区别：单体的提示词是在给模型“下指令”，团队模式的提示词是在给 Agent “定边界、定接口、定标准”。以下几个准则来自我多次踩坑之后的总结：

准则一：给每个 Agent 明确的输出格式。不要只告诉它“输出研究结果”，要告诉它“输出[来源, 关键数据点, 置信度]结构的列表”。格式一旦统一，下游 Agent 的解析成本低到可以忽略。

准则二：给每个 Agent 一个“禁止项”清单。比如“不要编造数据”“不要输出主观臆断的观点”“不要输出超出你职责范围的内容”。这类“negative prompt”可以有效降低 Agent 幻觉率。

准则三：所有 Agent 共享一份“项目背景说明”。在任务开始时，通过系统消息把项目背景同步给每个 Agent。很多协作问题其实来自信息不对称——Agent 不知道其他角色在做什么，但这并不是它的错，而是你传话没传清楚。

准则四：用“你正在接手某人的工作”来衔接上下文。交接信息明确时，下游 Agent 要对上游输出先做提炼和总结，再开始自己的工作。这可以避免下游 Agent 读入超长上游报告后上下文爆炸。

准则五：给每个 Agent 一个“兜底方案”。例如“如果信息源不可靠，注明信息缺口，不要强行填充内容”。兜底方案的价值在于，它让 Agent 敢于承认不知道，而不是硬编一个答案。

准则六：动态调整生成温度。发散型 Agent 用高温（Temperature 0.7-0.9），收敛型 Agent 用低温（Temperature 0.0-0.3）。这一点很多框架默认是做不了的，但你可以给每个 Agent 单独设参，强烈建议你在实际重构时加进去。同样是写代码，让“程序员 Agent”发散探索新方案和让“测试 Agent”严格检查 bug，参数设置应该完全不同。

5.3 从“伪协作”到“真协作”

最后再点一个实操中很容易犯的问题。很多人在做多 Agent 系统时，其实只是做了任务分块——每个 Agent 干自己的活，最后拼起来。这就像一群人在流水线上各自拧螺丝，看似是一个团队，其实没有真正的信息流动。真协作的标志是：下游 Agent 的产出能反向影响上游 Agent 的下一步行动。比如分析师发现研究员收集的数据缺少某个关键维度，它能自动通知研究员补充调研；写稿人发现核心结论之间存在矛盾，它能触发分析师二次验证。要实现这种反向链路，你的编排层必须支持“回环”和“动态任务路由”。这确实比单向流水线复杂，但它才是 Agency Agents 真正的价值所在。

6. 常见问题与排查技巧：落地过程中的深坑与解法

最后这部分我写的全部是实战型问题。做多智能体系统，几乎没有人能一遍跑通，你必然会遇到下面这些问题。

问题一：Agent 陷入无意义循环

现象：两个 Agent 反复对话，互相“客气”个没完，就是不停下来；或者 Manager 不停把任务派回给同一个 Agent，没有任何进展。解决方案：为所有对话任务设置最大轮次（比如 5 轮）；在每个 Agent 的提示词里写明“完成任务后立即输出[DONE]”；在设计 Manager 层时加入“终止条件判断”，一旦发现重复内容超过阈值就直接终止，并输出当前最优结果。

问题二：上下文被下游 Agent 灌满

现象：研究员角色一次性输出 2 万字的资料，分析师读入之后上下文直接爆掉，后续根本没法工作。解决方案：在任务描述中限定“单次输出长度上限”；要求所有 Agent 输出“摘要化、清单化、结构化”的结果；在上游输出后加入“内容压缩”节点，用一个小模型（比如本地部署的轻量模型）先把长文压缩到 1000 字以内的核心摘要，再传给下游。

问题三：工具权限被滥用

现象：数据分析师明明只需要做计算，却频繁调用网络搜索；又或者研究员把网页抓取工具当计算器用，结果自然是混淆。解决方案：严格按角色最小权限原则分配工具；每次工具调用都要在日志里记录“调用者、工具名、输入、输出”，便于回溯；如果框架支持，给每个工具加上“生命周期限制”，比如一个工具只允许被某几个特定角色调用。

问题四：多 Agent 输出的格式解析失败

现象：下游 Agent 期待 JSON，上游 Agent 却输出了 Markdown，导致解析报错，整个流程中断。解决方案：不要指望模型自己“遵守格式”。要用一个“输出清洗器”作为所有 Agent 的输出过滤器，统一把各种格式转成规范结构再传给下游；同时，在提示词中给出格式示例（Few-shot），一个例子胜过十句描述；如果上游 Agent 用的是流式输出，通常会导致格式不完整，尽量关闭流式，或者等输出结束后再清洗。

问题五：成本失控，token 消耗比预期高 3 倍以上

现象：本来预计跑一次调研任务花费 1 美元，结果实际跑了 4 美元，而且很多 token 消耗在无关紧要的对话上。解决方案：给每个 Agent 设置“单轮最大 token 上限”；用较小的模型处理辅助角色任务（比如摘要、格式化），大模型只留给核心推理；对并行执行的任务要控制并发，避免几十个 Agent 同时跑把账单烧爆。实测下来，给所有 Agent 的通信加上压缩策略，能省掉至少 40% 的 token 成本。

问题六：完全脱离主线任务，产出不符合预期

现象：Agent 写出了结构工整但内容严重偏离原始目标的报告；用户要的是“东南亚跨境电商趋势”，Agent 却重点写“全球电商物流”。解决方案：在任务开始的输入信息里，加入“关键词约束清单”和“禁止主题清单”；让 Manager 每完成一小节就做一次“目标对齐检查”，自动将输出与原始需求做余弦相似度对比，低于阈值立即打回；并且在最终交付之前，安排“终审 Agent”逐条对照原始需求做需求矩阵检查，缺失需求直接标红。

7. 最后分享一点我的个人体会

做了将近半年的 Agency Agents 项目，我最深的感受是：这套架构真正的难点不在写代码，而在系统设计思维。你需要像一个真正的公司管理者那样，想清楚谁负责什么、谁向谁汇报、什么信息需要透传、什么信息需要过滤、什么情况下要打回重做。你把这些问题想清楚了，技术实现不过是一两天的功夫；想不清楚，不管用什么框架都会做出一个“四不像”的失败系统。

很多人刚开始玩多 Agent 时会陷入一种误区——为了多 Agent 而多 Agent。任务明明一句话能问完，非要拆成 5 个角色互相开三轮会。我的建议是从最小的 2-Agent 团队开始（执行者+审查者），跑通真实任务，再一步步扩展角色数量。每次增加角色，都要先问自己一个问题：它是真的新增了能力，还是只是让系统变得更贵、更慢、更容易出错？

另外关于模型选型，我目前的经验是：不要吝啬给核心角色配一个好模型，但辅助性角色完全可以降级用便宜模型。大多数框架都支持每个 Agent 单独指定模型和参数，这会成为你成本控制的关键手段。截至我写这篇文章时，主流方案仍然是在 LangGraph 上自己画图最可控，在 CrewAI 上快速验证业务逻辑最方便，在 AutoGen 上做对话式多智能体研究最适合。

希望这些实践细节能帮你少走一些弯路。如果你正在做的项目刚好踩到上面说的某几个问题上，不妨先从编排模式和控制节流下手调——你会发现，多数团队协作问题的根源，不在单个 Agent 的能力上，而在整个“机构”的管理制度上。说到底，AI Agent 再怎么进化，它终究逃不开管理学的基本规律。