多Agent协作架构实战：用公司模型解决任务分配与状态同步

1. 从“一群 Agent”到“一家公司”：这个开源项目到底在解决什么问题

第一次看到“把一群 AI Agent 管成了一家公司”这个说法，我脑子里冒出来的画面是一堆聊天窗口在互相发消息，然后某个 Agent 跳出来说“这个需求排期到下个迭代”。听起来像段子，但真去把这类开源项目扒一遍之后，我发现它戳中的是一个特别现实的问题：当 Agent 从 1 个变成 10 个、50 个的时候，你靠什么让它们不打架、不重复劳动、不把任务丢进黑洞？

单个 Agent 的玩法大家已经很熟了——给个系统提示词，挂几个工具，接一个循环，能查资料、能写代码、能调接口。但只要你试过让两个以上的 Agent 协作，就会立刻撞上三堵墙：任务怎么分、状态怎么同步、结果怎么验收。这三堵墙不解决，Agent 数量越多，系统越像一锅粥，最后你还得自己当那个“人肉调度器”，盯着每个 Agent 的输出手动往下传。

这个开源工具的核心思路，就是把公司里那套已经被验证了几十年的组织架构，搬到了 Agent 编排上。它不再把 Agent 看成“一个更聪明的函数”，而是看成“一个有岗位、有职责、有上下级、有交付物”的员工。于是你会看到类似这样的角色划分：有负责拆解目标的“管理者”，有负责具体执行的“员工”，有负责质量把关的“审核者”，甚至还有负责跨部门协调的“项目经理”。每个 Agent 有自己的职责边界，任务在它们之间流转的方式，不是简单的函数调用，而是类似工单、汇报、审批的流程。

它解决的问题可以一句话概括：让多个 Agent 的协作从“临时拼凑”变成“有组织、有流程、可追溯”。适合谁来参考？如果你正在做多 Agent 编排、想让 AI 自动完成一条比较长的任务链、或者你已经被“Agent 之间互相甩锅”折磨过，那这类项目值得你花时间研究。哪怕你最后不用它，它里面关于角色设计、任务状态机、上下文传递的思路，也能直接搬到自己的系统里。

我下面会按“整体设计思路 → 核心机制拆解 → 实操落地 → 踩坑排查”这条线来展开，尽量把每个设计决策背后的“为什么”讲清楚，而不是只告诉你“它有个 Manager Agent”。

2. 整体设计思路拆解：为什么是“公司”而不是“流水线”

2.1 流水线模型的天花板在哪里

大部分人多 Agent 的第一反应是搭流水线：Agent A 输出给 Agent B，B 输出给 C，像工厂传送带一样。这个模型在任务步骤固定、每步输入输出明确的时候非常好用，比如“抓取数据 → 清洗 → 分析 → 出报告”。但它有两个硬伤。

第一个硬伤是步骤不可预知。真实任务往往不是一条直线，而是带分支、带回退、带循环的。比如写一份行业分析，你可能先查资料，查完发现资料不够要换方向，换完方向发现某个数据需要重新验证，验证完又要回头改结论。流水线一旦定死，遇到这种回退就得靠人重新触发，自动化程度直接打折。

第二个硬伤是没有“谁对结果负责”的概念。流水线里每个节点只管把自己的输出丢给下一个，至于最终交付物质量如何，没人兜底。Agent B 拿到 A 的烂输出，它不会说“这不行，打回去重做”，它只会硬着头皮往下算。结果就是错误一路放大，到最后你拿到一个看起来完整、实际上没法用的东西。

2.2 公司模型的核心优势：职责、汇报与验收

公司模型恰好补上了这两块。它引入的第一个东西是角色职责。每个 Agent 不是“第 N 步处理器”，而是“某个岗位”。岗位意味着它知道自己该干什么、不该干什么、对什么负责。管理者 Agent 的职责是拆解目标和分配任务，它不需要会写代码；执行 Agent 的职责是完成具体工单，它不需要操心整体排期。职责一清晰，任务分配就有了依据，不会出现“这个活到底谁干”的扯皮。

