1. 先说一个失败经历单个智能体为什么撑不起“一个项目”前段时间在搭建一套行业情报整理流程时我犯了个很典型的错误以为只要把提示词写细一个智能体就能完整地承担从数据采集、交叉验证到结论撰写全流程。结果连续三轮产出都很糟糕——前期的调研结论和后期建议互相矛盾格式五花八门最致命的是每次业务口径调整我都要把整套提示词推倒重来。正是这次反复碰壁让我彻底转向了agency-agents模式用多个职责明确的智能体组成一个微型“代理机构”对外统一承接目标对内按角色分工、按工单交接、按标准验收而不是让一个智能体孤军奋战。如果你也在把大模型接进真实业务准备把 Agent 从“能聊天”推进到“能交付”那这篇文章值得看完。它不打算重复官方概念只从我自己的项目复盘出发拆解agency-agents背后真正核心的设计取舍角色怎么分、信息怎么传、质检怎么做、成本怎么算以及我在实际运行中踩过的几个真实坑。1.1 单智能体“包打天下”的三个死穴先说清楚问题出在哪。单个智能体做长流程任务通常会卡在三个地方第一是上下文预算不够。表面看窗口很大但长任务里真正稀缺的其实是“有效注意力”。当研究报告写到中后段模型对最早期信息和业务约束的“记忆”会被大量中间内容冲淡于是出现前面说过的现象第一步调研产出的结论到第三步写建议时已经对不上了。第二是角色冲突。一个 agent 要同时扮演调研员、分析师、撰稿人、审校员这个角色的行为规范会互相干扰。你让它“数据要严谨”写出来的文案就偏保守你让它“结论要鲜明”数据部分可能就开始拍脑袋。其实不是模型能力不够而是“一人分饰多角”这个设定本身就违反了大模型指令遵循的边界。第三是自审失效。模型在同一个上下文里既当运动员又当裁判它对自己产出的评价高度自洽很难发现真正的逻辑漏洞。就像写代码的人检查自己的代码总会下意识绕开已知的坑。我后来才意识到让一个 agent 自己给自己挑毛病天然就是个伪命题。1.2 从“单人模式”到“机构模式”三种组织形态怎么选agency-agents这个词字面上就是“代理机构”。把多个智能体组织成一个稳定协作的小型团队就像开一家工作室至少有三套常见的组织方式平行作坊式多个同质化 agent 并行处理同类子任务比如批量改写、批量数据标注。每个 agent 接到的工单完全独立做完后汇总。这套模式最简单适合处理量大、边界清晰的活。层级公司式一个 Coordinator协调者负责任务拆解和调度多个 Specialist专家分别产出最后还有一个 Reviewer评审者把关。我后面用的主要是这套因为它最接近真实项目团队的分工逻辑尤其适合目标本身需要拆解成不同专业领域的场景。流水线工厂式上游 agent 的产出直接成为下游 agent 的输入每个角色只做一道工序。比如采集 agent → 清洗 agent → 分析 agent → 排版 agent。好处是产出稳定坏处是单点故障会沿链路放大。用生活类比就是找三个人分别写三段并拼起来是一个极端设一个项目经理、三个模块负责人和一个测试主管是另一个极端。大部分需要质量保证的业务场景层级式会比流水线式更合适因为层级式有“返工回路”流水线一般没有。1.3 先别急着下结论agency-agents不只是“多个 agent”有朋友看完上面那段后说“这不就是 multi-agent 吗”还真不是。普通的多智能体并发调用通常是好几个 agent 看到同一份请求各自输出后拼在一起本质上是“几个专家各说各话”。而agency-agents强调的是组织结构本身——有发起方、有执行方、有检验方各方通过约定好的“契约”协作而不是靠自由发挥。我后来把两者放在一起做了张对照表清晰一些维度多智能体并发代理机构协作任务拆解不拆或简单分片按专业领域/工序设计角色定义靠提示词临时指定固定角色 固定职责边界信息传递共享完整对话历史结构化工单 数据引用质量闭环基本没有Review 后可以定向返工可复现性弱换一次随机种子结果就不同强可回放每一步输入输出这个区别决定了系统的稳定性。很多团队做 multi-agent 失败并不是模型不行而是“组织”没设计好——没有契约、没有验收、没有回溯能力。而agency-agents模式真正的价值就是把这套组织能力补上。2. 角色三角与任务工单把代理协作契约化的两个关键设计很多人在设计多智能体协作时第一步就走歪了先纠结角色数量觉得角色越多越专业或者把每个角色的提示词写得特别长试图靠“描述得多”来让模型懂规矩。我实测下来角色数量控制在 3 到 5 个最舒服角色描述里行为约束比能力描述更重要。这里先强调一个原则角色是“契约”的骨架不是“人设”。你不需要让 Coordinator 听起来像个资深项目经理你需要告诉它“你只负责任务拆解不产出内容”。规则写得越像边界条款系统越稳定。2.1 为什么是 Coordinator、Specialist、Reviewer 三个角色我最开始参考了很多资料最后稳定下来只保留了三个角色因为这三者正好覆盖了“目标、产出、质量”三段闭环Coordinator只做两件事——把模糊目标拆成可执行的工单以及把结果合并成最终交付物。它不直接写内容避免“协调者下场干活”导致没人真正做计划。Specialist负责一个领域的具体产出。可以按领域拆成多个比如调研专员、撰写专员、代码专员。每个 Specialist 只认自己职责范围内的工单不做跨领域判断。Reviewer对着验收标准做检查产出“通过 / 返工”的结论并给出可执行的修改意见。它不是夸夸其谈的评论员更像合同里的验收方。这个三角结构最像现实中的广告公司模式项目经理Coordinator对接甲方目标文案和设计Specialist干活创意总监Reviewer把关。对比两种极端配置只有 Coordinator Specialist就是典型的“无人质检”系统会自信地输出错误结果只有 Specialist Reviewer没人拆目标任务一复杂就崩。所以三角缺一不可。2.2 任务工单让 agent 协作从“闲聊”变成“契约”确定了角色之后最关键的一步是确定它们之间怎么传话。我强烈建议用结构化“任务工单”代替自由对话。你想象一下两个真人协作如果全靠微信聊天重要信息很快会被刷上去如果有一份任务单子写着“你要做什么、输入在哪、验收标准是什么”双方都会清醒得多。Agent 之间也是同理。下面是我一直在用的工单模板你可以直接抄{ ticket_id: T-20241125-001, title: 某竞品定价策略摘要, role: researcher, objective: 基于给定数据源给出目标产品近18个月的定价变化摘要, input_refs: [source_a, source_b], constraints: { output_format: markdown_table, max_words: 800, must_mention: [促销周期, 版本差异] }, review_criteria: [ 引用来源可追溯, 数据口径一致, 结论不超出数据范围 ], rework_count: 0, feedback: }字段背后的设计逻辑我逐一说说objective必须是一个动作对象边界不能写“分析一下”。写得太模糊Specialist 就会自由发挥。input_refs只放数据引用对象不直接把全文塞进去。这样每个 Specialist 按需取数不会因为接收了别人的长报告而上下文超载。constraints是可硬性校验的格式限制。模型在这个字段上最容易犯迷糊所以尽量少用“请用专业的语气”这种描述性约束改成可检查的字段。review_criteria是 Review 的标准。Reviewer 拿着它逐条打钩比自由打分靠谱得多。rework_count和feedback是返工机制的载体专门用来防止“无限循环改稿”。为什么要用工单而不是对话历史核心原因是结构记忆。对话历史是一维的时间流工单是多字段的可寻址记录。后续不管排查问题、重跑任务、还是做局部替换都可以只操作一个工单而不用从头到尾看聊天记录这在你需要支持多轮迭代时价值巨大。2.3 质检不是“看一眼”而是一张可打钩的合同好多人设计完 Coordinator 和 Specialist 就开始跑Reviewer 只是象征性地加一个。结果 Review 环节变成了“有道理但我觉得这里可以更好”——这种意见给不到点子上返工一次后广告不敢再改。我后来给 Reviewer 立了规矩只能基于review_criteria逐条“通过 / 不通过”不通过的必须给具体修改指令不能只给方向。举个例子如果 Review 的结论是“数据口径不一致”这不是可执行的反馈Specialist 仍然不知道怎么改。正确的反馈应该类似“第三段引用的是零售口径第一段是出货口径请统一为零售口径并重新核对表格编号”。一旦 Reviewer 提出这种级别的问题返工一次的成功率就会显著提高。3. 一个能跑起来的极简实现与五步落地路径理论说了一堆下面讲实现。我这套骨架在项目里跑了好几个月虽然不能说大而全但胜在可直接落地团队规模 3 到 8 个 agent 的场景完全够用。3.1 技术选型为什么我推荐“轻框架、重流程”很多朋友一听多智能体第一反应就是上重框架。我的建议恰恰相反前两个项目阶段请把“流程”看得比“框架”重要。所谓轻框架就是自己用一个主循环把各角色串起来用 JSON 文件当状态存储先跑通再谈优化。原因有三。第一重框架的编排能力比如图形状态管理在角色少、流程固定时是在叠复杂度第二自己的主循环所有逻辑都是可见的出了问题直接在日志里定位第三模型调用、重试、token 计费这些细节都要在自己手里过一遍才有感知。等流程真正稳定了、需要并发了再考虑要不要把底层换掉也不迟。落到具体技术栈上我的配置是模型统一走某个主流推理 API框架层直接用 Python 的 dataclass dict 组装工单状态持久化用一个本地 JSON 文件。没有引入任何重量级中间件。这种组合的效果是连最小部署环境都能跑排查问题也快。3.2 一个可以直接跑起来的最小骨架核心代码思路不难一句话概括主循环负责“拆工单 → 分派给 Specialist → 交给 Reviewer 检查 → 不通过就返工”。下面是简化版可以直接运行调试class AgentAgency: def __init__(self, coordinator, specialists, reviewer): self.coordinator coordinator self.specialists {s.role: s for s in specialists} self.reviewer reviewer def execute_ticket(self, ticket): specialist self.specialists[ticket[role]] result specialist.run(ticket) verdict self.reviewer.check(ticket, result) if verdict[state] rework and ticket[rework_count] 2: ticket[rework_count] 1 ticket[feedback] verdict[feedback] result self.execute_ticket(ticket) return result def run(self, brief): planning self.coordinator.plan(brief) outputs [] for ticket in planning[tickets]: ticket[rework_count] 0 ticket[feedback] outputs.append(self.execute_ticket(ticket)) return self.coordinator.consolidate(outputs)这段代码里有三个关键点分别对应三类最常见的坑rework_count 2是返工闸门。没有它遇到 Review 条件写得太苛刻或者两个 agent 风格不合任务会无限循环烧光 token 预算。specialist.run(ticket)只接收工单不接收完整对话历史。这从一开始就确保两个 Specialist 之间的信息只能通过结构化字段传递不会互相污染。coordinator.consolidate(outputs)是最后一道整合步骤它能检查所有子结果是否完整、格式是否统一而不是简单地把文本拼接起来。这个骨架跑通后你再根据实际需求加日志、加缓存、加并发分支都会有章可循。3.3 小团队落地五步法从零开始把这个系统放进业务我推荐按下面五步走每一步都不要跳过先定义交付物再定义角色。连最终产出长什么样都没想清楚角色一定拆不对。我一般会先把一个真实案例的人工产出物拿来看把它拆成可以并行处理的段落。角色克制起步。刚开始只建 Coordinator 一个 Specialist Reviewer跑通一两条真实任务后再观察 Specialist 是不是又忙又乱如果是就把它按领域拆成两个而不是一开始就铺三个。工单先于代码。动手写任何类之前先把 3 到 5 个任务的标准工单模板手写出来拿给做业务的人看一遍确认字段没有歧义再写代码。这一步能省掉很多返工。全量落盘。每个工单的输入、输出、Review 意见、返工次数全部写文件哪怕只是本地 JSON。原因很简单没有数据的排查就是瞎猜有数据才能定位是拆解的问题还是执行的问题。人工抽检哨兵。上线初期哪怕 Reviewer 再强也一定要留一个真实业务的人抽检最后输出。AI 质检的盲区非常隐蔽人工兜底是必要的“安全垫”。4. 三个故障案例的完整排查链路串味、风暴与自证式质检再完美的设计实际运行中也会出意外。我把自己在真实环境里踩过的三个坑完整梳理出来这些故障极具代表性。4.1 上下文“串味”最隐蔽的任务漂移事故有一回我做行业竞品分析一个专项 Specialist 负责查历史价格另一个负责写渠道策略。跑出来的结果里写渠道策略的 agent 居然在告诉读者“历史价格的波动主要是由大促节奏决定的”而它应该讨论的是渠道覆盖策略明显任务目标漂移了。排查时我把日志逐条拉出来对比发现问题出在信息传递方式上。最初实现为了让 Specialist 有足够背景把前面所有 agent 的聊天记录直接塞进了下一个 agent 的上下文。结果排名靠前的数据说明文字量非常大把策略 agent 给“带偏”了——它误以为自己是数据解读员开始复述前面的内容。这个坑本质上是“共享上下文”造成的注意力分配失控。修复方式很简单让每个 Specialist 只接收工单和它input_refs对应的数据对象至于其他 Specialist 在哪一步做了什么一概不看。Coordinator 是唯一一个看全貌的角色但它只负责调度和汇总不参与具体内容生成。改完之后任务漂移的问题基本绝迹。4.2 工具调用风暴撞上死循环的门卫另一次事故更尴尬。某个 Specialist 接到检索任务后外部接口返回空结果。按人类直觉发现数据源不可用就应该如实上报或者换条路但这个 agent 偏偏“执拗”地反复重试同一接口在一个空结果上循环了 12 分钟烧掉的 token 是正常任务的十几倍最后还被主流程当成超时任务挂了。排查链路也很清晰看日志发现同一条 HTTP 请求被打了十几次且每次都指向同一个空响应。根源是模型被赋予了“自主调用工具”的能力却没有为“工具失败”设定退出条件。修复方案是给所有工具调用加“全局预算与熔断门卫”市面术语叫 Circuit Breaker。具体到代码层面就是给每次调用设一个计数器同一工单内某个工具重试超过 3 次就强制短路并生成一条异常报告交给 Coordinator 决策。另外我还加了一个全局 token 上限所有 Specialist 共享一个预算池哪个角色都无法独占。自此之后风暴类故障再没出现过。4.3 “自证式质检”陷阱让同一个模型审自己等于没审我最早以为加了 Reviewer 就万事大吉后来发现同一个大模型既执行任务又做质检存在一个严重盲区模型对自己的生成风格和错误倾向高度自洽。它写出来的数据口径错误Review 时也会觉得“根据上下文这个口径是对的”。这不是模型笨而是它更倾向于确认自己之前的输出而不是质疑。排查后我还发现一个放大因素当任务描述越长、内容越专业模型对错误的自我感知就越差。比如一份行业术语密集度很高的报告Reviewer 会倾向于给出“论证充分、数据详实”的评价实际里面可能有好几个术语被混淆。破解这个陷阱要分三层做第一是给 Review 环节设置强制可校验字段比如引用来源是否存在、表格列数与标题是否一致、关键词是否覆盖这些是硬校验模型只能逐条打钩无法自由发挥第二是 Review 模型和执行模型要错开有条件的话用不同的模型提供方或模型路线至少也要用不同的提示词体系破坏模型的“自证”惯性第三是设置人工抽检站流程稳定后每天抽 5% 到 10% 最后交付物用真实业务人员的判断兜底。5. 多智能体的成本账与适用边界什么时候值得上写到这里你可能会有一个疑问又是多个角色、又是工单、又是返工这成本得往上涨多少这个问题问得很实在。agency-agents不是银弹它是一笔需要先算清楚的投资。5.1 三个看不见的账单第一张是 token 账单。同样一个任务单 agent 可能只要 30k token换成一个 3 角色机构总量往往冲到 120k 以上。原因不只是多跑几次而是每个角色都要把工单、产物、评审意见重读一遍返工还要再读一遍。用户要用机构模式就得预先接受 3 到 5 倍的 token 成本。第二张是延迟账单。流水线串行时端到端耗时为各 agent 运行时间之和即便用上平行分支Coordinator 的合并和 Review 也是额外环节。agent 数量超过 4 个以后串行链路会明显变得“没办法实时交互”用户反馈体验非常受影响。第三张是维护账单。改动一个输出字段常常要连带改三份提示词和两处工单 schema。没有良好的版本控制意识系统会在三周内“忘记自己当初为什么这样设计”。5.2 用一张筛选表决定“要不要上机构模式”任务特征建议模式简单问答、短文本总结单 agent步骤清晰、边界明确的批处理平行作坊式多个同质 agent 并行需要多角色视角、交叉验证层级公司式Coordinator Specialist Reviewer端到端内容生产、工序固定流水线工厂式需求本身模糊、没有稳定交付物先不要上 agent 机构先人工梳理流程我后来形成一条经验只要任务本身不是“多专家协作形态”就别硬套agency-agents。如果最终交付物只有一段话多智能体纯属浪费只有当交付物需要多个模块协同、互相引用、互相校验才值得动用机构编排。5.3 十秒自检清单动手前自问四个问题答案都是“是”再继续这个任务有稳定的交付物模板吗有可以量化的质量验收标准吗团队能接受 2 到 5 倍的 token 成本和明显增加的处理延迟吗有没有真实业务的人愿意做最后一轮抽检这四个问题只要有一个回答“否”我建议你先退回去把单 agent 或简单流程用熟再回来考虑多智能体机构。6. 沉淀下来的三个实操原则可观测、小作坊、人工抽检跑了大半年agency-agents相关项目之后我最大的感受是这个模式真正的难点不在“多模型编排”的技术而在“组织设计”的取舍。最后分享三条我反复验证过的实操原则算是一个收尾第一可观测性比“智能”本身更重要。多智能体系统里最贵的不是 token而是排查问题的时间。凡是能把工单、产物、评审意见落盘落日志的地方一定要落。宁可让日志丑一点也不要在故障时靠猜。第二用小作坊模式先跑通流程再扩成公司。很多项目一开始就设计六七个角色结果大部分时间花在协调角色之间的矛盾上。我先用最小三角跑通一个真实任务再观察哪个角色是瓶颈然后拆出去这个过程是“组织演进”不是“一步到位”。第三Reviewer 的人工抽检配额绝不能取消。再聪明的模型质检也有盲区尤其涉及行业知识、术语边界的时候。我在流程里固定保留 5% 的人工抽检配额这部分的成本不能省。这不是对模型的不信任而是对工程交付的基本尊重。如果你正准备从单个 agent 走向多智能体协作希望这篇文章能帮你少走几趟弯路。agency-agents不是万能的但当你面对的是一个真正需要多角色协作、质量闭环和结构记忆的任务时这套方法论会给你非常扎实的支撑。 
长河君 · 2026/10/10 4:32:40 · 阅读 1.2k 从单智能体到代理机构：多智能体协作与质量闭环实践
1. 先说一个失败经历单个智能体为什么撑不起“一个项目”前段时间在搭建一套行业情报整理流程时我犯了个很典型的错误以为只要把提示词写细一个智能体就能完整地承担从数据采集、交叉验证到结论撰写全流程。结果连续三轮产出都很糟糕——前期的调研结论和后期建议互相矛盾格式五花八门最致命的是每次业务口径调整我都要把整套提示词推倒重来。正是这次反复碰壁让我彻底转向了agency-agents模式用多个职责明确的智能体组成一个微型“代理机构”对外统一承接目标对内按角色分工、按工单交接、按标准验收而不是让一个智能体孤军奋战。如果你也在把大模型接进真实业务准备把 Agent 从“能聊天”推进到“能交付”那这篇文章值得看完。它不打算重复官方概念只从我自己的项目复盘出发拆解agency-agents背后真正核心的设计取舍角色怎么分、信息怎么传、质检怎么做、成本怎么算以及我在实际运行中踩过的几个真实坑。1.1 单智能体“包打天下”的三个死穴先说清楚问题出在哪。单个智能体做长流程任务通常会卡在三个地方第一是上下文预算不够。表面看窗口很大但长任务里真正稀缺的其实是“有效注意力”。当研究报告写到中后段模型对最早期信息和业务约束的“记忆”会被大量中间内容冲淡于是出现前面说过的现象第一步调研产出的结论到第三步写建议时已经对不上了。第二是角色冲突。一个 agent 要同时扮演调研员、分析师、撰稿人、审校员这个角色的行为规范会互相干扰。你让它“数据要严谨”写出来的文案就偏保守你让它“结论要鲜明”数据部分可能就开始拍脑袋。其实不是模型能力不够而是“一人分饰多角”这个设定本身就违反了大模型指令遵循的边界。第三是自审失效。模型在同一个上下文里既当运动员又当裁判它对自己产出的评价高度自洽很难发现真正的逻辑漏洞。就像写代码的人检查自己的代码总会下意识绕开已知的坑。我后来才意识到让一个 agent 自己给自己挑毛病天然就是个伪命题。1.2 从“单人模式”到“机构模式”三种组织形态怎么选agency-agents这个词字面上就是“代理机构”。把多个智能体组织成一个稳定协作的小型团队就像开一家工作室至少有三套常见的组织方式平行作坊式多个同质化 agent 并行处理同类子任务比如批量改写、批量数据标注。每个 agent 接到的工单完全独立做完后汇总。这套模式最简单适合处理量大、边界清晰的活。层级公司式一个 Coordinator协调者负责任务拆解和调度多个 Specialist专家分别产出最后还有一个 Reviewer评审者把关。我后面用的主要是这套因为它最接近真实项目团队的分工逻辑尤其适合目标本身需要拆解成不同专业领域的场景。流水线工厂式上游 agent 的产出直接成为下游 agent 的输入每个角色只做一道工序。比如采集 agent → 清洗 agent → 分析 agent → 排版 agent。好处是产出稳定坏处是单点故障会沿链路放大。用生活类比就是找三个人分别写三段并拼起来是一个极端设一个项目经理、三个模块负责人和一个测试主管是另一个极端。大部分需要质量保证的业务场景层级式会比流水线式更合适因为层级式有“返工回路”流水线一般没有。1.3 先别急着下结论agency-agents不只是“多个 agent”有朋友看完上面那段后说“这不就是 multi-agent 吗”还真不是。普通的多智能体并发调用通常是好几个 agent 看到同一份请求各自输出后拼在一起本质上是“几个专家各说各话”。而agency-agents强调的是组织结构本身——有发起方、有执行方、有检验方各方通过约定好的“契约”协作而不是靠自由发挥。我后来把两者放在一起做了张对照表清晰一些维度多智能体并发代理机构协作任务拆解不拆或简单分片按专业领域/工序设计角色定义靠提示词临时指定固定角色 固定职责边界信息传递共享完整对话历史结构化工单 数据引用质量闭环基本没有Review 后可以定向返工可复现性弱换一次随机种子结果就不同强可回放每一步输入输出这个区别决定了系统的稳定性。很多团队做 multi-agent 失败并不是模型不行而是“组织”没设计好——没有契约、没有验收、没有回溯能力。而agency-agents模式真正的价值就是把这套组织能力补上。2. 角色三角与任务工单把代理协作契约化的两个关键设计很多人在设计多智能体协作时第一步就走歪了先纠结角色数量觉得角色越多越专业或者把每个角色的提示词写得特别长试图靠“描述得多”来让模型懂规矩。我实测下来角色数量控制在 3 到 5 个最舒服角色描述里行为约束比能力描述更重要。这里先强调一个原则角色是“契约”的骨架不是“人设”。你不需要让 Coordinator 听起来像个资深项目经理你需要告诉它“你只负责任务拆解不产出内容”。规则写得越像边界条款系统越稳定。2.1 为什么是 Coordinator、Specialist、Reviewer 三个角色我最开始参考了很多资料最后稳定下来只保留了三个角色因为这三者正好覆盖了“目标、产出、质量”三段闭环Coordinator只做两件事——把模糊目标拆成可执行的工单以及把结果合并成最终交付物。它不直接写内容避免“协调者下场干活”导致没人真正做计划。Specialist负责一个领域的具体产出。可以按领域拆成多个比如调研专员、撰写专员、代码专员。每个 Specialist 只认自己职责范围内的工单不做跨领域判断。Reviewer对着验收标准做检查产出“通过 / 返工”的结论并给出可执行的修改意见。它不是夸夸其谈的评论员更像合同里的验收方。这个三角结构最像现实中的广告公司模式项目经理Coordinator对接甲方目标文案和设计Specialist干活创意总监Reviewer把关。对比两种极端配置只有 Coordinator Specialist就是典型的“无人质检”系统会自信地输出错误结果只有 Specialist Reviewer没人拆目标任务一复杂就崩。所以三角缺一不可。2.2 任务工单让 agent 协作从“闲聊”变成“契约”确定了角色之后最关键的一步是确定它们之间怎么传话。我强烈建议用结构化“任务工单”代替自由对话。你想象一下两个真人协作如果全靠微信聊天重要信息很快会被刷上去如果有一份任务单子写着“你要做什么、输入在哪、验收标准是什么”双方都会清醒得多。Agent 之间也是同理。下面是我一直在用的工单模板你可以直接抄{ ticket_id: T-20241125-001, title: 某竞品定价策略摘要, role: researcher, objective: 基于给定数据源给出目标产品近18个月的定价变化摘要, input_refs: [source_a, source_b], constraints: { output_format: markdown_table, max_words: 800, must_mention: [促销周期, 版本差异] }, review_criteria: [ 引用来源可追溯, 数据口径一致, 结论不超出数据范围 ], rework_count: 0, feedback: }字段背后的设计逻辑我逐一说说objective必须是一个动作对象边界不能写“分析一下”。写得太模糊Specialist 就会自由发挥。input_refs只放数据引用对象不直接把全文塞进去。这样每个 Specialist 按需取数不会因为接收了别人的长报告而上下文超载。constraints是可硬性校验的格式限制。模型在这个字段上最容易犯迷糊所以尽量少用“请用专业的语气”这种描述性约束改成可检查的字段。review_criteria是 Review 的标准。Reviewer 拿着它逐条打钩比自由打分靠谱得多。rework_count和feedback是返工机制的载体专门用来防止“无限循环改稿”。为什么要用工单而不是对话历史核心原因是结构记忆。对话历史是一维的时间流工单是多字段的可寻址记录。后续不管排查问题、重跑任务、还是做局部替换都可以只操作一个工单而不用从头到尾看聊天记录这在你需要支持多轮迭代时价值巨大。2.3 质检不是“看一眼”而是一张可打钩的合同好多人设计完 Coordinator 和 Specialist 就开始跑Reviewer 只是象征性地加一个。结果 Review 环节变成了“有道理但我觉得这里可以更好”——这种意见给不到点子上返工一次后广告不敢再改。我后来给 Reviewer 立了规矩只能基于review_criteria逐条“通过 / 不通过”不通过的必须给具体修改指令不能只给方向。举个例子如果 Review 的结论是“数据口径不一致”这不是可执行的反馈Specialist 仍然不知道怎么改。正确的反馈应该类似“第三段引用的是零售口径第一段是出货口径请统一为零售口径并重新核对表格编号”。一旦 Reviewer 提出这种级别的问题返工一次的成功率就会显著提高。3. 一个能跑起来的极简实现与五步落地路径理论说了一堆下面讲实现。我这套骨架在项目里跑了好几个月虽然不能说大而全但胜在可直接落地团队规模 3 到 8 个 agent 的场景完全够用。3.1 技术选型为什么我推荐“轻框架、重流程”很多朋友一听多智能体第一反应就是上重框架。我的建议恰恰相反前两个项目阶段请把“流程”看得比“框架”重要。所谓轻框架就是自己用一个主循环把各角色串起来用 JSON 文件当状态存储先跑通再谈优化。原因有三。第一重框架的编排能力比如图形状态管理在角色少、流程固定时是在叠复杂度第二自己的主循环所有逻辑都是可见的出了问题直接在日志里定位第三模型调用、重试、token 计费这些细节都要在自己手里过一遍才有感知。等流程真正稳定了、需要并发了再考虑要不要把底层换掉也不迟。落到具体技术栈上我的配置是模型统一走某个主流推理 API框架层直接用 Python 的 dataclass dict 组装工单状态持久化用一个本地 JSON 文件。没有引入任何重量级中间件。这种组合的效果是连最小部署环境都能跑排查问题也快。3.2 一个可以直接跑起来的最小骨架核心代码思路不难一句话概括主循环负责“拆工单 → 分派给 Specialist → 交给 Reviewer 检查 → 不通过就返工”。下面是简化版可以直接运行调试class AgentAgency: def __init__(self, coordinator, specialists, reviewer): self.coordinator coordinator self.specialists {s.role: s for s in specialists} self.reviewer reviewer def execute_ticket(self, ticket): specialist self.specialists[ticket[role]] result specialist.run(ticket) verdict self.reviewer.check(ticket, result) if verdict[state] rework and ticket[rework_count] 2: ticket[rework_count] 1 ticket[feedback] verdict[feedback] result self.execute_ticket(ticket) return result def run(self, brief): planning self.coordinator.plan(brief) outputs [] for ticket in planning[tickets]: ticket[rework_count] 0 ticket[feedback] outputs.append(self.execute_ticket(ticket)) return self.coordinator.consolidate(outputs)这段代码里有三个关键点分别对应三类最常见的坑rework_count 2是返工闸门。没有它遇到 Review 条件写得太苛刻或者两个 agent 风格不合任务会无限循环烧光 token 预算。specialist.run(ticket)只接收工单不接收完整对话历史。这从一开始就确保两个 Specialist 之间的信息只能通过结构化字段传递不会互相污染。coordinator.consolidate(outputs)是最后一道整合步骤它能检查所有子结果是否完整、格式是否统一而不是简单地把文本拼接起来。这个骨架跑通后你再根据实际需求加日志、加缓存、加并发分支都会有章可循。3.3 小团队落地五步法从零开始把这个系统放进业务我推荐按下面五步走每一步都不要跳过先定义交付物再定义角色。连最终产出长什么样都没想清楚角色一定拆不对。我一般会先把一个真实案例的人工产出物拿来看把它拆成可以并行处理的段落。角色克制起步。刚开始只建 Coordinator 一个 Specialist Reviewer跑通一两条真实任务后再观察 Specialist 是不是又忙又乱如果是就把它按领域拆成两个而不是一开始就铺三个。工单先于代码。动手写任何类之前先把 3 到 5 个任务的标准工单模板手写出来拿给做业务的人看一遍确认字段没有歧义再写代码。这一步能省掉很多返工。全量落盘。每个工单的输入、输出、Review 意见、返工次数全部写文件哪怕只是本地 JSON。原因很简单没有数据的排查就是瞎猜有数据才能定位是拆解的问题还是执行的问题。人工抽检哨兵。上线初期哪怕 Reviewer 再强也一定要留一个真实业务的人抽检最后输出。AI 质检的盲区非常隐蔽人工兜底是必要的“安全垫”。4. 三个故障案例的完整排查链路串味、风暴与自证式质检再完美的设计实际运行中也会出意外。我把自己在真实环境里踩过的三个坑完整梳理出来这些故障极具代表性。4.1 上下文“串味”最隐蔽的任务漂移事故有一回我做行业竞品分析一个专项 Specialist 负责查历史价格另一个负责写渠道策略。跑出来的结果里写渠道策略的 agent 居然在告诉读者“历史价格的波动主要是由大促节奏决定的”而它应该讨论的是渠道覆盖策略明显任务目标漂移了。排查时我把日志逐条拉出来对比发现问题出在信息传递方式上。最初实现为了让 Specialist 有足够背景把前面所有 agent 的聊天记录直接塞进了下一个 agent 的上下文。结果排名靠前的数据说明文字量非常大把策略 agent 给“带偏”了——它误以为自己是数据解读员开始复述前面的内容。这个坑本质上是“共享上下文”造成的注意力分配失控。修复方式很简单让每个 Specialist 只接收工单和它input_refs对应的数据对象至于其他 Specialist 在哪一步做了什么一概不看。Coordinator 是唯一一个看全貌的角色但它只负责调度和汇总不参与具体内容生成。改完之后任务漂移的问题基本绝迹。4.2 工具调用风暴撞上死循环的门卫另一次事故更尴尬。某个 Specialist 接到检索任务后外部接口返回空结果。按人类直觉发现数据源不可用就应该如实上报或者换条路但这个 agent 偏偏“执拗”地反复重试同一接口在一个空结果上循环了 12 分钟烧掉的 token 是正常任务的十几倍最后还被主流程当成超时任务挂了。排查链路也很清晰看日志发现同一条 HTTP 请求被打了十几次且每次都指向同一个空响应。根源是模型被赋予了“自主调用工具”的能力却没有为“工具失败”设定退出条件。修复方案是给所有工具调用加“全局预算与熔断门卫”市面术语叫 Circuit Breaker。具体到代码层面就是给每次调用设一个计数器同一工单内某个工具重试超过 3 次就强制短路并生成一条异常报告交给 Coordinator 决策。另外我还加了一个全局 token 上限所有 Specialist 共享一个预算池哪个角色都无法独占。自此之后风暴类故障再没出现过。4.3 “自证式质检”陷阱让同一个模型审自己等于没审我最早以为加了 Reviewer 就万事大吉后来发现同一个大模型既执行任务又做质检存在一个严重盲区模型对自己的生成风格和错误倾向高度自洽。它写出来的数据口径错误Review 时也会觉得“根据上下文这个口径是对的”。这不是模型笨而是它更倾向于确认自己之前的输出而不是质疑。排查后我还发现一个放大因素当任务描述越长、内容越专业模型对错误的自我感知就越差。比如一份行业术语密集度很高的报告Reviewer 会倾向于给出“论证充分、数据详实”的评价实际里面可能有好几个术语被混淆。破解这个陷阱要分三层做第一是给 Review 环节设置强制可校验字段比如引用来源是否存在、表格列数与标题是否一致、关键词是否覆盖这些是硬校验模型只能逐条打钩无法自由发挥第二是 Review 模型和执行模型要错开有条件的话用不同的模型提供方或模型路线至少也要用不同的提示词体系破坏模型的“自证”惯性第三是设置人工抽检站流程稳定后每天抽 5% 到 10% 最后交付物用真实业务人员的判断兜底。5. 多智能体的成本账与适用边界什么时候值得上写到这里你可能会有一个疑问又是多个角色、又是工单、又是返工这成本得往上涨多少这个问题问得很实在。agency-agents不是银弹它是一笔需要先算清楚的投资。5.1 三个看不见的账单第一张是 token 账单。同样一个任务单 agent 可能只要 30k token换成一个 3 角色机构总量往往冲到 120k 以上。原因不只是多跑几次而是每个角色都要把工单、产物、评审意见重读一遍返工还要再读一遍。用户要用机构模式就得预先接受 3 到 5 倍的 token 成本。第二张是延迟账单。流水线串行时端到端耗时为各 agent 运行时间之和即便用上平行分支Coordinator 的合并和 Review 也是额外环节。agent 数量超过 4 个以后串行链路会明显变得“没办法实时交互”用户反馈体验非常受影响。第三张是维护账单。改动一个输出字段常常要连带改三份提示词和两处工单 schema。没有良好的版本控制意识系统会在三周内“忘记自己当初为什么这样设计”。5.2 用一张筛选表决定“要不要上机构模式”任务特征建议模式简单问答、短文本总结单 agent步骤清晰、边界明确的批处理平行作坊式多个同质 agent 并行需要多角色视角、交叉验证层级公司式Coordinator Specialist Reviewer端到端内容生产、工序固定流水线工厂式需求本身模糊、没有稳定交付物先不要上 agent 机构先人工梳理流程我后来形成一条经验只要任务本身不是“多专家协作形态”就别硬套agency-agents。如果最终交付物只有一段话多智能体纯属浪费只有当交付物需要多个模块协同、互相引用、互相校验才值得动用机构编排。5.3 十秒自检清单动手前自问四个问题答案都是“是”再继续这个任务有稳定的交付物模板吗有可以量化的质量验收标准吗团队能接受 2 到 5 倍的 token 成本和明显增加的处理延迟吗有没有真实业务的人愿意做最后一轮抽检这四个问题只要有一个回答“否”我建议你先退回去把单 agent 或简单流程用熟再回来考虑多智能体机构。6. 沉淀下来的三个实操原则可观测、小作坊、人工抽检跑了大半年agency-agents相关项目之后我最大的感受是这个模式真正的难点不在“多模型编排”的技术而在“组织设计”的取舍。最后分享三条我反复验证过的实操原则算是一个收尾第一可观测性比“智能”本身更重要。多智能体系统里最贵的不是 token而是排查问题的时间。凡是能把工单、产物、评审意见落盘落日志的地方一定要落。宁可让日志丑一点也不要在故障时靠猜。第二用小作坊模式先跑通流程再扩成公司。很多项目一开始就设计六七个角色结果大部分时间花在协调角色之间的矛盾上。我先用最小三角跑通一个真实任务再观察哪个角色是瓶颈然后拆出去这个过程是“组织演进”不是“一步到位”。第三Reviewer 的人工抽检配额绝不能取消。再聪明的模型质检也有盲区尤其涉及行业知识、术语边界的时候。我在流程里固定保留 5% 的人工抽检配额这部分的成本不能省。这不是对模型的不信任而是对工程交付的基本尊重。如果你正准备从单个 agent 走向多智能体协作希望这篇文章能帮你少走几趟弯路。agency-agents不是万能的但当你面对的是一个真正需要多角色协作、质量闭环和结构记忆的任务时这套方法论会给你非常扎实的支撑。