三省六部幻觉:为何虚拟公司式多Agent架构在工程上不成立 ✍ SagaSu🕐 2026-04-14📦 13.5 KB 🟢 已读 𝕏 文章列表 文章批判了将多个AI Agent拟人化为“产品经理”、“工程师”等角色进行流水线协作的“三省六部”架构。作者指出该模式忽视了LLM无专业壁垒的特性,导致推理过程在传递中衰减。通过对比Anthropic、OpenAI和Google的工程实践,文章提出真正的多Agent架构应依赖显式状态文件、并行搜索而非线性分工,并强调保持推理链连续性比角色扮演更重要。 Agent架构设计多AgentLarge Language ModelsAnthropicOpenAI工程实践上下文管理技术选型 # 三省六部幻觉:为什么"虚拟公司"式多Agent架构在工程上不成立 **作者**: SagaSu **日期**: 2026-04-14T03:45:49.000Z **来源**: [https://x.com/sujingshen/status/2043898494818410731](https://x.com/sujingshen/status/2043898494818410731) ---  一个在AI社区广泛流传的架构思路,正在让大量团队走弯路。 ## 先说结论 如果你正在考虑把多个AI Agent分别命名为"产品经理"、"架构师"、"测试工程师",让它们像公司部门一样传递文档、协作完成任务——请停下来。 这个模式看起来很直觉,逻辑上似乎很合理,但它在工程上有根本性的缺陷。更重要的是,Anthropic、OpenAI、Google三家厂商在构建自己的Agent系统时,没有一家采用这个模式。 这不是巧合。 ## 什么是"三省六部"式架构  这个比喻指的是一类在社区里广泛流行的多Agent设计思路,在不同框架和文章里有不同名字:role-based agents、virtual team、CrewAI式分工、MetaGPT式组织——本文统称"三省六部"。 核心模式是:把一个复杂任务拆解成若干职能,每个Agent扮演一个角色——PM负责需求、Tech Lead负责架构、Dev负责实现、QA负责测试。任务在Agent之间流转,像一条流水线。 这个模式在图示上非常好看。它满足了人类对"分工协作"的直觉,也让"AI团队"这个概念变得具象可解释。CrewAI等框架正是因此积累了大量用户。 问题在于,它解决的是人类的瓶颈,不是AI的瓶颈。 ## 为什么这个类比从根本上是错的 人类需要分工,是因为: - 单个人的注意力有限,无法同时处理所有信息 - 人有专业壁垒,学习切换成本高 - 人与人之间需要接口来协调 但LLM的特性完全不同: - 同一个模型既能写PRD又能写代码,没有"职业边界" - 模型的瓶颈不是注意力广度,而是推理深度和信息完整性 - 模型之间没有"文化"和"默契"来补偿信息损耗 给Agent贴上"产品经理"的标签,不会让它更专业——但会让它拒绝越界。一个被框死在"测试工程师"角色里的Agent,看到架构层的问题可能直接跳过,因为"不在我职责范围内"。最有价值的推理往往发生在边界上,而三省六部模式在系统层面封死了这个可能性。 角色扮演制造了假边界。这是第一个问题。 ## 第二个问题:信息在流转中死亡  三省六部模式里,Agent A产出一个文档,传给Agent B。 这个过程传递的是结论,不是推理过程。 B拿到文档,重新理解,重新建立上下文。原始意图在衰减,隐含假设在丢失,每次传递都在累积误差。工作流越长,最终输出越"局部正确但整体漂移"——每个节点看起来合理,但整体已经偏离了最初的目标。 人类组织靠会议、文化、非正式沟通来补偿这个信息损耗。Agent之间没有这些机制。 这里有一个常见的反驳:三家厂商的解法(progress.txt、spec文件、runbook)不也是"传文件"吗?区别在哪? 区别在于谁在写、写给谁、怎么更新。 三省六部的信息流转是角色间的单向交接:A写完交给B,B不再回头,A也不知道B怎么用了这份文档。信息被压缩成结论,推理过程丢失,接棒就是断点。 外部状态文件是同一任务的增量日志:执行主体在每个checkpoint时往同一份记录里追加,下一个session读取的是任务的完整历史,不是上一个"同事"的输出结论。写状态的人和读状态的人是同一个角色,只是时间不同。信息不是被"压缩传递"的,是被"连续积累"的。 这个区别决定了推理链能不能跨session保持连续。 大量token被浪费在Agent之间的"交接文件"上,而不是用于实际推理。你得到的是一个模拟公司行为的系统,而不是一个解决问题的系统。 ## 三家厂商实际怎么做的 值得注意的是,当Anthropic、OpenAI、Google真正构建自己的生产级Agent系统时,他们的工程文档里几乎找不到"角色扮演"或"部门分工"的字眼。 Anthropic:Context Engineering + 显式状态文件 Anthropic内部把"Prompt Engineering"升级成了"Context Engineering":问题不是怎么写好一个prompt,而是什么样的token配置最能产生想要的行为。 在构建Claude Code和Research系统时,他们面对的核心挑战是:Agent必须在离散的session里工作,每个新session对之前发生的事情没有任何记忆。他们的比喻是"轮班工程师"——每个新班次的工程师到岗时对上一班的工作一无所知。 解法不是让Agent扮演不同角色,而是: - claude-progress.txt:一个跨session的工作日志,Agent在每个session结束时更新,下一个session开始时读取 - Git history:作为状态锚点,记录每一个增量变化 - Initializer Agent:只在第一个session运行,建立环境、展开feature list、写好runbook,供后续所有session使用  关键洞察:推理链的连续性不靠模型"记住",靠显式的外部状态来锚定。 他们同时发现,把"model能力假设"硬编码进harness是危险的。Sonnet 4.5有"context anxiety"——快到context limit时会提前收尾,于是harness里加了context reset。但Opus 4.5这个行为消失了,reset变成了死重量。这说明:harness需要随模型迭代而演化,任何"永久解法"都只是当前阶段的工程妥协。 在多Agent的Research系统里,Anthropic的架构是orchestrator-worker:一个lead agent分解任务、协调subagent,subagent并行探索不同方向,结果回流给lead agent综合。他们发现token消耗量本身就解释了80%的性能差异——多Agent的价值不是"分工",而是用更多token覆盖更大的搜索空间。 这里有一个容易混淆的地方:Anthropic的subagent看起来也像"分工",但本质完全不同。三省六部是职能性分工——不同角色承担不同工种,PM做完传给Dev,Dev做完传给QA,每个角色只处理流水线的一段。Anthropic的subagent是功能性并行——多个相同性质的agent同时搜索不同方向,没有"下一棒",结果全部汇聚回同一个orchestrator综合。前者是接力赛,后者是同时撒网捞鱼。 OpenAI:Compaction + Skills + 结构化Spec文件  OpenAI给出的长任务原则更直接:在任务开始时就为continuity做规划。 他们的Codex实验里,工程师给agent一个spec文件(冻结目标,防止agent"做出了很impressive但方向错误的东西"),让它生成milestone-based plan,然后用一个runbook文件告诉agent如何操作。这个runbook同时也是共享记忆和审计日志。 结果:GPT-5.3-Codex跑了约25小时不间断,完成了一个完整的设计工具,保持了全程的连贯性。 Server-side compaction作为默认primitive,不是紧急fallback。多步骤任务里,previous_response_id让model能在同一个thread里继续工作,而不是每次重建上下文。 他们还引入了Skills概念——可复用的、版本化的指令集,挂载进container,让agent执行特定任务时有稳定的操作规范。这不是"角色",是工具和操作规程,是本质上不同的东西。 Google:1M上下文 + Context-driven Development Google的方向是硬扩窗口:Gemini的1M token context是明确的差异化策略。他们的逻辑是:之前被迫使用的RAG切片、丢弃旧消息等技术,在足够大的窗口下可以被"直接放进去"所取代。 但他们自己也承认这不够用。Google在Gemini CLI推出了Conductor扩展,核心思路和Anthropic如出一辙:把项目意图从聊天窗口里移出来,放进代码库里的持久化Markdown文件。哲学是:"不依赖不稳定的聊天记录,依赖正式的spec和plan文件。" Gemini 3还引入了Thought Signatures机制:在长session里保存推理链的关键节点,防止"reasoning drift"——长context里逻辑前后不一致的问题。 ## 真正的架构原则是什么 从三家的工程实践中,可以提炼出几个共同的原则: 推理链不能断,只能分叉再合并。 多Agent的正确用法不是流水线,而是一个主agent持有完整意图,子调用是为了深挖某个子问题,结果回流给主agent,不是传给下一个agent。 显式外部状态,不靠模型记住。 progress.txt、git history、spec文件、数据库——形式不重要,原则是:推理链的关键节点必须外化到持久存储里,而不依赖模型在context window里"记住"。 多Agent的价值是并行覆盖,不是分工。 Anthropic Research系统的结论很清楚:性能提升主要来自于"花了更多token",而不是来自"分工更合理"。多Agent适合breadth-first类任务——需要同时探索多个独立方向的场景。不适合需要连续推理、深度依赖上下文的场景。  验证Agent是否定者,不是接棒者。 如果要用多Agent做质量控制,正确的设计是让一个Agent专门找另一个Agent的问题,而不是"传递工作成果"。对抗性检验,不是流水线传递。 工具是工具,不是角色。 给Agent配什么工具(bash、文件读写、搜索、代码执行)远比给它贴什么标签重要。工具决定了Agent能做什么;角色标签只是约束它愿意做什么。 ## 那三省六部为什么会流行? 因为它好解释。 "这个Agent是PM,那个是QA"——这句话任何人都能理解。它满足了人类对AI系统可解释性的渴望,也满足了管理层对"AI像团队一样工作"的想象。  它还好展示。用流程图画出来,有部门、有箭头、有交接,非常直观。 但好解释和好展示,和工程上是否成立是两件事。 更深层的原因是:大多数采用这个模式的团队,并没有真正面对过"上下文在多Agent间传递时的损耗"这个问题。他们的任务可能不够复杂,或者问题被其他因素掩盖了。等到任务复杂度上来,系统开始出现诡异的"局部正确整体错误"时,问题才会暴露。 ## 实践建议 最好的多Agent系统,不像公司。它更像一个思考者的多次草稿——同一个大脑,在不同维度上展开推理,最终合并成一个连贯的结论。 从这个原则出发: 不要问"我需要几个Agent",要问"这个任务的信息依赖结构是什么"。 如果任务需要连续推理、上下文高度依赖(比如写一个复杂功能的设计文档),单Agent + 好的context engineering通常优于多Agent。 如果任务需要同时探索多个独立方向(比如同时研究10个竞品的不同模块),多Agent并行是合理的——每个subagent的任务相互独立,信息损耗代价最小。这正是Anthropic Research系统token量解释80%性能差异背后的原因:不是分工让它更好,是更大的搜索覆盖让它更好。 如果任务跨越多个session,外部状态文件是必须的。一份有效的状态文件应该包含四类信息: - 任务目标(不变,session开始时读取,防止漂移) - 已完成的步骤(追加,不覆盖,保留完整历史) - 当前状态(覆盖,反映最新进展) - 已知的坑(追加,避免下一个session重复踩) 这四类信息分开维护,合在一起就是"下一个自己"需要的完整上下文。 如果要加验证环节,让验证Agent的唯一任务是找问题,不是"接棒继续做"。对抗性检验,不是流水线传递。  最后:模型能力在快速提升,今天harness里需要的workaround,六个月后可能变成死重量。Anthropic已经验证了这一点——Sonnet 4.5的context anxiety在Opus 4.5里消失了,为它设计的context reset随即变成了无用代码。保持架构的可演化性,比选一个"完美架构"更重要。  三省六部是一个让人感觉良好但工程上代价高昂的错觉。它的真正成本不是直接的失败,而是让你的系统在复杂度上升时,以一种难以诊断的方式退化——每个节点都"看起来在工作",但整体在漂移。 等你发现问题的时候,流水线已经很长了。 参考来源:Anthropic Engineering Blog(Building Effective Agents, Effective Context Engineering, Multi-Agent Research System, Effective Harnesses for Long-Running Agents, Managed Agents);OpenAI Developers Blog(Run Long Horizon Tasks with Codex, Shell + Skills + Compaction);Google Developers Blog(Architecting Efficient Context-Aware Multi-Agent Framework, Conductor: Context-Driven Development for Gemini CLI) ## 相关链接 - [SagaSu](https://x.com/sujingshen) - [@sujingshen](https://x.com/sujingshen) - [587](https://x.com/sujingshen/status/2043898494818410731/analytics) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [11:45 AM · Apr 14, 2026](https://x.com/sujingshen/status/2043898494818410731) - [574 Views](https://x.com/sujingshen/status/2043898494818410731/analytics) --- *导出时间: 2026/4/14 19:52:59*
不 不懂 Harness Engineering,你所谓的 AI 转型只是在浪费预算 文章探讨了 Harness Engineering 的概念,即通过设计环境、设定标准和建立反馈来构建 AI 的工程环境,从而将 AI 从简单的聊天工具转化为能持续工作的生产力。文章对比了 OpenAI 和 Anthropic 的不同实践路径,并以 VergeX 为例,阐述了 Harness 在 AI 交易中的具体应用,包括工具调用、上下文管理、架构约束和反馈循环四大核心模块。 技术 › Harness Engineering ✍ Lewis爆肝战神🕐 2026-04-13 AIHarness EngineeringAgentOpenAIAnthropicCodexVergeX架构设计上下文管理自动化
A Agent Harness 拆解:AI Agent 的工程化基础设施 本文深入探讨了 Agent Harness 的概念,即包裹在 LLM 外部、将无状态模型转化为可用智能体的完整软件基础设施。文章引用了 Anthropic、OpenAI 和 LangChain 的实践,详细拆解了生产级 Harness 的 12 个核心组件(如编排循环、记忆系统、上下文管理、验证循环等),并阐述了如何通过优化这层“操作系统”来解决遗忘、工具调用失败和上下文腐烂等工程难题。 技术 › Harness Engineering ✍ 土豆本豆🕐 2026-05-21 AgentHarnessLLM架构设计LangChainClaudeOpenAI上下文管理工程化Agent拆解
A Agent 工程方法实践:Claude Code 与 OpenClaw 的深度对比 文章深入对比了 Claude Code 和 OpenClaw 两个 Agent 框架的工程实现。两者虽都采用 Agent = Model + Harness 的理念,但架构迥异:Claude Code 采用分层堆叠架构,服务于单线程深度编程场景,追求精确可控;OpenClaw 采用管道架构,面向多并发的生活场景,追求自主进化。文章从架构、循环、工具、指令、上下文、记忆等九个维度详细拆解了各自的工程设计权衡。 技术 › Harness Engineering ✍ Mr Panda🕐 2026-04-26 AgentClaude CodeOpenClaw架构设计上下文管理记忆系统工程实践
O OpenAI Agents SDK 重大升级:Harness 与 Sandbox 架构分离 OpenAI 于 2026 年 4 月 15 日升级 Agents SDK,核心是将 Harness 和 Sandbox 做进 SDK 并实现架构分离。新架构将 Agent Loop 托管化,解耦计算与控制逻辑,支持 100+ 模型及多云 Sandbox 环境。对比 Anthropic 的工具箱路线,OpenAI 选择了全托管方案,降低开发门槛。 技术 › LLM ✍ Jason Zhu🕐 2026-04-17 OpenAIAgents SDKAgentAnthropicSandbox架构设计MCP开发工具
代 代理工具的解剖结构 文章深入剖析了将无状态 LLM 转变为功能强大的智能体所需的“代理框架”基础设施。内容涵盖编排循环、工具工程、内存、上下文管理、安全护栏及子代理编排等 12 个核心组件。文章对比了 Anthropic、OpenAI 和 LangChain 的实现策略,指出生产级应用的关键在于模型周围的工程架构,而非模型本身。 技术 › Agent ✍ Akshay🕐 2026-04-07 AgentLLM架构设计OpenAILangChainClaude工程化上下文管理工具调用多智能体
深 深入解读 Harness Engineering:AI 工程的第三次范式转移 Anthropic 和 OpenAI 几乎同时发布关于 Harness Engineering 的文章,引发 AI 社区热议。本文梳理了从 Prompt Engineering 到 Context Engineering 再到 Harness Engineering 的演变,解析了 Anthropic 的“生成器+评估器”循环架构与 OpenAI 的“百万行代码零手写”分层实践,并结合多位博主的观点,探讨了 Agent 时代工程师角色的转变与未来工程实践的方向。 技术 › Harness Engineering ✍ Jason Zhu🕐 2026-03-31 AI工程AgentAnthropicOpenAI范式转移ClaudeCodex架构设计自动化开发者工具
你 你不知道的 Claude Code:架构、治理与工程实践 本文基于作者深度使用 Claude Code 的实战经验,深入剖析了 Claude Code 的六层架构模型。文章详细阐述了上下文治理的成本构成与最佳实践,解释了 Skills、Hooks、Tools 和 Subagents 的区别与设计原则,并分享了如何利用 Prompt Caching 和 Plan Mode 优化系统性能与稳定性。 技术 › Claude ✍ Tw93🕐 2026-03-21 Claude CodeLLMAgent架构设计工程实践上下文管理Prompt Engineering
A Agent工程架构解析:Harness、Loop与Graph的区别 本文深入解析Agent工程中常被混淆的三个架构层级:Harness工程构建模型运行环境与基础能力;Loop工程设计工作反馈循环,通过验证与迭代提升质量;Graph工程则显式定义工作流拓扑,控制节点分支与状态转换。文章强调理清环境、反馈与流的关系对构建生产级Agent至关重要。 技术 › Harness Engineering ✍ beamnxw🕐 2026-07-26 Agent架构设计工程化工作流LangChainOpenAIAgent HarnessLoop Engineering
构 构建智能代理的三层架构:Loop、Graph与Harness 本文提出解决Agent重复读取数据和Token浪费的三层架构方案:Loop负责单元工作的收集-行动-验证闭环;Graph通过分发和并行管理复杂任务;Harness作为运行时环境提供工具和上下文隔离。文中提供了具体的代码实现思路和实战演示。 技术 › Agent ✍ Archive🕐 2026-07-25 AgentLoopGraphHarness架构设计上下文管理Token优化验证机制代码实现
L Let's build Claude Code's harness (step-by-step) 本文深入解析了Claude Code的“harness”架构,解释了为何简单的模型调用不足以构建可靠的代码代理。作者通过CrewAI框架逐步重建了包括核心循环、工具管理、规划机制在内的关键组件,揭示了通过工程化手段弥补模型差距的方法。 技术 › Claude Code ✍ Akshay🕐 2026-07-16 Claude CodeAgentCrewAIHarness Engineering代码代理工具调用LLM工程实践架构设计Context Engineering
构 构建优秀的垂直领域 Agent:以 Shortcut 为例 本文探讨了如何构建一个在实际应用中表现卓越的垂直领域 Agent。作者结合开发 Shortcut 电子表格 Agent 的经验,提出核心原则是“对任务分布的忠实压缩”。文章详细介绍了“分层缓存”架构,将上下文分为 L1(常驻核心)、L2(按需规格)和 L3(兜底参考),以平衡效率与准确性。同时强调了“单工具优于多工具”的策略,主张通过代码执行来统一能力,降低模型决策复杂度,从而在长尾任务中实现高准确率。 技术 › Agent ✍ Peter Wang🕐 2026-06-12 AgentLLM架构设计上下文管理垂直领域性能优化Tool Use代码执行缓存策略
为 为何应用层未死:避开 AI 黄砖路指南 文章探讨了创业公司如何在 OpenAI 和 Anthropic 等大厂的阴影下生存。作者提出了“黄砖路”的概念,指代大厂直接主导的通用领域(如代码生成、写作),并建议初创企业应避开此路径,转而专注于“奥兹国其他地方”——即垂直领域、多步骤工作流及遗留系统整合等大厂难以通过单一模型解决的复杂问题。文章分析了数据飞轮、模型复杂性管理及私有行业知识作为初创公司的护城河。 技术 › Agent ✍ Joe Schmidt IV🕐 2026-05-28 AI创业AgentOpenAIAnthropic行业洞察垂直应用黄砖路模型护城河投资策略