前置阅读想看更硬核的实现拆解拓扑调度、Loop 状态机、回传语义、看门狗、AutoVision 拦截链、执行器抽象见同目录《Multi-Agent Orchestrator - 技术路线详解》。 先说结论让最强模型只负责想便宜模型负责干再派一个独立审查者每轮把关配上循环迭代引擎——项目质量上去了账单下来了。这篇文章从三个扎心的痛点讲起拆解我是怎么一步步把公司分工搬进 AI 世界的。️ 源码在这里github.com/MRreeeg/multi_agent_orchestratorMIT 协议中英双语 README含演示截图docs/ 下还有面向开发者的交接文档可直接喂给你的 AI 让它帮你改造 引子为什么你的 AI 项目总是烂尾你大概率经历过这个流程找最强的模型“帮我写一个 xxx 系统”它噼里啪啦输出一大堆看起来很完整你兴冲冲拿去跑——报错、缺文件、逻辑对不上你让它改它改一处崩三处改到第五轮你和它都累了项目烂尾问题出在哪不是模型不行是生产方式不对。一次性生成整个项目本质是让 AI一蹴而就。但好项目从来不是一次写出来的是迭代出来的。而且我想先讲一个更重要的体会——这套系统里没有哪个功能是拍脑袋设计出来的先让一个 AI 干活 → 发现没人查 → 加审查者 → 发现查完没下文 → 加返工循环 → 发现执行者拿到需求就瞎写 → 加架构师……每个功能都是被上一个问题逼出来的。理解了这条链你就知道哪些东西真正重要而不是被功能列表牵着走。下面按重要程度拆解。 一、最重要的把公司分工搬进 AI省钱的核心先算一笔账。一个中等项目的开发过程 规划 几十轮编码 反复自审。全程用旗舰强模型质量稳但每一轮都在烧钱全程用免费/便宜模型钱包笑了但它写的代码你需要用命去 review但仔细想想一个项目里真正需要聪明的环节有几个就两个开头定方案架构设计结尾做判断这活儿干得行不行中间那几十轮的编码执行便宜模型完全能干。所以正确姿势是分工角色用什么模型干什么干几次️ 架构师强模型定方案只跑 1 次⚙️ 执行者便宜模型写代码干活N 轮 审查者便宜模型把关挑刺每轮 1 次贵模型只出想法便宜模型出力气——这就是经济学的比较优势AI 也适用。为什么架构师只跑 1 次计划一次成型、执行多轮修正是最经济的分工。但注意方向错了的时候你可以手动把它拽回来——这就是后面回传目标的用处。 二、便宜模型不能放养审查者 带牙齿的协议就算分工了便宜模型干活还是有两个经典翻车姿势翻车姿势表现后果偷工减料说已完成实际只写了半截你以为好了一跑全是坑卡死空转同一句话反复说、工具反复失败任务永远不结束token 白烧所以便宜模型不能放养——需要一个独立的审查者节点逐轮把关。关键设计审查者说什么你的程序得听得懂。如果审查者输出感觉不太行程序只能把这句话原样贴回去——那是废话返工。所以从第一天起立规矩审查者必须输出 JSON。{decision:blocked,requiredChanges:[端口解析没处理逗号分隔,缺少错误日志],summary:主逻辑可用边界处理不足}编排器解析这个 JSON 驱动状态机blocked就带着 requiredChanges 进入下一轮passed才收工。不靠 AI 的自觉靠协议。真实开发里还有个细节模型经常不守规矩输出前先来一段好的让我检查一下……。解析 JSON 必须用取最后一个 JSON 块的策略解析失败要能降级处理绝不能让整个流程崩掉。 三、好项目是 Loop 出来的迭代 回传目标就算有审查者第一轮写的东西也未必能过审。这时候❌ 推倒重来第一次写的东西全扔了✅带着意见改审查者指出问题 → 执行者针对性修改 → 再审 → 再改……B 就是 Loop 循环干一点 → 审一遍 → 带着反馈改 → 再审。1~10 轮上限兜底防止无限循环烧钱。但这里藏着一个很多人忽略的问题反馈给谁默认情况下审查结论回流给所有执行者。但你的流水线里可能有两个并行执行者——只有 B 的部分有问题让 A 陪跑就是白烧钱。所以做了拖线指定回传目标在画布上从审查者的输出端口拖一条虚线到你想要它回去的节点。拖给某个执行者 → 只有它重跑其他节点复用历史输出零 token 陪跑拖两条线 → 两个都重跑拖回架构师 → 让强模型重新想一想方向错了的时候这比让执行者瞎改十轮都管用↩ 回传 → 架构师↩ 回传 → 执行者B️ 架构师⚙️ 执行者A⚙️ 执行者B 审查者省 token 的逻辑很直白没被点名的人不用陪跑。顺带说个产品思路用户画了一条会成环的线很多系统会弹窗报错。我们把成环翻译成开启循环 指定回传目标——把用户的笨操作变成功能。 四、防卡死每只便宜模型配一只看门狗便宜模型打工还有两个经典事故事故一躺平空转。同一句话翻来覆去说工具反复调用反复失败任务永远不结束token 哗哗流。事故二假装完成。“已完成”——实际只写了半截。看门狗两级处置温柔纠偏常驻进程模式中断当前请求注入引导消息让它继续硬重启救不回来就杀掉进程自动重跑一句话总结便宜模型可以笨但不许躺。真实开发还有个更硬的教训弱模型 全量工具 探索循环温床。免费模型会反复 read/glob/grep数预算、复述计划一个回合拖到 10 分钟。比提示词更硬的做法是给硬约束——禁写禁执行、保留只读工具让它在笼子里干活。 五、设计哲学能确定性接管就不祈祷 LLM 自觉这句话贯穿了整个系统举两个例子。例 1识图AutoVision。便宜模型大多没有视觉看不了截图。传统做法是在提示词里写请调用识图命令——实测非常不可靠它可能忽略提示、没有 curl 环境甚至直接编造图片内容幻觉读图。我们的做法是编排层主动拦截任务文本里出现图片引用 → 先解析出绝对路径注入任务节点模型无视觉 →Orchestrator 直接替它委派一个有视觉的辅助手运行时完成识图识图结果以结构化文本注入任务并明令禁止再调任何识图工具委派失败就如实声明无法识图——绝不编造也不阻塞流水线例 2重启后的诚实世界。服务重启后之前运行中的进程其实全死了。很多系统会假装它们还活着结果用户点进去ERR_CONNECTION_REFUSED。我们的规则重启后一律标记 stopped 清空端口——宁可显示已中断绝不展示点进去就死的假活入口。原则就一条凡是能确定性接管的事就不要祈祷 LLM 自觉。 六、透明化AI 干活不能是黑盒Canvas 画布每个节点实时渲染状态等待/运行/完成/失败连线即流程Runtime Console常驻进程的 Agent 保留运行时小窗实时流式看它在想什么做什么执行记录放大窗每轮的完整输入/输出/token 消耗随时放大细看黑盒变鱼缸一目了然。 七、热点客制化 Agent 导入和贴提示词不是一个东西很多人做多 Agent 的方式是同一个模型塞不同的系统提示词——“你是架构师”“你是测试工程师”。这种方式有个致命弱点提示词约束太脆弱。对话一长就被冲淡模型动不动出戏。我们的方案接入了 deepseek-harness 的客制化 Agent维度提示词约束客制化 Agent本质一段话请你扮演…persona 工具集的完整预设工具引擎默认那套预设自带专属工具集身份挤在系统提示里独立 agent 身份运行管理散落各处统一目录一键导入区别就在于一个是嘴上说说一个是真换了个人连手上的工具都换了。 八、换电脑即插即用程序化自检把整套系统拷到新电脑最烦的是什么这台机器装了哪些 AI、有哪些模型全都不一样。自检 纯程序化探测读配置、跑版本命令、枚举模型列表不用 AI 检查 AI——因为新电脑可能一个 AI 都没装用 AI 检查 AI 会死循环。探测结果直接合并进节点类型目录——而它正是前端所有下拉的数据源。所以换电脑后探测 → 目录更新 → 前端下拉自动变化一条数据管道贯穿零适配代码。️ 技术路线一览CLI子进程Go 单二进制浏览器RESTCanvas 画布原生 JS 无框架SSE 实时推送编排器DAG调度 · Loop状态机 · 看门狗JSON 目录持久化版本链reasonixmimocodexclaudeopencodedsh 客制化Agent几个值得说的技术选择Go 单二进制前端直接 embed 进二进制serve一条命令起服务无数据库无外部依赖SSE 而非 WebSocket单向推送够用实现简单一半子进程调 CLI每种 Agent 就是一个子进程stdout/stderr 全量捕获崩了看得见JSON 版本链持久化每次改动 Canvas 自动存新版本改坏了能回溯 这套东西适合谁✅适合想用便宜模型干活又怕质量翻车的独立开发者有多步骤固定流程规划→执行→审查要自动化的团队预算敏感但质量敏感的个人项目❌不太适合一次性问答、简单脚本杀鸡用牛刀需要 GPU 推理自建模型的场景这套管的是调度与监管不管推理 总结三句话带走经济学强模型只出想法规划审查各一次便宜模型出力气N 轮执行——质量和成本可以兼得管理学便宜模型不能放养——独立审查者逐轮把关 结构化判决协议 看门狗防躺平 能确定性接管就不祈祷自觉迭代论好项目是 Loop 出来的——干一点、审一遍、带着反馈改反馈给谁还能在画布上拖线指定甚至指回架构师重新想AI 编程的下一步不是更强的单模型而是更好的生产关系。 后续计划回传目标支持更多组合策略条件触发审查协议可插拔自定义 JSON schema更多执行器接入如果这篇文章对你有启发欢迎点赞收藏评论区聊优化记录第 1 轮事实核对 叙事闭环核对全部技术细节与真实代码loop-review-v1 协议字段decision/requiredChanges/summary、review_decides 与 fixed 双模式、targetNodeIDs 拖线语义含指回架构师时架构师重跑、非目标节点复用历史输出、stall 两级处置引导继续/杀掉重跑、AutoVision 四步拦截与降级声明、deepseek-harness persona工具集、六种执行器——均一致。JSON 示例字段与真实协议对齐。第 2 轮小白视角 节奏校准全文术语首次出现均有一句话解释serve 模式、persona、SSE 等长段落全部拆短emoji 小节锚点统一经济账保持相对量级表述未虚构具体价格数字。第 3 轮重点重排——基于完整设计认知在通读全项目设计与实现之后重排博客优先级与篇幅——按真正重要的方面排序①分工省钱核心②审查协议监管核心③Loop回传目标迭代独创交互含拖线指回架构师亮点④看门狗防卡死⑤设计哲学能确定性接管就不祈祷自觉AutoVision诚实世界两个例子讲透⑥透明化⑦客制化 Agent 热点⑧自检。新增引子中功能是被问题逼出来的思想主线解释为什么这个排序有意义删除与教程重复的实现细节博客聚焦为什么重要而非怎么实现。