1. 从“agency-agents”这个标题说起它到底在解决什么问题第一次看到“agency-agents”这个组合词我脑子里蹦出来的第一反应是这大概率是一个围绕“代理型智能体”做文章的项目而且“agency”这个词放在前面说明它强调的不是单个智能体的能力而是“代理机构”或者“代理网络”这一层的组织与协作。换句话说它关心的不是“一个智能体有多聪明”而是“一群智能体怎么像一个团队一样干活”。这个判断不是拍脑袋来的。过去两年智能体相关的项目从“单点工具调用”快速演进到“多智能体协作”但真正落地的时候大家普遍卡在同一个地方单个智能体跑个demo很惊艳一旦要它稳定地完成一个跨步骤、跨角色、跨工具的任务就开始各种掉链子。要么是任务拆解不清晰要么是角色之间互相甩锅要么是上下文传递丢失最后变成“看起来热闹实际没法用”。“agency-agents”这个标题我理解它瞄准的就是这个痛点。它想做的是一套让多个智能体像一家代理公司那样运转的机制——有接单的、有拆解的、有执行的、有审核的各司其职又能协同交付。这个方向对做自动化流程、做智能客服中台、做内容生产流水线的团队来说参考价值很大。哪怕你只是一个人在做副业项目理解这套思路也能帮你把“一个智能体硬扛”变成“几个智能体分工”稳定性和可维护性完全不是一个量级。这篇文章我会按我自己的实操习惯来拆先讲整体设计思路和选型逻辑再讲核心细节和容易踩的坑然后给一套可以直接抄的实操流程最后整理常见问题和排查技巧。全程不堆术语尽量用我踩过的坑和试过的方案来说话。2. 整体设计与思路拆解为什么是“代理机构”而不是“超级智能体”2.1 单智能体方案的三个硬伤我最早做智能体项目的时候也是想着“一个提示词写全一点模型强一点不就什么都能干了吗”。实测下来这条路在简单任务上没问题一旦任务超过三步就开始出问题。最典型的三个硬伤第一上下文污染。一个智能体既要理解用户意图又要规划步骤又要调用工具又要检查结果所有信息挤在一个上下文窗口里。前面步骤的中间结果会干扰后面的判断模型很容易“忘记”自己到底在干什么。我试过一个任务让它先查数据再写报告结果它把查询用的临时参数写进了最终报告里因为上下文里这些东西混在一起它分不清哪些是过程、哪些是结果。第二角色冲突。同一个智能体既当执行者又当审核者它天然倾向于“自己做的都是对的”。你让它检查自己的输出它大概率会说“没问题”。这不是模型笨而是角色没有分离缺少对抗性。第三错误放大。单智能体一旦在某一步理解偏了后面所有步骤都会沿着错误方向走而且没有中间检查点。等最后发现不对已经浪费了大量调用和token。2.2 “代理机构”模式的核心思路“agency-agents”这个思路本质上是把一家代理公司的组织架构搬进智能体系统里。代理公司怎么干活客户提需求客户经理接单并初步理解然后交给策略或策划拆解成可执行的任务包再分给具体执行人员执行完交给审核人员检查最后汇总交付。每个角色只关心自己那一块信息通过标准化的“工单”传递。对应到智能体系统里就是几个关键设计角色分离规划者、执行者、审核者、汇总者分开每个角色有独立的提示词和上下文边界。工单机制角色之间不直接共享全部上下文而是通过结构化的任务描述传递信息。规划者输出的是任务列表执行者拿到的是单个任务审核者拿到的是任务加执行结果。检查点每个关键步骤后都有审核或校验错误在早期就被拦截不会一路放大。可替换性每个角色可以用不同的模型、不同的提示词、甚至不同的人来承担系统不依赖某一个“超级智能体”。这个设计的优势很明显稳定性高、可调试、可扩展。缺点是前期设计成本高角色划分和工单格式要想清楚。但一旦跑通后面加新能力就是加角色或加工单类型不用动整体架构。2.3 为什么不用“全自动端到端”方案有人可能会问现在不是有那种“给个目标智能体自己规划自己执行”的框架吗为什么还要手动设计角色我的经验是全自动端到端在演示场景很酷但在真实业务里你往往需要知道“它现在在干什么”“为什么这么干”“哪一步出了问题”。全自动方案把这些都藏在黑盒里排查成本极高。“代理机构”模式虽然看起来多了一些“人工设计”的成分但它把过程透明化了。每个角色的输入输出都是可见的、可记录的、可干预的。对于需要稳定交付的项目这种透明性比“全自动”的噱头重要得多。3. 核心细节解析与实操要点角色、工单与上下文管理3.1 角色划分的四个基本盘基于我自己的实践一个最小可用的“代理机构”至少需要四个角色。你可以根据任务复杂度增减但这四个是基本盘角色职责关键输出常见模型选择规划者理解需求拆解任务定义验收标准结构化任务列表强推理模型执行者按任务描述完成具体操作任务结果与过程记录强工具调用模型审核者检查执行结果是否符合验收标准通过/不通过及原因强推理模型汇总者整合各任务结果生成最终交付物最终输出强生成模型这里有个细节规划者和审核者最好用同一个模型或者同级别的模型因为它们都需要强推理能力。执行者可以用稍微轻量一点的模型因为它的任务已经被拆得很具体了。汇总者需要好的语言组织能力但不一定需要最强的推理。注意不要让执行者兼任审核者。我试过为了省调用成本让同一个智能体先执行再自检结果它的自检通过率接近百分之百但人工抽查发现错误率并没有下降。角色分离带来的对抗性检查是这套系统价值的关键。3.2 工单格式的设计要点工单是角色之间传递信息的载体它的设计直接决定系统能不能跑稳。我踩过的坑是一开始工单写得太随意就是一段自然语言描述结果执行者经常理解偏审核者也没法判断对错。后来我改成结构化格式情况好很多。一个任务工单至少包含这些字段任务编号唯一标识方便追踪和引用。任务目标一句话说清楚要做什么不要超过两行。输入数据执行这个任务需要哪些前置信息明确列出。输出要求期望的输出格式、字段、精度。验收标准审核者根据什么判断这个任务完成了。依赖关系这个任务依赖哪些前置任务或者被哪些后续任务依赖。用JSON或者YAML来组织这些字段都行关键是格式统一。我习惯用JSON因为模型对JSON的解析稳定性比较好。下面是一个示例{ task_id: T-003, goal: 根据前两步收集的数据生成一份不超过500字的摘要, inputs: { data_source: T-001的输出, outline: T-002的输出 }, output_format: { type: text, max_length: 500, language: 中文 }, acceptance_criteria: [ 摘要包含数据中的三个关键结论, 没有编造数据中不存在的信息, 字数在400到500之间 ], dependencies: [T-001, T-002] }这个格式看起来有点繁琐但它带来的好处是执行者知道边界在哪审核者有明确依据出问题时能快速定位是哪个字段没理解对。3.3 上下文管理的三个原则多智能体系统最容易出问题的地方就是上下文管理。我的经验是遵循三个原则原则一角色只拿自己需要的上下文。规划者需要全局视野所以它拿完整需求。执行者只需要当前任务的工单和必要的输入数据不要给它看整个任务列表否则它会分心。审核者需要任务工单加执行结果不需要看其他任务。原则二上下文通过工单传递不通过对话历史传递。很多框架默认把对话历史一路带下去这在多角色场景里是灾难。角色A和角色B的对话历史混在一起模型会混淆自己的身份。正确做法是每个角色独立会话工单作为唯一的信息通道。原则三关键信息做冗余校验。比如任务编号在工单里出现一次在执行结果里也要求带上审核时对比两者是否一致。这能拦住一部分“张冠李戴”的错误。3.4 工具调用的权限隔离执行者通常需要调用外部工具比如搜索、读写文件、调用API。这里有个安全细节不要让所有执行者都有所有工具的权限。按任务类型分配工具权限比如负责数据收集的执行者只能调用搜索和读取工具负责写文件的执行者只能调用写入工具。这样即使某个执行者理解错了任务它也没有权限去造成大范围影响。我在一个内容生产项目里就吃过亏一个执行者本来只该读取素材结果它误调了删除接口把中间产物清掉了。后来加了权限隔离每个执行者只能访问自己任务需要的工具这类问题再没出现过。4. 实操过程与核心环节实现从零搭一套可跑的代理流程4.1 环境准备与基础依赖这部分我按最小依赖来讲不绑定具体框架你用任何支持多轮对话和工具调用的模型接口都能实现。基础依赖就三样一个能调用的模型接口支持系统提示词和结构化输出。一个轻量的任务队列或状态存储用来记录工单状态。我用的是本地JSON文件加一个简单的状态机够用了。一个日志系统记录每个角色的输入输出。排查问题时这是救命稻草。如果你用Python大概需要这些库requests或官方SDK用来调模型pydantic用来校验工单格式json和os做本地存储。不需要什么重型框架越简单越可控。4.2 第一步定义角色提示词每个角色一个系统提示词这是整个系统的灵魂。我写提示词的习惯是先写角色定位再写职责边界再写输出格式最后写禁止事项。以规划者为例我的提示词大概长这样你是一个任务规划者。你的职责是理解用户需求将其拆解为可独立执行的任务列表。 职责边界 - 你只负责拆解任务不负责执行任务。 - 你不需要考虑任务具体怎么实现只需要定义清楚每个任务的目标、输入、输出和验收标准。 - 如果需求不清晰你可以在任务列表中增加一个“澄清任务”而不是自己猜测。 输出格式 输出一个JSON数组每个元素包含task_id、goal、inputs、output_format、acceptance_criteria、dependencies字段。 禁止事项 - 不要输出任何解释性文字只输出JSON。 - 不要合并多个任务每个任务必须可独立执行。 - 不要遗漏验收标准。执行者的提示词则更聚焦你是一个任务执行者。你会收到一个任务工单你的职责是严格按照工单要求完成任务。 职责边界 - 你只执行当前工单描述的任务不处理工单之外的事情。 - 如果工单信息不足你输出“信息不足”并说明缺少什么不要自行编造。 - 你只能使用被授权的工具。 输出格式 输出一个JSON对象包含task_id、status、result、process_notes字段。 禁止事项 - 不要修改工单中的任何参数。 - 不要在结果中添加工单未要求的内容。审核者和汇总者的提示词也是类似结构。写提示词的时候禁止事项比职责描述更重要因为模型天然倾向于“多做一点”而多做的部分往往是错误的来源。4.3 第二步搭建任务流转主循环主循环的逻辑不复杂我用伪代码说明def run_agency(user_request): # 1. 规划阶段 task_list planner.run(user_request) validate_task_list(task_list) # 2. 执行阶段 results {} for task in topological_sort(task_list): if not dependencies_satisfied(task, results): continue work_order build_work_order(task, results) result executor.run(work_order) results[task.task_id] result # 3. 审核阶段 for task in task_list: review reviewer.run(task, results[task.task_id]) if review.status ! pass: # 重新执行或标记失败 handle_failure(task, review) # 4. 汇总阶段 final_output summarizer.run(user_request, results) return final_output这里的关键是拓扑排序任务之间有依赖关系必须按依赖顺序执行。我一开始没做排序结果执行者拿到一个依赖前置数据的任务但前置任务还没跑它就开始瞎编数据。加了拓扑排序之后这类问题基本消失。另一个关键是失败处理。审核不通过怎么办我的策略是第一次不通过把审核意见附加到工单里重新执行第二次还不通过标记为失败并通知人工介入。不要无限重试会烧掉大量调用。4.4 第三步工单构建与结果回填工单构建的核心是把前置任务的结果注入到当前任务的输入里。这里有个细节不要注入原始结果要注入经过裁剪的结果。比如前置任务输出了一个很长的文本当前任务只需要其中的一个字段那就只注入那个字段。我试过直接注入完整结果结果执行者的上下文被无关信息占满反而影响了当前任务的判断。后来改成按需注入效果明显提升。结果回填则是把执行者的输出存到结果字典里供后续任务和审核者使用。回填时要校验task_id是否匹配防止张冠李戴。4.5 第四步审核与迭代审核者的提示词要强调“找问题”而不是“确认正确”。我一开始写的审核提示词是“检查结果是否符合验收标准”结果审核者通过率极高。后来改成“你的职责是找出结果中不符合验收标准的地方如果找不到说明你检查得不够仔细”通过率才回归正常。审核不通过时我会把审核意见结构化附加到原工单的review_feedback字段然后重新执行。执行者看到反馈后通常会针对性修正。4.6 第五步日志与可观测性每个角色的每次调用都要记录输入、输出、耗时、token消耗、状态。我用一个简单的JSONL文件每行一条记录。排查问题时按task_id过滤就能看到这个任务从规划到执行到审核的完整链路。这个日志系统看起来不起眼但它是整个项目能不能持续迭代的基础。没有日志你根本不知道问题出在哪个角色、哪个环节。5. 常见问题与排查技巧实录5.1 执行者“自作主张”怎么办这是最常见的问题。执行者拿到工单后觉得任务太简单或者太复杂就自行调整了任务范围。比如让它写500字摘要它写了800字还觉得自己写得挺全。排查思路先看工单的output_format和acceptance_criteria是否足够明确。如果只写了“写一份摘要”那执行者自由发挥是必然的。要写到“不超过500字包含三个关键结论不添加数据外信息”这种程度。如果工单已经够明确但执行者还是跑偏那就是提示词的禁止事项不够强。在执行者提示词里加一句“任何超出工单要求的输出都视为失败”通常能压住。5.2 审核者“放水”怎么破审核者通过率过高通常有两个原因一是审核提示词太温和二是审核者和执行者用了同一个模型且没有角色隔离。我的解法是审核提示词里明确写“你的价值在于发现问题而不是确认正确”并且给审核者一个检查清单让它逐项打勾。另外审核者和执行者用不同的系统提示词最好也用不同的模型增加对抗性。5.3 任务拆解粒度怎么把握拆得太粗执行者还是干不了拆得太细任务数量爆炸调用成本飙升。我的经验是一个任务应该是一个执行者在一轮对话里能完成的最小单元。如果执行者需要多轮工具调用才能完成那说明还可以再拆。如果两个任务之间没有依赖关系且都很简单可以合并。实际操作中我会先粗拆跑一遍看哪些任务执行者反馈“信息不足”或者审核不通过再针对性细化。不要一开始就追求完美拆解迭代两三轮就清楚了。5.4 上下文超长怎么处理多任务跑下来汇总阶段的上下文可能非常长。我的处理方式是汇总者不拿所有任务的完整结果只拿每个任务的摘要和关键字段。摘要由执行者在输出结果时一并生成作为result_summary字段。如果某个任务的结果确实很长且后续任务需要全文那就把全文存到外部存储工单里只放引用路径执行者需要时再读取。这样上下文始终可控。5.5 常见问题速查表问题现象可能原因排查动作解决方向执行者输出偏离任务工单验收标准不明确检查acceptance_criteria字段细化验收标准增加禁止事项审核通过率异常高审核提示词太温和查看审核者系统提示词强调找问题增加检查清单任务执行顺序错乱缺少拓扑排序检查依赖关系解析逻辑实现拓扑排序严格按依赖执行上下文超长导致质量下降注入过多无关信息检查工单输入字段按需注入结果做摘要重复执行同一任务状态管理缺失检查任务状态记录增加状态机标记已完成任务执行者调用未授权工具权限隔离缺失检查工具授权配置按角色分配工具权限5.6 几个我踩过的坑第一个坑工单编号重复。早期我用时间戳做编号结果并发执行时出现了重复导致结果回填错位。后来改成UUID问题解决。第二个坑审核意见没有结构化。一开始审核者输出一段自然语言意见执行者看不懂重点。后来要求审核者输出JSON包含failed_criteria和suggestion字段执行者修正效率大幅提升。第三个坑汇总者编造信息。汇总者拿到各任务结果后为了让最终输出更“完整”会自行补充一些没有依据的内容。解法是在汇总者提示词里强调“只整合已有结果不添加新信息”并且在审核阶段增加一个针对汇总结果的最终检查。第四个坑模型接口不稳定导致任务中断。多任务流程里任何一次调用失败都可能中断整个流程。我的做法是给每次调用加重试机制重试三次仍失败则标记任务失败并继续后续不依赖该任务的部分最后统一报告失败任务。6. 关于这套思路的扩展与个人体会这套“代理机构”模式跑通之后我发现它的扩展性比预想的好。最直接的扩展是增加角色比如在规划者和执行者之间加一个“资源评估者”判断任务需要哪些工具和数据或者在审核者之后加一个“优化者”对通过的结果做进一步提升。每加一个角色只需要定义它的提示词和工单接口主循环基本不用动。另一个扩展方向是角色复用。同一个执行者角色可以起多个实例并行处理无依赖的任务只要工单编号和结果回填做好隔离就行。这在任务量大、时间敏感的场景下很有用。我个人在实际操作中的体会是这套模式最大的价值不是“让智能体更聪明”而是“让智能体的行为可预测、可干预、可追溯”。在真实项目里可预测比聪明重要得多。一个偶尔惊艳但经常失控的系统不如一个稳定输出合格结果的系统。最后分享一个小技巧如果你刚开始尝试这套模式不要一上来就做四个角色。先用两个角色——一个规划者、一个执行者——跑通最小闭环感受一下工单传递和上下文隔离的效果。等这个闭环稳定了再加审核者和汇总者。一步一步来比一次性搭全套然后到处救火要快得多。