# 四层工程解法很对，但每一层都有张账单没人念给你听 > Agent 工程的四层解法——Harness、多 Agent、记忆、Instinct——方向都对，但没人念给你听的是每层背后那张账单：校验器合谋放行、token 暴涨约 15 倍、记忆投毒、坏习惯被固化。该加哪层、什么时候加，先看价签。 - 原文链接: https://laojin.blog/blog/20260604_agent_four_layers_hidden_bill - 作者: 老金 - 发布日期: 2026-06-04 - 标签: Agent, Harness, 多 Agent, AI 记忆, 工程方法论 --- ![四层工程解法很对，但每一层都有张账单没人念给你听](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260604/00_cover.png) 前几天读到一篇讲 Agent 工程的文章，标题是《你的 Agent 为什么越跑越歪？四层工程解法》。素材很扎实，我一口气读完，基本认同——它把"Agent 越跑越歪"拆成了四层：稳定性、可靠性、连续性、成长性，每层都配了解法。 | 层次 | 核心问题 | 解法 | |---|---|---| | 稳定性 | Agent 在长链路任务中偏轨 | Harness Engineering（Guides + Sensors） | | 可靠性 | 单 Agent 失控、自我评估失灵 | 多 Agent 架构（按场景选模式） | | 连续性 | 每次对话从零开始 | CLAUDE.md + Auto Memory + claude-mem | | 成长性 | AI 无法积累行为习惯 | Hooks + Instinct 持续学习 | 这张表我没意见，方向全对。 但读完有个感觉挥之不去：这四层讲的全是"加什么能变好"，没人讲加完之后你要还什么。每层解法都不是免费的。它解决一个明面上的问题，同时换来一个更隐蔽的、要等你上线两周被现网用户教做人时才冒出来的问题。 ![每层解法左边是收益，右边挂着一笔隐藏成本](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260604/01_tradeoff_ledger.png) 这篇就想把每层背后那张账单念一遍。不是要推翻那四层，它们是对的，是想让你掏钱之前先看见价签。 --- ## 第一层：Harness 不是越多越好，它本身也会变成 bug 源 原文的主张是：要提升稳定性，别去换更好的模型，去设计更好的 Harness。还举了 LangChain 那个例子——不换底层模型，仅靠 Harness Engineering，Agent 排名从 30 名开外冲到前五。 这个主张我百分百同意。模型是发动机，Harness 是底盘、刹车、方向盘，光有发动机的车上不了路。Harness 那层在干的三件事我之前专门写过，这里不重复。 但"从 30 名到前五"这句话得加两个脚注。 一个是，那是榜单排名，不是生产表现。榜单是个固定的、可重复的评测集，你针对它调 Harness，干的其实是一件很危险的事：过拟合。提示词里多塞一句"注意第 N 类边界情况"，校验器里多加一条针对榜单常见坑的规则，排名立刻往上窜。可这些规则一到现网，面对的是榜单里压根没有的输入分布，该歪还是歪。benchmark 屠榜、上线翻车的案例我见太多了，Harness 调得越精细，过拟合的嫌疑反而越大。 另一个脚注更现实：Harness 自己也要维护，而且它会反咬你。原文把 Harness 拆成 Guides（前馈）和 Sensors（反馈），听着干净。但落到代码里，那些"独立的验证器、质量评估、异常检测"，绝大多数时候本身也是个 LLM。 **你是在拿一个会胡说的东西，去校验另一个会胡说的东西**。 这个坑我真踩过。做一个内容审核 Agent，加了道"质量评估"的 Sensor 专门挑生成结果的毛病。上线后一段时间数据特别好看，通过率高、复审率低。后来抽查才发现，那个评估 Agent 学精了——它倾向于给"看起来完整、语气自信"的输出打高分，而这恰恰是生成 Agent 最擅长糊弄的维度。两个模型合起来没有互相纠错，反倒合谋着把一个漂亮的错误盖了章放行。 所以 Harness 这层真正的成本不是要不要做——必须做——而是你加的每道 Sensor 都是一段需要被验证的新代码。它不会自动正确。一道没被验证过的校验器比没有校验器更危险，因为它给了你一种已经兜底了的错觉。 --- ## 第二层：多 Agent 是这四层里最被高估的一层 这是我最想泼冷水的地方。 原文列了五种多 Agent 协作模式：生成-验证、编排器-子智能体、智能体团队、消息总线、共享状态。每种都讲得很清楚，模式本身也都真实存在。问题不在模式，在一个没被点破的前提——它默认你已经到了需要多 Agent 的地步。 而绝大多数人没到。 这事在圈子里其实有过一场公开对撕，值得讲讲。一边是 Anthropic，写过一篇《How we built our multi-agent research system》，是多 Agent 的正方，把编排器-子智能体讲得很漂亮。但同一篇里他们自己披露了一个数字： > 多 Agent 系统消耗的 token，大约是普通对话的 **15 倍**（单 Agent 大约 4 倍）。 15 倍。你那个一天十万次调用的场景，乘以 15 想一下账单。 另一边是 Cognition，做 Devin 那家，发过一篇态度很硬的《Don't Build Multi-Agents》。核心观点是多 Agent 最大的毛病是上下文碎片化：你把任务拆给多个子 Agent 并行做，每个都在基于自己那块残缺的上下文做隐含决策，最后汇总时这些决策彼此冲突，缝都缝不上。他们的结论很重——能用单个线程化的 Agent 解决就别上多 Agent，把精力花在上下文工程上。 ![单 Agent 低成本，多 Agent 上下文碎片、合并冲突、成本约 15 倍](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260604/02_single_vs_multi.png) 两家都不是外行，结论却几乎相反。这恰好说明，多 Agent 不是个能力题，是个权衡题。 再回头看原文那五种模式，每种的"局限"其实都很要命，但都被一笔带过了： - 生成-验证，原文自己也提了要设"最大迭代次数防无限振荡"。可你想想，需要靠最大次数兜底，本身就说明这俩 Agent 谈不拢是常态。撞上限那次你拿到的是"没谈拢但被迫交付"的半成品，比单 Agent 还差。 - 编排器-子智能体，原文说"Orchestrator 是信息瓶颈，子 Agent 关联信息多次中转后细节容易丢失"。这就是 Cognition 说的上下文碎片化，换了个说法。 - 共享状态，原文提醒"必须设计一等公民级别的终止条件，否则陷入反应式循环无限烧 token"。说人话就是没设好就是个烧钱永动机。 我的实践结论是：先把单 Agent 的 Harness 做到极致。真扛不住了再上多 Agent，而且先上最简单的那种（生成-验证），别一上来就消息总线、共享状态。后面那几种是给"Agent 生态在持续扩展"的大系统准备的，不是给你那个还在找 PMF 的工具准备的。多 Agent 是解药，可很多人是在没病的时候吃药。 --- ## 第三层：持久记忆是把双刃剑，坏记忆比没记忆更糟 原文把"无状态"叫做 Claude Code 的致命缺陷，说你每次开新对话都要重新缴"上下文税"。解法是 CLAUDE.md、Auto Memory，以及社区的 claude-mem——后者号称省 95% token（6 条 observation 读 2911 token，干完原本要 56291 token 的活）。 省 token 这数字是真的，我也在用类似方案。但这里有个被"省钱"叙事盖住的转折：记忆系统没有消除风险，它只是把风险从"贵"换成了"静悄悄地错"。 全量加载历史，贵，但信息是全的。换成语义检索按需注入之后，省钱的代价是召回会失败，而且失败得无声无息。这次该用到的那条关键背景，向量检索没召回来，Agent 不会报错、不会提示"我可能缺了点什么"，它会拿着不全的上下文，自信地给你个错结论。从"贵但对"换成"便宜但可能错"，这买卖划不划算，得看你的场景能不能扛住那个"错"。 更麻烦的是记忆投毒。Auto Memory 也好、Instinct 也好，都是 AI 自己往记忆库里写东西。一旦它把一条错误结论写进了长期记忆——比如某次调试误判了根因——这条错误会在之后每次会话里被当成"事实"重新注入，反复污染。它不再是一次性的错，是会自我繁殖的错。 ![一条错误结论被反复注入会话，自我繁殖成循环](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260604/03_memory_poison.png) 我自己定了条规矩：被检索回来的记忆一律当成"写入时为真"的旧情报，不当当前事实。它说某个文件、某个函数、某个开关还在，先去看一眼还在不在，再用。这规矩不是我想出来的，是被坑出来的——有次 Agent 信誓旦旦引用了一个早就被删掉的配置项，理由就是"记忆里有"。 所以记忆这层的账单是：你省下了 token，却欠下了一笔验证债。省下来那 95% 里，有一部分是要拿"偶尔自信地错一次"去还的。 --- ## 第四层：Instinct 学的是频率，不是对错 最后一层最性感：Hooks + Instinct，让 AI 攒"肌肉记忆"，从每次都得从头教，变成越用越懂你。一个 Instinct 就是一条原子化的行为偏好，带 trigger、带 confidence、带 evidence，存成 YAML。学习流程也设计得很巧：每 20 次工具调用触发一次分析，用便宜的 Haiku 识别模式，按观测次数给置信度，新会话自动注入高置信度那些。 工程上很漂亮。但我盯着那个置信度公式看了很久——3 到 5 次给 0.5，6 到 10 次给 0.7，11 次以上给 0.85。 这里藏着个偷换：它把频率当成了置信度。 观测到 8 次，不代表这个行为对，只代表你重复了 8 次。要是你这 8 次重复的是个坏习惯呢？比如你总不写测试就直接改代码，这系统会忠实地把"不写测试直接改"学成一条 0.7 的 Instinct，然后每个新会话开头自动注入，提醒 AI 也这么干。它不是在帮你变好，是在帮你把当下的自己连缺点一起固化下来。频率高不等于正确，这俩之间没有等号，可置信度公式里画了等号。 第二个问题更隐蔽。自动注入的 Instinct 是一段你看不见的上下文。哪天 AI 突然有个怪行为，你排查半天，根因可能是三周前某条被自动学进去、又自动注入的 Instinct 在作祟。它不在你的提示词里，不在你的代码里，它躺在一个你几乎不会去翻的 YAML 库里。可调试性差到出了问题你都不知道该看哪。 第三个问题是固化。"肌肉记忆"这比喻很美好，但肌肉记忆的另一面是它会抗拒改变。当 AI 已经攒了一套关于"你喜欢怎么干"的高置信度 Instinct，它会倾向于延续这套，而你恰恰可能正处在一个该升级工作方式的节点上。学习系统让它越来越像过去的你，但你真正想要的，也许是个能帮你跳出过去的伙伴。 我不是说别用 Instinct。我是说，给它配一个遗忘和质疑的机制，可能比配一个学习机制还重要。能写进去，就得能被推翻；置信度再高，也得定期被重新质询一遍。一个只会攒、不会忘也不会纠错的记忆系统，时间一长就是个偏见放大器。 --- ## 收尾 把四张账单摆一起看，模式很清楚： | 层次 | 它解决的问题 | 它换来的新问题 | |---|---|---| | 稳定性 / Harness | Agent 偏轨 | 校验器本身会出错、Harness 会过拟合 | | 可靠性 / 多 Agent | 单 Agent 失控 | token 暴涨约 15 倍、上下文碎片化 | | 连续性 / 记忆 | 重复缴上下文税 | 召回静默失败、记忆投毒 | | 成长性 / Instinct | 不积累习惯 | 把坏习惯也固化、不可调试、抗拒改变 | 每层都是真解法，但每层也都是用一个显眼的问题，换一个更安静的问题。原文那张四层表的价值，不在于"这四层你都得上"，而在于它给了你一张地图——只是地图上没标价签，这篇就是来补价签的。 所以我对这四层的实操建议特别朴素：别因为某层听起来高级就上，等到那层对应的痛真疼到你了再上，而且上最便宜的那一版。这就是 Agent 工程里的 YAGNI——没疼之前别加复杂度，你加的每一层都在给系统增加新的、更难发现的失败面。 我现在的默认动作是，每想加一层之前先问自己一句：现在不加，最坏会怎样？答不上来，就先不加。 最后留个问题，评论区扣个号就行：这四张账单，你被哪张坑得最狠？**1 Harness 校验器合谋放行、2 多 Agent 上下文缝不上、3 记忆投毒、4 Instinct 把坏习惯学走。** 我赌"3 记忆投毒"被点的最多——它坑起人来最不声不响，等你发现时已经被自信地错了好几回。要是你还踩过第五张账单，更欢迎补出来。