第二个东西是汇报关系。执行 Agent 完成后不是直接把结果丢给下一个执行者，而是先汇报给管理者，由管理者决定下一步是继续、是转交、还是打回。这个“汇报”动作看起来多了一步，但它带来的是可控性。管理者手里握着全局状态，它能判断当前进度是否偏离目标，能决定要不要插入新的子任务，能在某个环节卡住时换一个执行者重试。

第三个东西是验收机制。公司里有 QA、有审核、有签字，Agent 系统里对应的就是独立的审核角色。审核 Agent 不参与生产，只负责按标准检查交付物，不达标就打回。这个设计把“质量”从“祈祷上游别出错”变成了“流程里自带一道闸门”。

提示：公司模型不是银弹。它的代价是通信开销变大、延迟变高。任务越简单，这套架构越显得笨重。所以选型时要先判断你的任务复杂度，别为了“看起来高级”硬上多角色。

2.3 任务状态机：整个系统的骨架

不管角色怎么设计，底层都得有一个东西来记录“现在进行到哪了”。这类项目通常会用一张任务表或者一个状态机来管理，每个任务有明确的状态，比如待分配 → 进行中 → 待审核 → 已完成 / 已打回。状态流转由管理者 Agent 驱动，每次流转都伴随一次上下文更新。

为什么状态机这么关键？因为它是多 Agent 协作的“唯一事实来源”。没有它，每个 Agent 各自维护一份记忆，时间一长必然对不上。有了它，任何 Agent 想知道“现在什么情况”，都去读同一份状态，不会出现 A 以为任务完成了、B 以为还在做的尴尬。

我实测下来，状态机的粒度要把握好。太粗（只有“进行中/完成”）会导致管理者无法精细调度；太细（每个小动作一个状态）会让状态表爆炸，维护成本飙升。比较舒服的粒度是按交付物划分状态，一个交付物走完“分配→执行→审核→归档”就算一个闭环。

3. 核心机制深度解析：角色、通信与上下文传递

3.1 角色设计：管理者、执行者、审核者怎么分工

角色设计是这类项目的灵魂，也是最容易设计翻车的地方。我见过一些实现，角色划分得很细，什么“规划者”“研究员”“写作者”“校对者”“总结者”一大堆，结果 Agent 之间光是在“我该不该接这个活”上就消耗了大量 token。角色不是越多越好，关键看职责边界是否清晰、是否存在职责重叠。

比较稳的一套最小角色集是三个：管理者（Manager）、执行者（Worker）、审核者（Reviewer）。管理者负责接收顶层目标、拆解成子任务、分配给执行者、跟踪进度、处理异常；执行者负责领工单、干活、交结果；审核者负责按预设标准检查结果，给出通过或打回的意见。

这三个角色的提示词写法差别很大。管理者的提示词重点在“拆解”和“判断”，要让它学会把一个模糊目标拆成可执行的原子任务，还要让它学会在收到执行结果后判断“够不够、要不要继续”。执行者的提示词重点在“聚焦”，要限制它只处理当前工单，不要越界去操心全局。审核者的提示词重点在“挑刺”，要给它明确的检查清单，否则它很容易当老好人，什么都放行。

注意：审核者 Agent 最容易形同虚设。如果你不给它具体的验收标准，它大概率会输出“看起来不错，通过”。解决办法是把验收标准写成可勾选的清单，比如“是否包含数据来源”“结论是否有至少两个论据支撑”“格式是否符合模板”，让它逐条打勾。

3.2 通信机制：Agent 之间到底怎么“说话”

Agent 之间的通信方式，直接决定了系统的稳定性和可调试性。常见的有三种：共享内存/黑板模式、消息传递模式、以及基于任务队列的模式。

