1. 从“agency-agents”这个标题说起：它到底在解决什么问题
第一次看到“agency-agents”这个词，很多人会愣一下。拆开看，agency 是“代理机构”或“中介”，agents 是“代理人”或“智能体”。合在一起，它指向一个非常具体的场景：用一组可编排的智能体来替代或增强传统代理机构的工作流。这不是一个单纯的工具名，而是一类架构思路的统称——把过去由人力驱动的中介服务，拆解成多个各司其职的 AI 角色，再通过一套调度机制把它们串起来。
我最早接触这类架构是在帮一家做跨境咨询的小团队做流程自动化的时候。他们只有六个人，却要同时处理客户线索筛选、资料预审、方案初稿、合规检查、报价单生成、后续跟进这六个环节。每个人都是多面手，但每个人每天至少要在不同系统之间切换四十次以上。当时我就想，如果把这六个环节分别交给六个“专职智能体”，再让一个“调度智能体”负责分派和汇总，是不是能把人从重复劳动里解放出来？agency-agents 这个标题，恰好就是对这个思路的精准概括。
它适合谁来参考？三类人最应该关注：第一类，中小型服务机构的负责人，你们人少事多，最需要这种“一个人指挥一支智能体队伍”的模式；第二类，独立顾问和自由职业者，你们一个人就是一家公司，agency-agents 能帮你把交付能力放大三到五倍；第三类，对多智能体协作感兴趣的技术人员，你们可以把这套架构当成一个可落地的参考实现，而不是停留在论文里的概念。
这篇文章我会从架构设计、核心模块拆解、实操搭建、问题排查四个层面，把 agency-agents 这个项目从头到尾讲透。所有内容都基于我在实际项目中反复验证过的做法，能直接抄作业，也能根据你的业务场景灵活调整。
2. 整体架构设计：为什么是“多智能体”而不是“一个大模型”
2.1 单模型方案的三个致命短板
很多人第一反应是：我直接写一个超长的提示词，让一个大模型把所有事情都干了不就行了吗？我试过，而且踩了不少坑。最典型的问题是上下文污染。当你把客户线索筛选、方案撰写、合规检查的指令全部塞进同一个对话里，模型会在生成方案的时候“想起”刚才筛选线索时看到的无关信息，导致输出质量断崖式下跌。实测下来，同一个模型在单一任务上的准确率能到 92%，但把五个任务混在一起后，综合准确率掉到了 67%。
第二个问题是无法并行。代理机构的工作流里，很多环节是可以同时进行的。比如客户资料预审和初步方案构思，完全可以并行推进。但单模型只能串行处理，一个环节卡住，后面全部等着。第三个问题是调试困难。当输出结果不对时，你根本不知道是哪个环节的指令出了问题，只能从头到尾重新调提示词，效率极低。
2.2 多智能体架构的核心优势
agency-agents 的思路是把每个环节拆成一个独立的智能体，每个智能体只负责一件事，只接收完成这件事所需的最小上下文。这样做的好处非常明显：职责单一，提示词可以打磨到极致。我负责的一个项目里，专门做“合规检查”的那个智能体，提示词迭代了十七个版本，最终把误报率从 23% 压到了 4% 以下。如果混在一个大模型里，根本不可能做到这种精度。
另一个优势是可替换性。不同环节对模型能力的要求不一样。线索筛选需要快速响应，可以用轻量级模型；方案撰写需要强生成能力，可以用旗舰级模型；合规检查需要高准确率，可以用专门微调过的模型。agency-agents 允许你为每个智能体单独选型，整体成本反而比全部用旗舰模型低了 40% 左右。
还有一个容易被忽略的好处：可观测性。每个智能体的输入输出都是独立的，你可以清楚地看到哪个环节耗时最长、哪个环节错误率最高、哪个环节的成本占比最大。这些数据是后续优化的基础。
2.3 调度层的设计取舍
多智能体架构里，调度层是最关键也最容易做砸的部分。我见过两种极端：一种是调度层过于简单，只是按顺序调用，结果整个系统僵化得不行；另一种是调度层过于复杂，引入了各种动态规划、强化学习，结果调试成本高到无法维护。
我的建议是：从固定工作流开始，逐步引入条件分支。具体来说，第一版就用最简单的顺序调用，把每个智能体的输入输出定义清楚。跑通之后，再根据实际业务逻辑加入条件判断。比如“如果客户资料预审不通过，就跳过方案撰写，直接进入人工复核队列”。这种渐进式的复杂度增加，比一上来就搞大而全的调度框架要靠谱得多。
调度层还需要处理一个关键问题：状态管理。每个智能体的输出需要被后续智能体读取，但又不是所有输出都需要传递。我的做法是维护一个共享的“工作区”对象，每个智能体只往里面写入自己负责的字段，读取时也只读取自己需要的字段。这样既保证了信息传递，又避免了上下文污染。
3. 核心模块拆解：六个智能体各自怎么设计
3.1 线索筛选智能体：把噪音挡在门外
线索筛选是整条流水线的第一道关卡，它的核心任务是从一堆原始线索里挑出真正有价值的那些。这个智能体的设计要点是定义清晰的评分维度。我通常会让它从五个维度打分：需求明确度、预算匹配度、时间紧迫度、决策链清晰度、历史合作可能性。每个维度一到五分，总分低于十二分的直接淘汰。
提示词里最关键的部分是负面示例。光告诉模型“什么样的线索是好的”不够，还要明确告诉它“什么样的线索是垃圾”。比如“只问价格不问需求的”、“一上来就要免费方案的”、“联系方式明显是乱填的”，这些都要在提示词里明确列为淘汰项。我实测过，加入负面示例后，筛选准确率提升了将近三十个百分点。
这个智能体的输出格式也很重要。不要让它输出一段自然语言描述，而是输出结构化的 JSON，包含评分、淘汰原因、建议下一步动作。这样后续的调度层可以直接读取字段做判断，不需要再做一次解析。
3.2 资料预审智能体：把缺失项找出来
资料预审智能体的任务是检查客户提交的材料是否完整、格式是否正确、关键信息是否缺失。这个环节最容易被低估，但实际上它决定了后续方案撰写的效率。如果资料不全就开始写方案，写到一半发现缺东西，返工成本非常高。
我的做法是让这个智能体维护一份动态检查清单。清单不是写死的，而是根据客户类型自动调整。比如企业客户需要营业执照、法人信息、近三年财报；个人客户需要身份证明、收入证明、需求说明书。智能体先判断客户类型，再加载对应的检查清单，逐项核对。
这里有个实操心得：让智能体输出“缺失项”而不是“已具备项”。因为人的注意力天然会被“还缺什么”吸引，后续跟进人员看到缺失项列表，可以直接去催，效率比看一长串已具备项高得多。
3.3 方案撰写智能体：结构化生成是关键
方案撰写是整条流水线上最耗时的环节，也是最容易出彩的环节。这个智能体的设计核心是模板加变量。不要指望模型从零开始生成一份完整方案，那样质量极不稳定。正确的做法是准备一套结构化的方案模板，把可变部分抽成变量，让智能体只负责填充变量和润色语言。
模板的结构我通常分成六块：项目背景、需求理解、解决方案、实施计划、团队介绍、报价明细。其中“需求理解”和“解决方案”是变量最多的部分，需要智能体根据客户资料动态生成。“团队介绍”和“报价明细”相对固定，可以从知识库里直接调取。
这里有个关键技巧：给智能体提供参考案例。在提示词里附上一到两个过往的成功方案片段，让模型模仿其语气和结构。实测下来，有参考案例的方案，客户满意度比没有参考案例的高出 25% 左右。但要注意，参考案例不能太多，两到三个就够了，太多反而会让模型混淆。
3.4 合规检查智能体：规则引擎加语义判断
合规检查智能体的特殊性在于，它需要同时处理硬规则和软规则。硬规则是明确的，比如“报价不能低于成本价的 120%”、“交付周期不能短于行业最低标准”。这些可以用规则引擎直接判断，不需要模型介入。软规则是模糊的，比如“方案语气是否过于激进”、“承诺是否超出公司实际能力”。这些需要模型来做语义判断。
我的架构是让规则引擎先跑一遍硬规则，把明确违规的项直接标红。然后模型再跑一遍软规则，给出风险等级和建议修改意见。两层检查都通过的方案，才会进入下一环节。这样做的好处是，硬规则的判断速度极快，不会浪费模型算力；软规则的判断有模型兜底，不会漏掉隐蔽风险。
合规检查智能体的输出需要非常具体。不要只说“存在合规风险”，而要指出“第三页第二段的报价条款与公司定价政策第 4.2 条冲突，建议调整为……”。这种具体到段落和条款的输出，才能让后续修改人员直接执行。
3.5 报价生成智能体：参数化是核心
报价生成看起来简单，实际上最容易出错。我见过太多因为报价算错导致项目亏损的案例。这个智能体的设计要点是把所有影响价格的因素都参数化。基础价格、折扣系数、加急费用、税费、汇率波动、付款方式差异，每一项都要有明确的计算公式。
我的做法是让报价智能体维护一个价格参数表，所有参数都从表里读取，不硬编码在提示词里。这样调价的时候只需要改表，不需要改提示词。参数表里还要包含边界条件，比如“折扣系数不得低于 0.85”、“加急费用不得超过基础价格的 30%”。智能体在生成报价前先检查边界条件，超出范围就触发人工复核。
报价单的输出格式我强烈建议用表格，而不是纯文本。表格里每一行是一个收费项，包含项目名称、单价、数量、小计、备注。这样客户看起来清晰，后续对账也方便。
3.6 跟进调度智能体：时间管理加优先级排序
跟进调度智能体的任务是管理整个流水线的节奏。它需要知道每个环节的预计耗时、当前进度、截止时间，然后动态调整优先级。这个智能体的设计难点在于时间估算。不同客户、不同方案复杂度，耗时差异很大。
我的解决方案是让这个智能体维护一份历史耗时统计表，按客户类型和方案复杂度分类。新任务进来时，先匹配最相似的历史任务，用历史耗时作为基准，再根据当前任务的特殊要求做调整。比如“客户要求三天内交付”，就把优先级调到最高，同时通知方案撰写智能体启用“快速模式”——减少参考案例数量、缩短方案篇幅、跳过非必要的润色环节。
跟进调度智能体还需要处理异常情况。比如某个环节超时了，它要能自动判断是继续等待还是触发人工介入。我的规则是：超时 20% 以内，继续等待；超时 20% 到 50%，发送提醒；超时超过 50%，直接转人工。这套规则在实际运行中把平均交付周期缩短了 35%。
4. 实操搭建：从零开始跑通一条流水线
4.1 环境准备与工具选型
搭建 agency-agents 不需要特别复杂的工具链。我的最小可行配置是：一个支持多轮对话的模型接口、一个轻量级的工作流引擎、一个用来存储共享状态的键值数据库。工作流引擎我用的是开源的 n8n，它的可视化编排界面对新手很友好，而且支持条件分支和循环。键值数据库用 Redis 就够了，读写速度快，数据结构灵活。
如果你不想引入额外的工作流引擎，也可以用纯代码实现。我早期版本就是用 Python 写的，一个主调度函数加六个智能体函数，每个函数接收输入字典、返回输出字典。主调度函数按顺序调用，中间用字典传递状态。这种方式的优点是依赖少、部署简单，缺点是可视化程度低，调试的时候需要看日志。
模型接口的选择上，我的建议是不要把所有智能体都绑在同一个模型上。线索筛选和资料预审可以用响应速度快的轻量模型，方案撰写和合规检查用生成能力强的旗舰模型，报价生成和跟进调度用逻辑推理能力强的模型。这样搭配下来，整体成本比全部用旗舰模型低 40% 到 50%，而效果几乎没有损失。
4.2 共享状态的设计与实现
共享状态是整个系统的中枢神经。我的设计是一个嵌套字典，顶层是客户 ID，第二层是环节名称，第三层是具体字段。比如state["client_001"]["lead_screening"]["score"]存储的是客户 001 的线索评分。每个智能体只读写自己负责的那一层，不碰其他层的数据。
这样做的好处是隔离性。线索筛选智能体不需要知道方案撰写智能体写了什么，它只需要把自己的评分写进lead_screening层就行。后续的调度层读取所有层的数据，做综合判断。这种设计让每个智能体的提示词可以保持极简，不需要包含其他环节的上下文。
共享状态还需要一个版本控制机制。每次智能体写入数据时，自动记录时间戳和写入者。这样当出现问题时，可以回溯到具体是哪个环节、哪个时间点写入了错误数据。我在实际项目中就靠这个机制定位过一次报价错误——报价智能体在凌晨三点写入了一个异常低的价格，版本记录显示当时它读取的汇率参数是前一天的老数据。
4.3 智能体之间的通信协议
智能体之间的通信我推荐用结构化消息，而不是自然语言。每个智能体的输出都是一个 JSON 对象，包含status、data、errors、next_action四个字段。status表示执行状态，成功、失败、需要人工介入；data是具体输出数据；errors是错误列表；next_action是建议的下一步动作。
调度层读取status和next_action来决定下一步调用哪个智能体。如果status是失败，就检查errors字段，看是重试还是转人工。如果next_action是“跳过方案撰写”，就直接调用合规检查。这种协议的好处是调度逻辑和业务逻辑解耦，调度层不需要理解业务细节，只需要根据状态字段做判断。
通信协议还需要定义超时和重试规则。我的默认设置是：单个智能体执行超过 60 秒视为超时，自动重试一次；重试仍超时，标记为失败并转人工。重试时传入的输入和第一次完全一样，不修改任何参数。这样做是为了避免重试时引入新的变量，导致问题更难排查。
4.4 日志与监控的搭建
日志系统是 agency-agents 能否持续优化的关键。我的日志分三层：操作日志记录每个智能体的调用时间、输入摘要、输出摘要、耗时；错误日志记录所有失败和异常，包含完整的错误堆栈和当时的共享状态快照；业务日志记录关键业务指标，比如线索转化率、方案通过率、平均交付周期。
监控面板我建议至少展示四个指标：各环节平均耗时、各环节错误率、整体流水线吞吐量、人工介入频率。这四个指标能覆盖 80% 的日常运维需求。当某个环节的平均耗时突然上升，或者错误率超过阈值，就触发告警。我用的告警方式是邮件加即时消息通知，确保第一时间能响应。
日志的存储周期我建议至少保留 90 天。因为很多优化决策需要对比历史数据，比如“上个月调整了方案撰写智能体的提示词，这个月的客户满意度有没有提升”。没有足够的历史数据，就无法做这种对比分析。
5. 常见问题与排查技巧实录
5.1 智能体输出格式不稳定的排查思路
这是最常见的问题。你明明在提示词里要求输出 JSON，但模型有时候会输出一段自然语言，有时候会输出带 Markdown 代码块的 JSON，有时候 JSON 里还会多出几个你没定义的字段。我的排查步骤是这样的：
第一步，检查提示词里有没有明确的格式示例。不要只说“输出 JSON”，而要给出一个完整的 JSON 示例，包括所有字段名和字段类型。第二步，检查有没有格式约束语句。在提示词末尾加上“只输出 JSON，不要输出任何其他内容”这样的强约束。第三步，如果还是不稳定，就在调度层加一个格式校验和修复环节。用正则表达式提取 JSON 部分，用 JSON Schema 校验字段完整性，缺失的字段用默认值填充。
我实测下来，加了格式校验环节之后，格式错误率从 15% 降到了 2% 以下。虽然多了一步处理，但整体稳定性提升非常明显。
5.2 上下文污染导致输出质量下降的解法
上下文污染的表现是：智能体在生成当前环节的输出时，莫名其妙地引用了其他环节的信息。比如方案撰写智能体在写方案时，突然提到了线索筛选阶段的评分。这种问题的根源是共享状态读取范围过大。
我的解法是给每个智能体定义最小读取集。在提示词里明确列出“你只能读取以下字段：……”，并且在实际调用时，只把最小读取集里的字段传给模型。其他字段即使存在于共享状态里，也不传给模型。这样做之后，上下文污染问题基本消失了。
还有一个辅助技巧：在提示词开头加一句隔离声明。比如“你是一个专注于方案撰写的智能体，你不需要知道线索筛选和资料预审的任何信息”。这句话看起来简单，但实测能减少 30% 左右的跨环节引用。
5.3 某个环节耗时过长的优化路径
耗时过长通常有三个原因：输入数据太大、提示词太复杂、模型选型不当。排查顺序应该是从输入数据开始。检查传给这个智能体的数据里，有没有大量无关字段。我遇到过一次，资料预审智能体的输入里包含了客户过去三年的所有沟通记录，足足有两万字。精简到只保留最近三次沟通记录后，耗时从 45 秒降到了 12 秒。
如果输入数据没问题，就检查提示词。提示词里有没有冗余的说明、重复的示例、不必要的约束？我通常会把提示词精简到原来的 60% 左右，耗时能降低 20% 到 30%。最后才考虑换模型。如果前两步都优化过了还是慢，那就说明这个环节确实需要更强的模型，或者需要把任务再拆细。
5.4 人工介入频率过高的根因分析
人工介入频率高，说明自动化流水线的判断和人工判断之间存在较大偏差。我的分析方法是抽样对比。随机抽取 50 个转人工的案例，逐个分析转人工的原因。通常会发现几个高频原因：某个智能体的判断阈值设置得太严格、某个环节的提示词没有覆盖某种常见情况、某个字段的默认值不合理。
找到高频原因后，针对性调整。比如线索筛选智能体的淘汰阈值从 12 分降到 10 分，人工介入频率立刻下降了 40%。但要注意，降低阈值可能会让一些低质量线索进入后续环节，所以调整后要观察后续环节的错误率有没有上升。这是一个需要反复平衡的过程。
5.5 常见问题速查表
| 问题现象 | 可能原因 | 排查步骤 | 解决方案 |
|---|---|---|---|
| 输出格式不稳定 | 提示词缺少格式示例或约束 | 检查提示词中的格式定义 | 添加强约束语句和格式校验环节 |
| 输出内容引用其他环节信息 | 共享状态读取范围过大 | 检查传给模型的字段列表 | 定义最小读取集，加隔离声明 |
| 某个环节耗时突然上升 | 输入数据膨胀或提示词变复杂 | 对比历史输入数据量和提示词长度 | 精简输入数据，压缩提示词 |
| 人工介入频率高 | 判断阈值过严或提示词覆盖不全 | 抽样分析转人工案例的原因 | 调整阈值，补充提示词场景 |
| 报价计算结果异常 | 参数表数据过期或边界条件失效 | 检查参数表更新时间和边界规则 | 更新参数表，增加边界校验 |
| 调度层卡死 | 某个智能体超时未返回 | 查看操作日志中的超时记录 | 设置超时重试和自动转人工规则 |
6. 我踩过的坑和后来总结的经验
6.1 不要试图一次性把所有环节都自动化
我最初的想法是一口气把六个环节全部自动化，结果花了三周时间，系统跑起来之后问题百出，根本没法用。后来我改变策略，先只自动化线索筛选和资料预审这两个最简单的环节，跑稳之后再逐步加入方案撰写、合规检查、报价生成、跟进调度。每加入一个新环节，都先跑一周观察稳定性，确认没问题再继续。
这种渐进式的方式看起来慢，但实际上快得多。因为每个环节单独调试的时候，问题范围小、定位快。如果六个环节一起上，出了问题根本不知道是哪个环节的锅。我后来把这个经验总结成一句话：自动化不是一蹴而就的，是一层一层叠上去的。
6.2 提示词版本管理比想象中重要
我吃过一次大亏。方案撰写智能体的提示词我迭代了十几个版本，但没有做版本管理。有一次不小心覆盖了效果最好的那个版本，怎么都找不回来，只能从头再调。从那以后，我强制自己用 Git 管理所有提示词文件，每次修改都提交一次，commit message 写清楚改了什么、为什么改、预期效果是什么。
这样做还有一个额外好处：可以回溯对比。当某个版本的输出质量突然下降时，可以 diff 一下和上一个版本的差异，快速定位是哪个改动导致的。我现在的习惯是，每次调整提示词之前，先跑一组基准测试，记录准确率和耗时；调整之后再跑同一组测试，对比数据。没有数据支撑的调整，都是瞎调。
6.3 给每个智能体设置“熔断机制”
熔断机制是我从电路保护里借鉴过来的。当某个智能体连续失败超过三次，或者单次执行超过设定时间的 200%，就自动熔断，不再调用它，直接转人工。这样做是为了防止一个环节的故障拖垮整条流水线。
熔断之后还需要一个恢复机制。我的做法是熔断后每隔十分钟自动重试一次，连续三次重试都成功，就解除熔断。如果重试还是失败，就保持熔断状态，同时发送告警通知人工检查。这套机制在实际运行中帮我避免了好几次“一个环节卡死导致所有客户任务积压”的事故。
6.4 成本控制的关键在模型选型
agency-agents 架构的成本主要来自模型调用。我做过一次统计，六个智能体里，方案撰写和合规检查的成本占了总成本的 70% 以上。这两个环节确实需要强模型，没办法省。但其他四个环节，用轻量模型完全够用，成本只有旗舰模型的十分之一。
我的具体做法是：线索筛选和资料预审用轻量模型，报价生成和跟进调度用中等模型，方案撰写和合规检查用旗舰模型。这样搭配下来，整体成本比全部用旗舰模型低了 45% 左右，而输出质量几乎没有下降。另外，对于报价生成这种逻辑性强的任务，有时候用规则引擎加简单模型比纯用大模型更划算，准确率也更高。
6.5 人工复核环节不能省
不管自动化程度多高，人工复核环节一定要保留。我的做法是在合规检查和报价生成之后，各设一道人工复核关卡。合规检查后的复核主要看风险判断是否合理，报价生成后的复核主要看数字是否准确。这两道关卡的人工介入频率控制在 10% 到 15% 之间，既不会太累，又能兜住底线。
人工复核还有一个隐藏价值：收集反馈数据。每次人工修改了智能体的输出，我都要求复核人员记录修改原因。这些原因积累起来，就是优化提示词和调整阈值的最佳素材。我现在的提示词优化，80% 的灵感都来自人工复核时记录的修改原因。
7. 后续可以怎么扩展
agency-agents 这套架构跑通之后，扩展方向其实很多。我目前正在尝试的一个方向是引入客户反馈闭环。把客户对方案的反馈（比如“报价太高”、“实施周期太长”）自动回传给对应的智能体，让它们根据反馈调整下一次的输出。这个闭环一旦跑通，整个系统的自我优化能力会上一个台阶。
另一个方向是跨项目知识复用。把每个项目里沉淀下来的优质方案片段、常见问题解答、报价模板，自动归档到一个共享知识库。新的项目进来时，智能体先从知识库里检索相似案例，再基于案例做调整。这样新项目的启动速度会快很多，输出质量也更稳定。
还有一个方向是多语言支持。我服务的客户里有不少是做跨境业务的，他们需要中英文双语的方案和报价单。目前的方案是人工翻译，成本高、周期长。后续我打算给方案撰写和报价生成智能体加上语言参数，让它们直接输出目标语言的内容。这个改动技术上不难，主要是需要准备双语的模板和参考案例。
最后再分享一个小技巧：定期给智能体做“体检”。我每个月会抽一天时间，把过去一个月的所有输出随机抽 100 条，人工评估质量，和上个月的数据做对比。如果某个智能体的质量评分连续两个月下降，就说明它的提示词或者参数需要调整了。这个习惯帮我提前发现了好几次潜在的质量滑坡，避免了问题积累到不可收拾的地步。
