多智能体协作系统设计：从零搭建agency-agents自动化服务流水线

1. 从“agency-agents”这个标题说起它到底在解决什么问题第一次看到“agency-agents”这个组合词很多人会愣一下。agency 是“代理机构、中介”agents 是“代理、智能体”两个词叠在一起字面上像是“代理的代理”。但如果你最近在关注 AI 应用落地的方向就会立刻反应过来这大概率是在讲用多个智能体Agent去模拟一个完整代理机构/服务团队的那类项目——也就是把过去一个人类团队干的活拆成若干个各司其职的 AI Agent让它们协作完成从接单、分析、执行到交付的全流程。我最早接触这类思路是在帮一个做内容外包的小团队梳理流程的时候。他们当时最大的痛点是一个客户需求进来要经过需求澄清、方案撰写、素材制作、审核、交付五个环节每个环节都依赖不同的人沟通成本极高一个单子拖三五天是常态。后来我们尝试把这套流程拆成几个独立的 Agent每个 Agent 只负责一件事用一个调度层把它们串起来结果单子处理时间压缩到了几个小时。这就是 agency-agents 这类项目最核心的价值把“一个团队协作完成的服务流程”抽象成“多个 Agent 分工协作的自动化流水线”。所以这篇博文我想聊的不是某个具体开源库的 API 怎么调而是这类“代理机构型多智能体系统”背后的设计逻辑、核心细节、实操落地方法以及我在实际搭建过程中踩过的坑。它适合三类人看一是想用 AI 重构自己服务流程的创业者或小团队负责人二是对多 Agent 协作感兴趣、想动手搭一个的开发者三是产品经理想搞清楚“多智能体到底能干什么、边界在哪”。不管你有没有 AI 基础我都会尽量用生活化的类比把原理讲透让你看完能自己动手复现一套最小可用的系统。2. 整体设计思路为什么是“多 Agent 分工”而不是“一个大模型全包”2.1 单 Agent 的天花板在哪里很多人第一反应是我直接写一个超长的提示词让一个大模型把接单、分析、执行、审核全干了不就行了我试过而且踩得很惨。单 Agent 处理复杂服务流程时有三个绕不过去的坎。第一个坎是上下文污染。当一个模型既要记住客户原始需求又要记住中间分析结论还要记住审核标准它的上下文窗口会被塞得乱七八糟。就像让一个人同时当销售、设计师、质检员他脑子里三套标准会互相打架最后输出的东西四不像。第二个坎是职责不清导致的“甩锅”。单 Agent 出错时你根本不知道是需求理解错了还是执行环节偷懒了排查成本极高。第三个坎是无法并行和复用。一个客户要改三版方案单 Agent 每次都得从头跑一遍而多 Agent 可以把“素材生成”这个环节单独抽出来复用。2.2 多 Agent 分工的核心逻辑像搭一条流水线agency-agents 的思路本质上是把“服务”当成“产品”用流水线的思维去拆解。我总结了一个拆解原则按“交付物”拆而不是按“动作”拆。什么意思比如“写一篇推广文案”这个服务交付物是文案本身那拆解就是需求分析 Agent 产出“需求简报”策略 Agent 产出“内容框架”撰写 Agent 产出“初稿”审核 Agent 产出“终稿”。每个 Agent 的输入是上一个的输出输出是下一个的输入边界非常清晰。这样做的好处是每个 Agent 的提示词可以写得非常聚焦。需求分析 Agent 只需要懂“怎么把模糊需求变成结构化简报”不需要懂文案怎么写撰写 Agent 只需要懂“怎么根据框架填内容”不需要懂怎么跟客户沟通。聚焦带来的是稳定性——我实测下来一个只干一件事的 Agent输出质量的方差比“全能 Agent”小得多。2.3 调度层多 Agent 系统的“项目经理”光有干活的 Agent 还不够中间必须有一个调度层我习惯叫它“项目经理 Agent”。它的职责不是干活而是决定下一步该谁干、干完了没有、要不要打回重做。这就像真实代理机构里的项目经理他不写文案但他知道什么时候该催设计、什么时候该让客户确认。调度层的实现方式有两种一种是固定流程比如需求→策略→撰写→审核一条路走到底另一种是动态路由调度 Agent 根据当前状态判断下一步。我建议新手从固定流程开始因为动态路由虽然灵活但调试难度是指数级上升的。我第一个版本就是动态路由结果 Agent 之间互相“踢皮球”一个需求在三个 Agent 之间转了八圈还没结论最后只能推倒重来。提示固定流程不是死板而是先把主干跑通。等主干稳定了再在关键节点加“条件分支”比如审核不通过就打回撰写环节而不是重新走全流程。3. 核心细节解析每个 Agent 到底该怎么设计3.1 角色定义给每个 Agent 一个“岗位说明书”设计 Agent 的第一步是写清楚它的“岗位说明书”。我见过太多人上来就写提示词结果 Agent 行为飘忽不定。正确的顺序是先定义职责边界再定义输入输出格式最后才是提示词。职责边界要回答三个问题这个 Agent 负责什么、不负责什么、遇到边界情况怎么办。比如“审核 Agent”负责检查文案是否符合品牌调性、是否有事实错误不负责改写文案遇到无法判断的情况标记为“需人工复核”而不是自己瞎猜。输入输出格式则决定了 Agent 之间能不能顺畅对接。我强烈建议所有 Agent 的输入输出都用结构化格式比如 JSON因为自然语言的模糊性会让下游 Agent 理解偏差。Agent 角色核心职责输入输出需求分析把模糊需求转成结构化简报客户原始描述需求简报JSON策略规划根据简报定内容框架需求简报内容框架JSON内容撰写按框架产出初稿内容框架初稿文本质量审核检查初稿并给出修改意见初稿标准审核报告JSON调度管理决定流程走向各环节状态下一步指令这张表看起来简单但每一列都是我反复调整过的。比如“需求分析”的输出一开始我用纯文本结果策略 Agent 经常漏掉关键信息改成 JSON 后字段固定了漏信息的概率大幅下降。3.2 提示词工程少即是多约束即是自由写 Agent 提示词有个反直觉的规律你写得越多它越容易跑偏。我早期给撰写 Agent 写了三千字的提示词把各种文风、各种禁忌都列上了结果它反而不知道该听哪条。后来我砍到八百字只保留“角色定位、核心任务、输出格式、三条硬性约束”效果反而稳定了。我的提示词模板通常包含四块第一块是角色定位一句话说清“你是谁、你只干什么”第二块是核心任务用动词开头比如“根据输入的内容框架撰写一篇 800 字左右的推广文案”第三块是输出格式明确要求 JSON 还是纯文本字段名是什么第四块是约束条件只写最关键的几条比如“不得编造数据”“不得使用绝对化用语”。注意约束条件不要超过五条。超过五条模型会开始“选择性遵守”你根本不知道它忽略了哪条。如果确实有很多约束把它们拆到不同的 Agent 里而不是堆在一个 Agent 上。3.3 记忆与状态管理Agent 之间怎么“交接班”多 Agent 系统最容易出问题的地方就是状态传递。A Agent 干完活怎么把结果准确交给 B Agent我的做法是维护一个共享状态对象可以理解成一个“项目文件夹”每个 Agent 干完活就往里放东西下一个 Agent 从里面取需要的东西。这个共享状态对象里通常包含原始需求、当前阶段、各环节产出物、历史修改记录、当前负责人。调度 Agent 每次决策前先读这个对象判断当前处于哪个阶段、上一个环节是否完成、有没有异常标记。这样做的好处是可追溯——任何一个环节出问题我都能翻出当时的完整状态知道是哪个 Agent 在什么输入下产出了什么。我踩过的一个坑是早期我让 Agent 之间直接传递自然语言结果结果 B Agent 经常“误解”A Agent 的意思。比如 A 说“这个方案基本可行但需要补充数据”B 理解成“方案可行直接执行”把“补充数据”漏了。改成结构化状态后A 会输出{status: conditional_pass, required_actions: [add_data]}B 就不会漏了。4. 实操过程从零搭一套最小可用的 agency-agents 系统4.1 环境准备与技术选型动手之前先明确技术选型。我的建议是新手用现成的 Agent 编排框架老手可以自己写调度逻辑。现成框架的好处是帮你处理了状态管理、重试、日志这些脏活累活你只需要关注每个 Agent 的提示词和流程设计。自己写的好处是灵活但你要做好花大量时间在“胶水代码”上的准备。我自己的最小系统是用 Python 写的核心依赖就两个一个大模型调用库一个流程编排库。模型方面我建议至少准备两个不同能力的模型——一个“强模型”用于需求分析和策略规划这种需要深度思考的环节一个“快模型”用于内容撰写和格式转换这种相对机械的环节。这样能在成本和效果之间取得平衡。环境准备清单Python 3.10 以上低版本会有依赖兼容问题一个大模型 API 的调用凭证一个流程编排库或自己用状态机实现一个日志系统强烈建议否则调试时你会疯4.2 第一步定义共享状态与流程骨架先别急着写 Agent先把“项目文件夹”和“流程骨架”定下来。我用一个 Python 字典来模拟共享状态project_state { raw_request: , # 客户原始需求 current_stage: intake, # 当前阶段 brief: None, # 需求简报 framework: None, # 内容框架 draft: None, # 初稿 review_report: None, # 审核报告 history: [], # 操作历史 status: running # 整体状态 }流程骨架我用一个简单的状态机表示intake - analysis - planning - writing - review - done。每个阶段对应一个 Agent调度器按顺序调用遇到review不通过就回退到writing。这个骨架看起来简陋但它是我调试了十几个版本后觉得最稳的——简单意味着可控。4.3 第二步逐个实现 Agent 并串联实现顺序很重要。我的建议是从中间环节开始而不是从头开始。因为中间环节比如撰写最容易验证效果你能快速看到产出物建立信心。如果从需求分析开始你可能要等整条链路跑通才能看到结果调试周期太长。以撰写 Agent 为例它的核心逻辑是从共享状态里取framework调用模型生成初稿把结果写回draft更新current_stage为review。代码大概长这样def writing_agent(state): framework state[framework] prompt f根据以下框架撰写初稿{framework} draft call_llm(prompt, modelfast-model) state[draft] draft state[current_stage] review state[history].append({stage: writing, output: draft}) return state每个 Agent 都是这样一个“读状态-干活-写状态”的函数。串联起来就是一个循环调度器不断检查current_stage调用对应的 Agent直到状态变成done。4.4 第三步加入审核与回退机制审核 Agent 是整个系统的“质量守门员”。它的输出必须包含明确的通过/不通过标记和具体修改意见。我用的审核报告格式是{ passed: false, issues: [ {type: fact_error, location: 第二段, detail: 数据来源不明}, {type: tone_mismatch, location: 结尾, detail: 语气过于随意} ], suggestions: [补充数据来源, 调整结尾语气] }调度器读到passed: false就把suggestions塞回framework或直接传给撰写 Agent让它重写。这里有个关键细节回退次数要设上限。我设的是三次超过三次就标记为“需人工介入”避免系统陷入无限循环。这个上限是我踩坑踩出来的——有一次一个需求在撰写和审核之间来回转了十几次烧了一堆调用额度最后产出还是不行。4.5 第四步日志与可观测性系统跑起来之后你最需要的是知道它内部发生了什么。我在每个 Agent 的入口和出口都加了日志记录时间戳、Agent 名称、输入摘要、输出摘要、耗时、调用模型、token 消耗。这些日志在调试时救了我无数次。比如有一次审核 Agent 一直不通过我翻日志发现是撰写 Agent 每次重写都只改了标点符号根本没动实质内容。进一步排查发现是回退时传给撰写 Agent 的suggestions被截断了它只收到了半句话。如果没有日志我可能要花几个小时才能定位到这个问题。5. 常见问题与排查技巧实录5.1 Agent 之间“踢皮球”怎么办这是多 Agent 系统最典型的问题A 说这事该 B 干B 说该 A 干结果卡住。根本原因通常是职责边界有重叠或空白。我的排查方法是把每个 Agent 的职责边界画成一张表检查有没有“两个 Agent 都声称负责”或“两个 Agent 都不负责”的区域。解决办法有两个一是明确仲裁者在调度层加一条规则遇到争议时由调度 Agent 强制指定负责人二是收窄职责把模糊地带单独拆成一个新 Agent。我遇到过一次“内容格式调整”该谁干的问题撰写 Agent 觉得该审核 Agent 干审核 Agent 觉得该撰写 Agent 干最后我拆了一个“格式整理 Agent”出来问题就解决了。5.2 输出质量不稳定怎么调质量不稳定的表现是同样的输入有时候产出很好有时候一塌糊涂。排查顺序是先看提示词是否过于宽泛再看输入是否结构化最后看模型温度参数。我实测下来把温度从默认的 0.7 降到 0.3撰写类 Agent 的稳定性会明显提升代价是创意性略降。对于审核类 Agent我甚至会把温度设到 0.1因为它需要的是判断不是发挥。还有一个容易被忽略的点输入的长度。如果传给 Agent 的输入太长模型会“注意力涣散”。我的做法是在传给撰写 Agent 之前先把框架压缩成关键要点而不是把整个需求简报原封不动塞进去。5.3 成本失控怎么控制多 Agent 系统烧钱的速度比单 Agent 快得多因为一次任务要调用多次模型。我控制成本的方法有三个第一分级用模型只有需求分析和策略规划用强模型其他环节用快模型第二设置 token 上限每个 Agent 的输入输出都设上限超了就截断或报错第三缓存重复结果比如同一个客户的历史需求简报可以缓存起来复用。下面这张表是我总结的常见问题速查表遇到问题可以先对照排查问题现象可能原因排查动作解决方向Agent 互相推诿职责边界重叠/空白检查职责表明确仲裁者或拆分 Agent输出质量波动大提示词宽泛/温度过高检查提示词和温度参数收窄提示词、降低温度流程卡死回退次数无上限检查调度逻辑设置回退上限和人工介入成本超预期全流程用强模型检查模型分配分级用模型、设 token 上限状态传递丢失用自然语言传状态检查状态格式改用结构化状态对象5.4 独家避坑技巧分享几个我在文档里看不到、只能自己踩出来的经验。第一个是给每个 Agent 加“超时”。有些 Agent 会因为输入异常陷入“思考死循环”一直不返回结果。我后来给每个 Agent 调用加了超时超时就标记为失败让调度器决定重试还是跳过。第二个是保留“原始需求”不被修改。共享状态里的raw_request我从不让任何 Agent 改写因为它是所有判断的最终依据一旦被污染整个流程都会跑偏。第三个是定期人工抽检。系统跑得再顺也要定期人工看几条产出因为 Agent 可能会“集体犯错”——比如所有 Agent 都忽略了某个新政策这种系统性偏差只有人工能发现。6. 这套系统还能怎么扩展跑通最小系统之后我陆续做了几个扩展效果不错。第一个扩展是加入“客户反馈”环节把客户对初稿的反馈也作为一个 Agent 的输入让系统能根据真实反馈迭代而不是只靠内部审核。第二个扩展是多项目并行把共享状态从单个字典改成项目列表调度器可以同时处理多个项目适合小团队批量接单的场景。第三个扩展是产出物归档每个项目完成后把完整的状态对象存下来形成“案例库”下次遇到类似需求可以直接参考。我个人在实际操作中的体会是agency-agents 这类系统的价值不在于“完全替代人”而在于把人从重复的流程协调中解放出来。人只需要在关键节点做判断——比如审核不通过三次后的人工介入、客户反馈的最终确认。剩下的脏活累活交给 Agent 流水线去跑。如果你也在做类似的事情我的建议是先从一条最简单的流水线开始跑通它再慢慢加环节。别一上来就追求“全自动”那大概率会让你在调试地狱里待很久。