做 AI 应用这几年我越来越明显感觉到一个问题单个智能体再怎么优化提示词碰到多步骤、多数据源、需要反复质检的复杂任务时还是会频繁掉链子。最近在一套叫 Agent-7 的智能体设计模型上折腾了不少项目这套模型把核心思路收敛为四个字团队作战。简单说它不指望一个智能体包揽所有事情而是让多个智能体像项目组一样分工协作各管一摊再通过协作机制把最终结果拼起来。很多刚接触 Agent 开发的朋友会问多智能体协作是不是就是把多个模型实例放在一起让它们互相聊没那么简单。如果只是让几个智能体来回对话跑不了几轮就会陷入信息混乱、任务空转、结论不一致这些坑。Agent-7 能比较稳地跑起来靠的是角色划分、任务拆解、消息协议和裁决机制这四个层面的设计。这篇文章就按这套模型的完整思路拆开讲从原理到代码再到踩坑经验都过一遍。适合正在做复杂自动化任务、研究智能体架构、或者被单个 Agent 的瑕疵折腾到头大的开发者参考。1. 为什么一个 Agent 搞不定能力边界与真实痛点1.1 单个智能体在处理复杂任务时的三个典型瓶颈先说一个我重复遇到过很多次的场景让一个 Agent 做“某产品线的竞品信息汇总与差异化建议”。任务看起来不复杂实际跑起来却问题不断。第一是上下文容量限制。任务步骤一多Agent 需要自己去搜索、打开网页、读文档、整理字段、写分析报告。每一步都会往上下文里塞入大量中间结果。等真正要写结论的时候前面那些早期信息早就被挤到上下文末尾甚至被截断了。结果就是结论里漏掉重要的竞品参数或者把某个中途废弃数据当成最终结论。第二是工具调用链很容易断。单个 Agent 在一条链路上既要规划下一步又要决定调用什么搜索词还要处理页面解析结果更要验证信息是否可靠。任何一个环节出现格式错误、超时或者内容不符合预期它就得停下来反复试错。有些模型不够稳定的时候会在同一个错误上绕好几圈出不来。第三是自我纠错能力偏弱。让模型检查自己的输出本质上是“让运动员自己当裁判”。模型一旦确认了一个错误的中间结论后续所有生成内容都会顺着这个错误往下编而且越编越自信。我见过一个案例Agent 把某产品发布日期写错后后面所有的对比分析都建立在那个错误日期上整体结论完全跑偏。这个体会可以用一个很生活化的类比一个人既当前台接待又当会计记账还要当质检员抽样检查。事情少的时候没问题流程一长角色切换必然出错。Agent-7 解决的就是这个“流程一长必然混乱”的问题。1.2 团队作战思路是如何绕过这些瓶颈的Agent-7 的设计出发点很朴素不再试图让一个智能体变成“全能超人”而是把任务拆成多个专业岗位让每个智能体只负责自己那一亩三分地。这样一来单个 Agent 的上下文就干净了。规划者只负责拆解任务不需要去读几十篇网页执行者只负责处理自己领到的那个子任务不需要为全局方案发愁审查者只负责看结果质量不需要去调工具。每个角色的提示词很短上下文窗口压力骤降出错率自然下来。更关键的是这种设计引入了真正独立的把关环节。执行者输出结果后由另一个角色的审查者去检查而不是执行者自己改自己。两个模型的偏差会形成一种互相牵制的机制执行者可能在分析上漏掉一个角度审查者会反过来补问一句执行者可能弄错一个数据审查者会要求重新核实。这比单 Agent 内部那套“自我反思”靠谱得多。还有一点常被忽略可并行性。团队作战后彼此没有依赖关系的子任务可以分给多个执行智能体同时跑。我实测过单个 Agent 从头到尾串行处理一份多章节调研报告可能要 5 到 8 分钟Agent-7 模式下并行处理后整体时间能压缩到 2 到 3 分钟质量还更稳定。这也是为什么“团队作战”不是概念噱头而是实打实能提效的架构方向。2. Agent-7 的核心架构七个角色、任务协议与消息流转2.1 七个角色的职责拆解为什么偏偏是七个Agent-7 名字里的 7指的不是“七个智能体实例随便堆在一起”而是七个职责互补的角色。这个数量是我实践之后觉得性价比最高的配置少一个就容易失控多一个又让调度变得笨重。角色核心职责类比全局规划者理解总目标拆解子任务分配负责人决定执行顺序项目经理领域执行者执行具体的子任务例如搜索、分析、写作、计算等一线工程师工具操作者负责调用外部能力包括数据库查询、文件读写、接口请求运维/平台组质量审查者检查执行结果是否完整、准确、符合要求输出整改意见质检员风险监控者发现任务执行过程中的异常信息、缺失数据和潜在冲突风控/巡检记忆管理员维护全局状态、关键结论和上下文摘要避免信息过载项目助理决策仲裁者在执行者与审查者意见不一致时做最终判断保证任务收敛决策负责人这个角色配置覆盖了一个完整项目组的核心职能。规划者负责“想清楚做什么”执行者负责“做出来”审查者负责“检查做得对不对”仲裁者负责“吵不拢时有人拍板”记忆管理员负责“别把线索弄丢了”。我尝试过更精简的配置比如把审查和仲裁合并成一个角色虽然能省一次调用但遇到执行者坚持认为自己的结果没问题时没有第三方介入任务会在一个错误结论上打转三四个来回。所以后来我还是保留了这个独立仲裁位。2.2 任务拆解与协作协议用“任务单”而不是“自由聊天”很多多 Agent 系统翻车的根本原因是让 Agent 之间用自然语气自由对话。A 说一句“我觉得你那个结论有问题”B 回一句“你倒是说清楚哪里有问题”这两条消息对任务推进没有任何价值却白白消耗 token还可能把上下文带偏。Agent-7 的做法是给每个角色下发结构化的任务单。任务单是一个固定格式的 JSON 消息包含任务编号、任务描述、输入数据、期望输出、优先级、状态几个字段。每个角色只认任务单只输出结果单不聊闲天。这也是整个系统能稳定跑起来的第一道保障。以规划者为例它接收总目标后必须输出一个数组每个元素都是一张子任务单。子任务单里写清楚谁来做、做什么、交付物是什么。执行者拿到的是干净利落的指令不需要自己想“我为什么要做这件事”“做完之后全局怎么办”它只需要把眼前这一件事做好。任务单机制带来一个额外好处可追溯。任务出问题时我可以通过任务编号快速定位是哪一步的分析结果出了问题。这比在一大段多角色对话日志里翻上下文要高效得多。2.3 消息流转与上下文共享黑板模式的设计思路Agent-7 里各角色之间并不直接私聊而是通过一个类似“黑板”的共享状态区交换信息。所谓黑板模式就是大家不互相发消息而是把信息写到公共区域谁需要谁自己去读。这样做有几个好处。第一避免信息只在两个角色之间流通其他人看不到全貌。第二降低上下文负载每个角色只订阅自己需要的消息类型而不是接收全部对话记录。第三方便做权限控制。全局目标放公共区所有角色可读执行者的中间过程放执行区只有审查者能翻阅最终结论放发布区任何角色都能读取。我用一个项目群来理解这个设计全局目标相当于置顶的那条#全体消息谁进群都能看到某一个执行者的搜索细节相当于私聊消息只有相关同事在意最后发布的报告相当于群公告所有人以它为准。这样的信息流转方式比“所有人拉一个大群谁发言所有人看”要清爽得多。共享内存也不是越大越好。我踩过的坑是把所有执行者的原始输出全部塞进公共区结果每个角色下一次生成时都被一大堆不相干的细节淹没token 暴涨速度骤降。Agent-7 里的记忆管理员角色核心作用就是定期把冗长的执行记录精炼为摘要只把关键结论和未决事项放回黑板让其他角色始终面对的是干净精炼的信息。3. 实操复现从零搭建一个最小版 Agent-7 协作系统3.1 技术选型思路先想清楚要解决什么问题再选框架跑 Agent-7 模型不一定需要重型框架。我最初也想找现成的编排框架试了一圈之后发现很多框架把角色通信、状态管理这些逻辑封装得过于严格我反而需要花大量时间去理解它内部约定。对于自己手头的实际项目我更倾向于写一个轻量调度器核心逻辑控制在几百行代码内后续调整角色数量和协作策略都方便。这里列出我的选型判断标准供参考角色之间靠结构化消息通信不依赖自然语言对话串场。状态存储器优先选简单的比如内存对象或 JSON 文件复杂方案以后需要再上。每个角色本质上是对大模型接口的一次封装所以代码里只保留最薄的适配层。调度循环单独写一个主控模块不要和角色实现耦合。按照这套标准用 Python 就可以实现一个麻雀虽小、五脏俱全的 Agent-7 最小闭环。下面的示例包含规划者、执行者、审查者和主控调度四个部分整体跑通后再往里面加风险监控和记忆管理也不难。3.2 核心代码Agent 基类与主控调度先定义一个消息体和一个基础 Agent 接口保证所有角色都遵循统一的输入输出格式。import json import time from typing import Dict, Any class TaskMessage: 任务单/结果单的统一结构 def __init__(self, task_id, role, action, data, statuspending): self.task_id task_id # 任务编号 self.role role # 负责角色 self.action action # 动作类型plan / execute / review self.data data # 输入或输出内容 self.status status # pending / success / failed / blocked def to_dict(self): return { task_id: self.task_id, role: self.role, action: self.action, data: self.data, status: self.status, }基于这个统一消息结构定义基础 Agent 类。每个 Agent 实例只需要具备能力接收一份输入消息调用大模型或其他工具最后返回一份结果消息。class BaseAgent: def __init__(self, name, system_prompt, llm_call): self.name name self.system_prompt system_prompt self.llm_call llm_call # 注入的模型调用函数 def run(self, message: TaskMessage) - TaskMessage: prompt self._build_prompt(message) result self.llm_call(self.system_prompt, prompt) message.data result message.status success return message def _build_prompt(self, message: TaskMessage) - str: return f请完成以下任务\n{json.dumps(message.data, ensure_asciiFalse)}有了基类之后规划者需要把总目标拆分成长任务单数组所以它的 _build_prompt 要特殊处理一下强制模型输出 JSON 列表。class PlannerAgent(BaseAgent): def run(self, message: TaskMessage) - TaskMessage: prompt ( 你是全局规划者。请把总体目标拆解为具体的子任务清单 输出一个 JSON 数组每个元素包含 subtask、assignee、deliverable 三个字段。\n f总体目标{message.data} ) raw self.llm_call(self.system_prompt, prompt) subtasks self._parse_subtasks(raw) message.data subtasks message.status success return message def _parse_subtasks(self, raw: str): # 调用统一解析器从模型输出中提取 JSON 数组 start raw.find([) end raw.rfind(]) 1 return json.loads(raw[start:end])主控调度的逻辑是整个系统的引擎。它负责把规划者拆出来的子任务分发给执行者再由审查者检查结果不合格就打回重做直到剩余预算用尽。class Agent7Orchestrator: def __init__(self, planner, reviewers, executors, memoryNone, max_loops5): self.planner planner self.reviewers reviewers self.executors executors self.memory memory or {} self.max_loops max_loops def run(self, goal: str) - Dict[str, Any]: # 阶段1全局规划 plan_msg TaskMessage(T000, planner, plan, goal) plan_msg self.planner.run(plan_msg) final_results [] # 阶段2执行与审查循环 for loop in range(self.max_loops): pending [] for task in plan_msg.data: executor self._pick_executor(task.get(assignee)) result executor.run(TaskMessage( task_idtask[subtask], roletask[assignee], actionexecute, datatask, )) pending.append(result) # 阶段3统一审查 approved True for result in pending: review_msg self.reviewers[0].run(TaskMessage( task_idresult.task_id, rolereviewer, actionreview, data{result: result.data, deliverable: result.data}, )) if 不通过 in review_msg.data: approved False # 打回后把审查意见并入原任务进入下一轮 result.data {original: result.data, feedback: review_msg.data} if approved: final_results pending break return {final_results: [r.to_dict() for r in final_results]}这段代码的核心思想是三层循环结构规划一次、执行一轮、审查打到过关为止。注意 _pick_executor 可以根据任务类型选择不同的执行 Agent 实例也可以用同一个执行 Agent 处理不同子任务让调度逻辑保持灵活。3.3 参数与提示词配置真正决定效果的是细节代码只是骨架真正影响 Agent-7 效果的是这些配置细节。第一个是温度参数。我习惯给不同角色分配不同温度规划者用 0.4让它有一定发散空间来提出拆解思路执行者用 0.1尽量保守稳定地完成任务审查者用 0.0保证审查结论不模棱两可。温度不宜都拉高不然执行者会“即兴发挥”输出很多结构化之外的废话。第二个是提示词里的输出约束。规划者和审查者的输出要求必须写成具体的 JSON 结构否则模型经常会在回答里夹带说明文字导致解析失败。我在解析函数里做了一定容错比如寻找首个[和最后一个]来截取 JSON但更稳妥的办法是在提示词里写“不要输出任何解释只输出 JSON”。第三个是轮次上限。我遇到过任务陷入“执行-打回-再执行-再打回”死循环的情况。所以主控里设置了 max_loops 参数循环到第三轮还不过审就强制把已经完成的部分当作最终输出并把审查意见附在结果后。这样至少不会无限消耗预算。第四个是关键的记忆管理策略。执行者之间的中间结果不要全部集中传输。真正实操时我会让每个执行者结果先自动生成一份 200 字以内的摘要审查者优先读摘要摘要信息不足以判断时再读取原始内容。这一步能把整体 token 消耗压缩百分之三十到四十。4. 常见问题与排查技巧实录4.1 智能体之间互相“踢皮球”任务进展不下去这是多 Agent 系统最典型的病执行者交出一版结果审查者觉得不对打回执行者改了一版审查者又提出新问题来来回回三四次任务进度停在原地花费却翻了几倍。排查后会发现根源往往不是模型能力不够而是缺少明确的终局规则。Agent-7 引入决策仲裁者角色后情况改善很多。审查者打回意见时仲裁者会判断这个修改意见是必须的核心问题还是可接受的优化项如果是优化项就直接放行。实操中应给每轮审查设置优先级标签。比如审查结果里必须包含“严重程度”字段阻断级、建议级、风格级。只有阻断级问题才能打回重做建议级问题记录到附录即可。用这个办法整个循环的迭代次数通常能控制在两轮以内。4.2 上下文互相污染结论张冠李戴另一个常见的翻车现场是调研 A 产品的执行者在输出结果里混入了 B 产品的数据。原因多半是执行者们共用了同一个大段上下文A 执行者在生成时看到了 B 执行者的临时记录。这种情况需要强化记忆管理员的隔离能力。共享区不存放执行过程的原始记录只存放经过校验后的结论。执行者读不到其他执行者的工作记录只能读任务目标和自己领域相关的结构化输入。形象一点说就是每个执行者有自己的工作台而不是全公司人挤在一张长桌上办公。我自己的一个习惯是给每个执行者的 prompt 前面加一句限定只基于本次输入数据作答忽略任何与当前任务不相关的历史信息。这句话虽然简单但对防串台有明显的安抚作用。4.3 Token 成本暴涨跑一次任务贵得离谱多智能体的成本通常是单 Agent 模式的三到五倍。这往往是消息转发时复制粘贴过多导致的每个角色都把完整历史带进模型输入而不是只带必要信息。省钱思路三个方向。第一优先用便宜的非最强模型做执行者只有规划和审查用高质量模型第二上下文摘要化每轮结束都让记忆管理员产出一份结构化摘要替代完整记录参与后续流转第三限制重试次数前面提到的 max_loops 其实也是成本保护机制。4.4 问题排查速查表现象可能原因首选排查动作多个子任务结果内容雷同执行者共享了同一个上下文区检查消息路由隔离各执行者输入审查永远不通过审查标准没有严重程度分级在审查提示词中加入优先级标签任务一直在循环打转缺少终局条件或仲裁角色检查主控循环的 max_loops 与仲裁逻辑输出格式解析频繁失败提示词没有强制 JSON 输出优化提示词并加强解析容错某些角色总是不加载信息记忆管理员的摘要过于精简调整摘要长度阈值保留关键结论5. 什么场景才是多智能体协作的主场5.1 真正适合使用 Agent-7 的任务特征经过这些项目验证我觉得适合上“团队作战”模式的任务有三个特征可拆分、可并行、有验收标准。以“跨领域信息采集与报告撰写”为例任务天然可以按领域拆成不同执行者金融、技术、市场三个领域可以并行去查资料统一汇总后再由审查者检查交叉引用的逻辑一致性。这类任务如果用单 Agent 做每一步都串行时间成本和上下文压力都成倍增长。另一种适合的场景是需要严格质检的生成任务。比如批量生成商品详情页文案执行者负责写初稿审查者负责查客观性、合规性和格式完整性。有了独立把关后批量产出的良品率比单 Agent 连续生成要高不少。还有一种场景是长链路自动化流程比如从数据导入、清洗、分析、出图到生成汇报。这种流程往往跨多个工具和数据源由专门的工具操作者管理工具调用、执行者负责业务逻辑、规划者负责总指挥会比一个 Agent 拿着十几个工具来回折腾稳妥得多。5.2 哪些场景不要“硬上团队作战”反过来说很多场景其实不需要多 Agent甚至用单 Agent 性能更快更省。比如简单的问答对话、知识库检索、单步骤翻译或改写这些任务一个智能体加一段干净 prompt 就能完成强行引入角色只会增加延迟和成本。还有一个需要警惕的信号如果你需要多个角色共享的上下文极少任务也没有明显的并行空间那“团队作战”就是过度设计。我曾经把一个只需要两步处理的文本分类任务强行套了三个角色结果总耗时比单 Agent 慢了四倍而且质量没有任何提升。杀鸡用牛刀这是最需要避免的坑。判断方法其实很简单用单 Agent 跑一次看瓶颈在哪里。如果瓶颈是上下文挤爆、工具调用混乱、中间步骤需要反复纠错这三个问题中的某一个再考虑转向 Agent-7如果只是生成速度慢那优化方向应该是模型选型和缓存而不是增加参与角色。5.3 团队规模怎么定不是角色越多越聪明Agent-7 提供的是七个角色位置的参考架构不是说每次都必须七个。我自己的经验法则是量体裁衣最小闭环只需要三个角色——规划者、执行者、审查者任务复杂一些就把执行者按领域拆成多个实例涉及外部工具和不确定数据时再加工具操作者和风险监控者只有当任务周期长、多轮次迭代频繁时才需要记忆管理者和决策仲裁者。执行者也不是越细分越好。我试过把同一个调研任务拆成十个领域的执行者并行跑表面上效率很高但最后汇总阶段审查者面对十份完全独立的输出交叉核对的工作量暴增反而拖垮了整体流程。合理的粒度是让每个执行者输出文档里至少能保证一个完整、可独立验证的章节而不是一句话就可以讲完的碎片。最后再分享一个调多 Agent 时特别有用的小技巧给每一条消息都留下追踪记录。调试阶段不只看最终结果要重点看谁收到了什么、谁输出了什么、哪一步卡住了。我用一个简单的 trace 日志记录每条消息的 task_id、角色、动作、耗时和输出摘要大多数协作问题都能通过追踪记录定位比反复修改提示词盲猜要高效得多。希望这套 Agent-7 的解析和实战分享能帮你在自己的项目里少走几个来回。