共享内存模式是所有 Agent 读写同一块状态存储，优点是简单直接，缺点是并发写容易冲突，而且很难追踪“谁在什么时候改了什么”。消息传递模式是 Agent 之间直接发消息，优点是解耦，缺点是消息一多就变成蜘蛛网，调试时根本理不清。基于任务队列的模式是折中方案：Agent 不直接对话，而是往队列里放任务、从队列里取任务，所有交互都通过任务这个中介完成。

这类“公司化”项目大多采用第三种，因为它天然契合“工单”的概念。管理者往队列里放一个工单，执行者取走、完成、把结果写回工单，管理者再取回工单决定下一步。整个过程有据可查，每个工单就是一条完整的审计线索。

我个人的经验是，通信内容要结构化，不要传自然语言大段文本。工单里应该包含明确的字段：任务 ID、任务描述、输入上下文、期望输出格式、截止条件、当前状态。自然语言只用在“任务描述”这一个字段里，其余全部结构化。这样解析起来稳定，不会因为某个 Agent 措辞变化导致下游解析失败。

3.3 上下文传递：怎么让 Agent 知道“前因后果”

多 Agent 系统里最烧脑的问题之一，就是上下文怎么传。每个 Agent 的上下文窗口有限，你不可能把整个任务历史都塞给它。但如果你只给它当前工单，它又可能因为缺少背景而做出错误判断。

常见的解法是分层上下文：全局上下文（整个任务的目标、约束、已完成的关键结论）放在一个共享区，每个 Agent 都能读到摘要版；局部上下文（当前工单的详细输入）只给处理这个工单的 Agent。管理者负责维护全局上下文的摘要，每次有重要结论产生就更新一次。

这里有个实操技巧：全局上下文用“结论列表”而不是“对话历史”。对话历史又长又杂，Agent 读起来费劲还容易抓错重点。把已经确认的结论一条条列出来，比如“目标用户是中小企业”“预算上限 5 万”“必须在本月底前交付”，Agent 一眼就能抓住关键约束。

另外，上下文传递要防“信息衰减”。任务经过几手之后，最初的约束很容易被丢掉。解决办法是在每个工单里强制带上“原始目标”字段，让每个执行者都能看到最终要达成什么，而不是只看到自己这一小步。

4. 实操落地：从零搭一个最小可用的多 Agent 协作系统

4.1 环境准备与技术选型

要复现这套东西，你不需要一上来就搞很重的框架。最小可用版本用 Python 加一个轻量状态存储就能跑起来。核心依赖就三块：Agent 运行时（调用大模型的 SDK）、状态存储（SQLite 或 Redis 都行）、任务调度循环（一个 while 循环加状态判断）。

选 SQLite 还是 Redis，取决于你的并发量。单机跑、任务量不大，SQLite 足够，还省得部署。如果要多个执行者并行取任务，Redis 的原子操作会更省心。我一开始用 SQLite，后来执行者一多就遇到锁表问题，换成 Redis 的 list 结构做队列就顺了。

大模型调用这块，建议把“模型调用”封装成一个统一函数，传入提示词和上下文，返回结构化结果。这样后面换模型、加重试、加限流都只改一个地方。别在每个 Agent 里各写各的调用逻辑，后期维护会想哭。

4.2 定义任务数据结构与状态流转

先把任务的数据结构定下来，这是整个系统的地基。一个工单至少要有这些字段：

字段名	类型	说明
task_id	string	全局唯一 ID
parent_id	string	父任务 ID，用于追溯拆解关系
description	string	任务描述，自然语言
input_context	json	执行所需的输入
expected_output	string	期望输出格式说明
status	enum	pending/running/reviewing/done/rejected
assignee	string	当前负责的 Agent 角色
result	json	执行结果
review_comment	string	审核意见
created_at	timestamp	创建时间
updated_at	timestamp	更新时间

状态流转规则要写死，不要让 Agent 自由发挥。推荐这样：pending由管理者创建；执行者取走后变running；执行完变reviewing；审核通过变done，不通过变rejected并附上意见；rejected的任务由管理者决定是重新分配还是修改描述后重试。

提示：状态流转一定要有“超时”处理。某个任务卡在running太久，管理者应该能检测到并介入，否则整个流程会静默死掉。我一般设一个阈值，超过就标记为异常并通知管理者重新调度。

