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 条人工评估质量和上个月的数据做对比。如果某个智能体的质量评分连续两个月下降就说明它的提示词或者参数需要调整了。这个习惯帮我提前发现了好几次潜在的质量滑坡避免了问题积累到不可收拾的地步。