本文深入探讨了 Multi-Agent 设计的核心思想强调通过 Orchestrator 集中处理高熵意图将任务分解后分配给 Sub-agents 执行从而高效收集用户需求并推动落地。文章详细阐述了个人多 Agent 工作流程包括不同模型的分工、任务执行与反馈机制并提出了信息压缩与可靠输出分离的设计理念。此外还讨论了 Harness 在提升 Multi-Agent 使用体验方面的作用从开发者、Agent 和普通用户三个视角分析了如何让 Multi-Agent 更顺手。最后总结了 Multi-Agent 设计的重要原则并展望了未来模型与 Harness 的融合发展前景。一、我日常的 multi-agent 工作流开发场景用多 Agent 已经是很多人的基操了主要有两个优势不同场景发挥不同模型的特点合作让多个 Agent 形成自查自纠闭环减少质量管控的人工参与轮次我自己的分工如下GPT 做前台 orchestrator负责和我讨论需求、收束 iteration、定义 goal 和验收标准Fable / Opus 偏后端工程执行K3 偏前端交互实现orchestrator 下发任务时附带严格标准并为每个任务准备独立 worktree各 executor 在独立 worktree 里施工交付时同时提交报告按反馈持续修改orchestrator 审阅不通过则返回结论要求修改通过后做冒烟和集成测试统一合并进入下一轮自动循环。为了同时体验 Harness 获得理论上的最佳模型性能我一般默认协作过程用模型自家的 Harness 跑它包成 Skill 互相调用GPT 用 CodexFable/Opus 用 Claude CodeK3 用 Kimi Code。多次跑下来我发现最高效的方式是每次和 orchestrator 一起梳理一个大的计划书然后让自己去慢慢做可以是持续几天乃至几周的任务orchestrator 从我这获取多个想法我们一起确认细节后他自己自行梳理多个功能的依赖关系和施工顺序产出一个或多个大的计划书和明确具体的实施节奏然后他自己生成任务包定义和安排 sub-agents 分头完成任务、根据他们的交付报告明确是否打回、如何修改、满足要求后统一测试并合并然后进入下一个实施项——周而复始直到整个大的计划书完成过程中遇到拿不准的功能变化或者大的界面变动引入人工确认。关于 orchestrator 的模型选择我的实践感受是大迭代阶段orchestrator 要像一个最严厉的父亲严格评估每个修改对系统架构和后续运维的影响拷打所有 worktree 的提交能否合并Opus 发散性强严谨性差一些K3 前端很棒但后端跟另外的模型比起来还是有差距Fable 和GPT 风格差不多严谨话少更适合这个角色但 Codex 重置确实太香了—— 因而这个阶段 orchestrator 我还是会更偏向选 GPT。修修补补阶段orchestrator 要像一个最耐心的秘书把用户所有细碎的不满意转为需求快速验证不过度设计。我体验下来GPT 不爱列计划容易漏优化点、过度设计Fable 太慢Opus 太啰嗦关注细节的 Kimi 处理这类反而是舒适区——擅长列清单耐心地把细节一点点做完。二、通过 Multi-agent 把信息压缩和可靠输出分开用户输入天然是高熵的目标模糊、约束缺失、优先级不清审美偏好也说不完。执行中还会不断冒出新想法但稳定执行要求低熵输入目标明确、上下文有边界、约束清楚、验收标准可验证。否则执行过程就是一边做一边猜需求最后把模糊性带进实现细节。这是我认为 multi-agent 能够发挥作用的系统增益把任务链路拆成两种性质不同的工作各自推进互不干扰。orchestrator 负责信息压缩接受开放、零散、持续变化的输入通过对话完成澄清、排序、取舍和边界定义形成可执行的任务包。sub-agents 负责可靠输出拿到减熵后的任务包在边界稳定、验收明确的环境里执行按约定返回报告、证据和阻塞项。这个结构其实让人有点想到香农分离orchestrator 类似信源编码器压缩输入中与任务无关的冗余sub-agents 类似信道编码通过报告、测试、验收字段加入结构化冗余让结果更容易检查和纠错。信息传输过程中意图澄清和可靠执行是两类可以分开设计的问题。塞进同一条上下文模型既要猜意图又要自证拆开后两侧可以分别优化也可以选用不同模型。而随着任务越来越长来到数天乃至数周的长任务我认为 Harness 的存在感也会越来越强——怎么从产品层面给用户安全感下面简单讨论一下。三、通过 Harness 让 multi-agent 用起来更顺手任务变长时Harness 怎么让 multi-agent 用起来顺手可以从三类用户视角来看视角怎么算顺手开发者能不能把自己之前的最佳实践 DIY 进去Agent能否方便的自我管理普通用户是否随时知道发生了什么、是否随时可介入3.1 开发者能把自己的最佳实践放进去开发者的掌控感来自”我自己有我自己的最佳实践“因而应当支持开发者根据自己的经验定义一些子 Agent包括使用什么模型、模型定义等给到 orchestrator 去编排和使用参考 Pi 的实现为3.2 Agent 明确的安全权限边界和方便的自我管理工具Agent 的掌控感来自我知道我自己能做什么怎么做。要做到这一点Harness 需要给 orchestrator 提供一套管理子 Agent 的工具和机制——派发、等待、审阅、打回、关闭每一步都显式可控主流 Harness 都做了类似的事情大同小异能力CodexKimi CodeClaude Code派发/创建SpawnAgentAgent/AgentSwarmAgent原Task恢复/追加SendInput/ResumeAgent回调已有实例SendMessage等待Wait后台运行 异步回传隐式等待停止CloseAgentAgentStopTaskStop状态查看agents_statesTaskList/TaskOutputSubagentStart/Stophooks3.3 普通用户信息透明完整随时可介入普通用户的掌控感来自信息透明知道要做什么所有待办和子 Agent 状态实时可见、信息完整知道做了什么所有已办都被记录随时可回溯、随时能介入这要求 Harness 在 runtime 层把子 Agent 当作有身份、有状态、可查询的长期对象来管理——不只是给 orchestrator 看的也是给用户看的。在随时介入这里Codex/Claude Code 和 Kimi Code 体验下来思路是有些差别的Codex/Claude Code 的 子 Agent 启动后主会话进入 wait/review 状态大部分情况下orchestrator 必须等子 Agent 跑完、审完结果、决定通过还是打回才能继续往下走人也需要一起干等。Kimi Code走的是后台模式。子 Agent 作为 background task 启动后orchestrator 立即被释放出来继续跟用户聊天。子 Agent 在独立上下文里跑结果异步回传。子任务运行期间人可以和 orchestrator 继续讨论、追加需求这些新信息也会被及时告知子 Agent 。就我自己体验来说我更喜欢 Kimi Code 这种设计虽然其他 Harness 也可以随时打断 orchestrator但这是一种“串联”的逻辑从我自己的实际感受来说因为有时任务书的任务很长Kimi Code 这种“并联”的设计能让我在不干扰 Agent 当前运行情况下及时补充和澄清自己的想法而非“先等等看再决定怎么改“我和 Agent 是“冰壶”式协作双方一起推着任务往前走而不是“乒乓球”式协作把任务抛来抛去。四、小结小结几条我认为比较重要的设计原则拆不拆多 agent 让 orchestrator 判断但人可以参与和自定义。子 Agent 默认多 Worktree 工作orchestrator统一集成验证和合并。子任务可见、明确的安全和任务边界、新想法随时可承接。multi-agent 虽然在一些情况很香但成本也很实在更多 token、更长等待时间。不过我的判断是随着 multi-agent 的实际数据越来越多未来什么场景要用 multi-agent 这件事模型自己就能做好判断Harness 做好承接就可以。稍微发散一下当模型能做越来越长的任务或许应用生态的未来也可以是这样如果 Harness 做得足够好手机里只需要有一个 “Orchestrator Agent”所有应用都可以被它“自举”出来——用户只感知到一个入口随时冒出想法就扔给它它在用户的桌面上生成各类应用统一维护。至于怎么把创作门槛降到足够低、让每个人都觉得「创造是一种快乐」——那就是当下做模型和 Harness 要努力回答的问题了。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取 Multi-Agent 设计实践：收藏这份指南，小白也能轻松驾驭大模型协作！
本文深入探讨了 Multi-Agent 设计的核心思想强调通过 Orchestrator 集中处理高熵意图将任务分解后分配给 Sub-agents 执行从而高效收集用户需求并推动落地。文章详细阐述了个人多 Agent 工作流程包括不同模型的分工、任务执行与反馈机制并提出了信息压缩与可靠输出分离的设计理念。此外还讨论了 Harness 在提升 Multi-Agent 使用体验方面的作用从开发者、Agent 和普通用户三个视角分析了如何让 Multi-Agent 更顺手。最后总结了 Multi-Agent 设计的重要原则并展望了未来模型与 Harness 的融合发展前景。一、我日常的 multi-agent 工作流开发场景用多 Agent 已经是很多人的基操了主要有两个优势不同场景发挥不同模型的特点合作让多个 Agent 形成自查自纠闭环减少质量管控的人工参与轮次我自己的分工如下GPT 做前台 orchestrator负责和我讨论需求、收束 iteration、定义 goal 和验收标准Fable / Opus 偏后端工程执行K3 偏前端交互实现orchestrator 下发任务时附带严格标准并为每个任务准备独立 worktree各 executor 在独立 worktree 里施工交付时同时提交报告按反馈持续修改orchestrator 审阅不通过则返回结论要求修改通过后做冒烟和集成测试统一合并进入下一轮自动循环。为了同时体验 Harness 获得理论上的最佳模型性能我一般默认协作过程用模型自家的 Harness 跑它包成 Skill 互相调用GPT 用 CodexFable/Opus 用 Claude CodeK3 用 Kimi Code。多次跑下来我发现最高效的方式是每次和 orchestrator 一起梳理一个大的计划书然后让自己去慢慢做可以是持续几天乃至几周的任务orchestrator 从我这获取多个想法我们一起确认细节后他自己自行梳理多个功能的依赖关系和施工顺序产出一个或多个大的计划书和明确具体的实施节奏然后他自己生成任务包定义和安排 sub-agents 分头完成任务、根据他们的交付报告明确是否打回、如何修改、满足要求后统一测试并合并然后进入下一个实施项——周而复始直到整个大的计划书完成过程中遇到拿不准的功能变化或者大的界面变动引入人工确认。关于 orchestrator 的模型选择我的实践感受是大迭代阶段orchestrator 要像一个最严厉的父亲严格评估每个修改对系统架构和后续运维的影响拷打所有 worktree 的提交能否合并Opus 发散性强严谨性差一些K3 前端很棒但后端跟另外的模型比起来还是有差距Fable 和GPT 风格差不多严谨话少更适合这个角色但 Codex 重置确实太香了—— 因而这个阶段 orchestrator 我还是会更偏向选 GPT。修修补补阶段orchestrator 要像一个最耐心的秘书把用户所有细碎的不满意转为需求快速验证不过度设计。我体验下来GPT 不爱列计划容易漏优化点、过度设计Fable 太慢Opus 太啰嗦关注细节的 Kimi 处理这类反而是舒适区——擅长列清单耐心地把细节一点点做完。二、通过 Multi-agent 把信息压缩和可靠输出分开用户输入天然是高熵的目标模糊、约束缺失、优先级不清审美偏好也说不完。执行中还会不断冒出新想法但稳定执行要求低熵输入目标明确、上下文有边界、约束清楚、验收标准可验证。否则执行过程就是一边做一边猜需求最后把模糊性带进实现细节。这是我认为 multi-agent 能够发挥作用的系统增益把任务链路拆成两种性质不同的工作各自推进互不干扰。orchestrator 负责信息压缩接受开放、零散、持续变化的输入通过对话完成澄清、排序、取舍和边界定义形成可执行的任务包。sub-agents 负责可靠输出拿到减熵后的任务包在边界稳定、验收明确的环境里执行按约定返回报告、证据和阻塞项。这个结构其实让人有点想到香农分离orchestrator 类似信源编码器压缩输入中与任务无关的冗余sub-agents 类似信道编码通过报告、测试、验收字段加入结构化冗余让结果更容易检查和纠错。信息传输过程中意图澄清和可靠执行是两类可以分开设计的问题。塞进同一条上下文模型既要猜意图又要自证拆开后两侧可以分别优化也可以选用不同模型。而随着任务越来越长来到数天乃至数周的长任务我认为 Harness 的存在感也会越来越强——怎么从产品层面给用户安全感下面简单讨论一下。三、通过 Harness 让 multi-agent 用起来更顺手任务变长时Harness 怎么让 multi-agent 用起来顺手可以从三类用户视角来看视角怎么算顺手开发者能不能把自己之前的最佳实践 DIY 进去Agent能否方便的自我管理普通用户是否随时知道发生了什么、是否随时可介入3.1 开发者能把自己的最佳实践放进去开发者的掌控感来自”我自己有我自己的最佳实践“因而应当支持开发者根据自己的经验定义一些子 Agent包括使用什么模型、模型定义等给到 orchestrator 去编排和使用参考 Pi 的实现为3.2 Agent 明确的安全权限边界和方便的自我管理工具Agent 的掌控感来自我知道我自己能做什么怎么做。要做到这一点Harness 需要给 orchestrator 提供一套管理子 Agent 的工具和机制——派发、等待、审阅、打回、关闭每一步都显式可控主流 Harness 都做了类似的事情大同小异能力CodexKimi CodeClaude Code派发/创建SpawnAgentAgent/AgentSwarmAgent原Task恢复/追加SendInput/ResumeAgent回调已有实例SendMessage等待Wait后台运行 异步回传隐式等待停止CloseAgentAgentStopTaskStop状态查看agents_statesTaskList/TaskOutputSubagentStart/Stophooks3.3 普通用户信息透明完整随时可介入普通用户的掌控感来自信息透明知道要做什么所有待办和子 Agent 状态实时可见、信息完整知道做了什么所有已办都被记录随时可回溯、随时能介入这要求 Harness 在 runtime 层把子 Agent 当作有身份、有状态、可查询的长期对象来管理——不只是给 orchestrator 看的也是给用户看的。在随时介入这里Codex/Claude Code 和 Kimi Code 体验下来思路是有些差别的Codex/Claude Code 的 子 Agent 启动后主会话进入 wait/review 状态大部分情况下orchestrator 必须等子 Agent 跑完、审完结果、决定通过还是打回才能继续往下走人也需要一起干等。Kimi Code走的是后台模式。子 Agent 作为 background task 启动后orchestrator 立即被释放出来继续跟用户聊天。子 Agent 在独立上下文里跑结果异步回传。子任务运行期间人可以和 orchestrator 继续讨论、追加需求这些新信息也会被及时告知子 Agent 。就我自己体验来说我更喜欢 Kimi Code 这种设计虽然其他 Harness 也可以随时打断 orchestrator但这是一种“串联”的逻辑从我自己的实际感受来说因为有时任务书的任务很长Kimi Code 这种“并联”的设计能让我在不干扰 Agent 当前运行情况下及时补充和澄清自己的想法而非“先等等看再决定怎么改“我和 Agent 是“冰壶”式协作双方一起推着任务往前走而不是“乒乓球”式协作把任务抛来抛去。四、小结小结几条我认为比较重要的设计原则拆不拆多 agent 让 orchestrator 判断但人可以参与和自定义。子 Agent 默认多 Worktree 工作orchestrator统一集成验证和合并。子任务可见、明确的安全和任务边界、新想法随时可承接。multi-agent 虽然在一些情况很香但成本也很实在更多 token、更长等待时间。不过我的判断是随着 multi-agent 的实际数据越来越多未来什么场景要用 multi-agent 这件事模型自己就能做好判断Harness 做好承接就可以。稍微发散一下当模型能做越来越长的任务或许应用生态的未来也可以是这样如果 Harness 做得足够好手机里只需要有一个 “Orchestrator Agent”所有应用都可以被它“自举”出来——用户只感知到一个入口随时冒出想法就扔给它它在用户的桌面上生成各类应用统一维护。至于怎么把创作门槛降到足够低、让每个人都觉得「创造是一种快乐」——那就是当下做模型和 Harness 要努力回答的问题了。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取