4.3 管理者 Agent 的提示词与拆解逻辑

管理者是整个系统的大脑，它的提示词质量直接决定拆解质量。我试过好几版，最后稳定下来的结构是这样的：先给角色定位（“你是一个任务管理者，负责把目标拆解成可独立执行的子任务”），再给拆解原则（“每个子任务必须能由一个执行者独立完成，输入输出明确，不依赖其他子任务的中间状态”），最后给输出格式（要求返回 JSON 数组，每个元素包含 description、input_context、expected_output）。

拆解逻辑上有个坑：管理者容易拆得太粗或太细。太粗，执行者拿到一个“写一份报告”这种模糊任务，无从下手；太细，拆出几十个琐碎步骤，调度开销比干活还大。我的经验是给管理者一个约束：“每个子任务的工作量控制在单个执行者一次能完成的范围内，通常对应一个明确的交付物”。用“交付物”作为拆解粒度，比用“步骤”更稳。

管理者还要负责动态调整。执行结果回来后，它要判断：这个结果是否满足当前子任务的目标？如果满足，是否触发下一个子任务？如果不满足，是打回重做还是换一种拆法？这部分逻辑建议写成显式的判断分支，而不是全丢给模型自由决定，否则行为会很不稳定。

4.4 执行者与审核者的协作闭环

执行者的提示词要“窄”。只告诉它当前工单是什么、输入是什么、期望输出是什么，别给它全局目标，否则它会自作主张扩大范围。执行者完成后，把结果写回工单的 result 字段，状态改为 reviewing。

审核者拿到工单后，按预设的检查清单逐条核对。检查清单要具体，比如“输出是否包含至少三个数据点”“每个数据点是否标注来源”“结论是否与数据一致”。审核者返回结构化结果：通过或不通过，不通过时给出具体哪一条没达标。

这里有个提效技巧：审核不通过时，把审核意见直接写进工单，重新分配给原执行者。执行者带着“上次哪里没做好”的上下文重做，比重新开一个工单效果好得多。我实测下来，带反馈的重试成功率明显高于盲目重试。

4.5 一个完整任务的流转实录

假设顶层目标是“调研某类开源项目的活跃度并输出简报”。管理者先拆成三个子任务：收集项目列表、抓取每个项目的活跃指标、汇总成简报。第一个子任务分配给执行者 A，A 返回一份项目清单，审核通过。第二个子任务因为涉及多个项目，管理者进一步拆成并行的小任务，分给执行者 B、C、D。其中一个执行者返回的数据缺了关键字段，审核打回，带上意见重做，第二次通过。第三个子任务汇总时，管理者发现某个项目的数据缺失，临时插入一个补查任务。最终简报产出，审核通过，状态置为 done。

整个过程里，管理者 Agent 被调用了大概七八次，执行者被调用了十几次，审核者五六次。token 消耗主要集中在管理者身上，因为它每次都要读全局上下文。这也是为什么全局上下文要做摘要——不然管理者的成本会失控。

5. 常见问题与排查技巧实录

5.1 Agent 互相甩锅、任务死循环怎么办

这是最常见的问题。表现是任务在几个 Agent 之间来回转，状态反复在 running 和 rejected 之间跳，就是到不了 done。根因通常是验收标准不明确或者打回意见太模糊。执行者不知道到底要改成什么样，只能瞎猜，猜完还是不过，就循环了。

排查思路：先看审核意见，如果意见是“不够好”“再完善一下”这种，那就是标准问题，要把检查清单写具体。再看是不是同一个任务被反复打回超过三次，如果是，强制升级给管理者，让它要么修改任务描述，要么换执行者，要么直接标记为“需要人工介入”。给重试次数设上限是必须的，不然系统会无限空转烧钱。

5.2 上下文丢失导致结果跑偏

