多 Agent 团队编排系统的设计与实测调度、评审链与上下文经济一个调度—编码—评审三岗协作的 LLM 编排系统评审不通过自动退回重试交付物经纯代码核验后才算完成。岗位记忆隔离在同批任务实测中节省 95.5% 的 prompt token。背景与动机让 LLM 独立承担编码任务时假完成是高频故障模型声明任务完成但文件并未生成或代码未经运行验证。单人单会话的结构存在三个固有缺陷缺少独立校对环节。模型自评可运行缺乏可信度验证成本最终回流到使用者身上。上下文膨胀。需求、代码、工具返回混排在一个会话中长任务下 token 成本不可控。完成标准不明确。模型对完成的定义产出代码文本与工程对完成的定义文件落盘、可运行、有输出之间存在偏差且偏差不会被自动暴露。本文介绍我近期完成的一个多 Agent 团队编排系统仓库见文末目标是把分工和验收做成系统能力而不是依赖单模型的自觉。系统架构系统由三个岗位组成各岗位绑定独立的 prompt 文件与记忆空间岗位职责关键约束调度岗scheduler判断输入类型工程需求产出结构化任务表任务表格式由纯代码校验违约即判失败编码岗coder实现任务声明交付文件清单产出须含协作信号与交付声明评审岗tester实际运行被审代码出具结论评审须附运行级证据结论分通过 / 不通过执行流程需求进入 → 调度岗拆解为任务表 → 编码岗执行 → 评审岗实测 → 不通过则退回编码岗、计数加一 → 通过后经交付核验纯代码检查声明文件的存在性→ 完成。退回次数上限由调度代码兜底超限判失败并完整打印现场。系统提供终端与 Web 双入口FastAPI SSE 事件流浏览器内总览流程图随执行逐节点点亮轨迹图按时间生长、退回路径绘制为带编号的回边每次运行结束自动结算本轮 token 消耗。关键机制设计星型调度调度权在代码不在模型岗位间的协作通过信号[请求协作:岗位key]发起由代码解析并派发转派限一层。相比模型自由互调的链式结构转派由确定性代码执行命中率不受模型输出格式漂移影响从机制上杜绝调用链自发扩散避免上下文成本失控。模型负责判断代码负责路由。任务表契约管理岗的产出同样受约束调度岗必须输出结构化任务表任务编号、执行岗位、评审对象、依赖关系由纯代码解析校验编号必须连续、每个产出型任务必须绑定评审任务。问候、纯问答等无需拆解的输入走直接回复通道不硬拆任务。设计意图系统里不存在特权角色调度者的产出和管理执行者一样受合同约束。评审链闭环与交付核验评审岗的结论只代表实测运行未报错。系统在此基础上叠加第二道闸——交付核验编码岗声明的文件清单由纯代码逐项检查存在性含路径归一化声明带前缀的相对路径亦正确判验。声称生成而未生成判失败。原则凡是能写成确定性代码的判断不交给模型。岗位记忆隔离与上下文经济每个岗位的记忆按工程岗位双键隔离工具调用的中间消息执行后沉淀丢弃仅结论进入历史历史按滑动窗口裁剪。实验数据同批任务对照实验3 个需求 × 双岗位同模型同工具唯一变量为记忆架构记忆架构prompt tokens相对倍数全员共享一份会话全量重发、工具消息全累积433,74422.12×岗位独立记忆 工具消息沉淀 滑动窗口19,6111×节省 95.5%补充对照同批任务不带工具调用时两种架构差距仅为 1.40×。说明上下文经济的主要收益来自工具循环——工具消息在共享会话中逐轮回灌其体积被记忆架构差异放大。工具调用越密集岗位记忆隔离的收益越大。工程实践与踩坑记录解析器的全半角兼容。用户以中文全角括号输入协作信号【请求协作:tester】全角冒号解析失败。修复所有面向模型自由输出的正则解析统一全半角一视同仁。对自由输出的解析宽容度即健壮性。分类判据的结构性表述。需求做个自我介绍网页版曾被调度岗判为闲聊走直接回复通道——提示词示例中自我介绍一词与让 Agent 自我介绍撞词。修复后判据改为结构性特征凡要求产出交付物的需求一律拆解与关键词解耦。截断的感知与恢复。编码岗工具循环中两次出现 completion 精确等于 max_tokens4096的截断输出被掐断、工具参数 JSON 残缺、解析失败被静默吞掉后以空参数空跑。修复分三层截断感知finish_reason length打标记、工具轮数上限超限回灌收尾提示假完成由交付核验兜底、参数解析失败按截断错误回灌被掐断的关键调用同轮补发一次。配置的显式化。排查发现请求超时时间 30 秒全代码库无赋值点实际生效值一直来自参数字段默认值配置化改动无法生效。已改为显式模块常量并接入配置。局限与路线图当前版本定位为架构验证原型局限如实列出每次运行为全新团队且工作区清零跨运行的修改型需求“在此基础上调整”尚不支持——工作区与记忆的跨运行保留已列入路线图直接回复通道的输出无结构化兜底偶发不符合预期的答复格式回归测试为 18 个打桩场景零 API 消耗覆盖调度、契约、评审链主路径尚不含端到端压测。已支持Docker 单命令部署镜像 273MB运行时 7 个真实依赖、终端与浏览器同一调度内核、每轮 token 账单结算。总结这套系统验证了三件事多 Agent 协作的可靠性来自机制契约、计数、核验在代码层而非模型自觉岗位记忆隔离的 token 收益可量化、可复现且与工具调用密度正相关确定性代码与 LLM 判断的边界越清晰系统越可控。仓库地址github.com/LiMuBai-QiuWuJi/agent-workflow含完整文档、小白向上手指南与一次真实运行的交付示例欢迎 Issue 交流。如果这篇文章对你的多 Agent 实践有参考欢迎转发交流。