任务链一长，最初的约束就容易丢。比如最开始说“面向非技术读者”，传到第五个执行者那里变成了技术文档风格。解决办法前面提过，在每个工单里强制带“原始目标”和“关键约束”字段。另外，管理者在每次分配任务前，应该把全局约束重新注入一次，别指望执行者自己去翻历史。

我还会在审核清单里加一条“是否符合原始约束”，让审核者专门盯这个。多一道检查，跑偏的概率就低很多。

5.3 Token 成本失控的优化手段

多 Agent 系统烧 token 是出了名的。优化手段有几个方向：减少不必要的调用、压缩上下文、用更便宜的模型处理简单任务。

减少调用方面，管理者的判断逻辑能写成规则的就别调模型。比如“任务状态是 rejected 且重试次数小于 3”这种判断，用代码写就行，没必要问模型。压缩上下文方面，全局上下文只保留结论，不保留过程。模型选择方面，执行者如果只是做格式转换、字段提取这种活，用便宜的小模型完全够，把贵模型留给管理者和审核者。

我做过一个粗略对比，把简单执行任务换成小模型后，整体成本降了大概六成，质量没有明显下降。当然这取决于你的任务类型，复杂推理任务还是得用能力强的模型。

5.4 常见问题速查表

问题现象	可能原因	排查动作	解决方向
任务卡在 running 不动	执行者异常退出或超时	查执行日志、看是否有报错	加超时检测，超时重新入队
反复打回死循环	验收标准模糊	看审核意见是否具体	细化检查清单，设重试上限
结果偏离原始目标	上下文丢失	检查工单是否带原始约束	强制注入全局约束字段
token 消耗异常高	上下文过长或调用过频	统计各角色调用次数	压缩上下文，规则判断替代模型调用
多个执行者结果冲突	任务拆分有重叠	检查子任务边界	重新设计拆解粒度，确保互斥
审核形同虚设	检查清单缺失	看审核通过率是否接近 100%	补充可勾选的验收标准

5.5 几个我踩过的坑

第一个坑是过早追求并行。一开始就上多个执行者并行跑，结果状态同步没做好，两个执行者改了同一个工单，数据直接错乱。后来改成先串行跑通，确认状态流转没问题，再逐步放开并行，才稳定下来。并行不是不能上，是得先把状态管理做扎实。

第二个坑是提示词写得太“聪明”。我一开始给管理者的提示词写得很复杂，希望它能处理各种边界情况，结果它反而经常跑偏，输出格式都不稳定。后来把提示词砍到只保留最核心的几条规则，行为反而可预测了。Agent 提示词这东西，约束比能力更重要，你限制得越清楚，它表现越稳。

第三个坑是忽略日志。多 Agent 系统出问题时，如果没有详细的调用日志，你根本不知道是哪一步、哪个 Agent、哪次调用出的问题。我后来强制每次模型调用都记录输入输出和耗时，排查效率提升了一大截。这个投入绝对值得，别省。

6. 这套架构还能怎么扩展

把基础版本跑通之后，能扩展的方向其实挺多。一个方向是引入“记忆”，让系统把历史任务的成功经验和失败教训存下来，下次遇到类似任务时管理者能参考。另一个方向是动态角色，根据任务类型临时生成新的角色，而不是固定那几个。还有一个方向是人机混合，在关键节点插入人工审批，让 AI 处理大部分流程，人只在重要决策上把关。

我个人比较看好的是把审核标准也交给系统自己迭代。每次打回都记录原因，积累一段时间后，管理者能从中总结出“哪类问题最常出现”，反过来优化拆解策略和提示词。这相当于让系统自己给自己做复盘，长期看能显著提升一次通过率。

不过话说回来，架构再花哨，核心还是那三件事：任务分得清、状态管得住、结果验得了。把这三件事做扎实，哪怕只有三个 Agent，也能跑出很稳的效果。反过来，这三件事没做好，堆再多角色也只是把混乱放大。我在实际项目里的体会是，先别急着加 Agent，先把单个工单的生命周期跑顺，把状态机和日志做扎实，后面加角色、加并行都是水到渠成的事。