模型只占一成：Stack Overflow 论"Agent = 模型 + 脚手架"，LangChain 只改配置提 13.7 个点

先说清楚：这不是一条新闻，是一篇观点长文

今天要聊的这篇东西，发布在 10 月 7 日的 Stack Overflow 官方博客上，是他们"编码 Agent 操作系统"系列的第六篇。它不是某个产品发布、不是融资、不是 benchmark 新纪录，而是一篇带着明确工程立场的方法论文章。但它值得被当成资讯认真读一遍，原因在于它给出了一个相当挑衅的数字，和一个几乎每个重度用过 coding agent 的人都能对号入座的观察。

挑衅的数字是这个：在公开的 Terminal-Bench 2.0 评测上，LangChain 的一个 coding agent 从第 30 名开外一路爬到了前 5，分数从 52.8% 涨到 66.5%，整整 13.7 个百分点。而达成这一切的方法是——模型一个字没换，改的全是模型之外的"脚手架"：系统提示词、工具集、自我验证和循环检测之类的中间件。能对号入座的观察是：第一次用 coding agent，你会惊呼"它把代码读懂了，还顺手写了个测试"；到第三十次会话，它开始重复翻已经看过的文件、推翻自己三周前做的决定、随手猜一条测试命令跑，甚至悄悄不再写测试了——因为没人强制它写。

文章的核心论点浓缩成一句话就是："agent = 模型 + 脚手架"（the agent is the model plus its harness），而"模型也许只占一成"（the model is maybe a tenth）。剩下那九成——提示词、工具、上下文策略、钩子、沙箱、子 Agent、可观测性——决定了你一个季度下来到底能不能拿到可用的软件。诚实地说，绝大多数 agent 的失败不是模型太笨，而是配置失败：缺了一个工具、规则写得太含糊、没加护栏、上下文窗口被噪声塞满。所以当质量在长项目里衰减，杠杆几乎从来不是"等一个更聪明的模型"，而是脚手架——而和模型不同，脚手架是你自己能造的。

对我们来说，这篇的价值在于它把 vibe coder 每天真实的痛点，提炼成了一套可以抄作业的工程方法论。值得注意的是，它和我们站内之前发的两篇内容正好形成互补：接工具（MCP 客户端接入指南）讲的是给 agent 接上能力，测质量（Evals 评测体系）讲的是怎么验证它干得好不好，这篇讲的是怎么把一个 agent"养"长期可信——"接/测/养"三部曲，凑齐了。顺带一提，本站周期 40 的资讯《大脑装上了身体：Agnes AI 开源 Agent 执行底座 AGH》谈的是执行层基础设施，和这篇的"脚手架工程"是同一场战争的两条战线。

13.7 个百分点：同模型，只换脚手架

先把这个数字聊透，因为它太容易被误读。Terminal-Bench 2.0 是一个公开的终端任务评测集，考的是 agent 在真实命令行环境里完成任务的能力。LangChain 的 agent 在这个榜上从 30 名开外冲进前 5，提升了 13.7 个百分点。原文反复强调的限定词是：模型完全没变。变化清单只有三项：系统提示词、工具选择、以及自我验证、循环检测这类中间件。

为什么这个数字重要？因为在 2026 年的 AI 圈子里，性能提升的叙事几乎被模型厂商垄断了：每次 benchmark 刷新都意味着"新一代模型"。但这个案例证明了一个反叙事：同一个模型，换一副脚手架，性能天花板可以凭空抬高十几个点。这对独立开发者的意义非常具体——你没有训练模型的预算，但你有改提示词、调工具、加检查点的自由。换句话说，这 13.7 个点是"穷人版的模型升级"，人人可得。

更深一层的含义是评测观的变化。原文的潜台词是：如果一个 benchmark 的结果高度依赖脚手架配置，那么"这个模型有多强"和"这个 agent 有多强"就是两个完全不同的问题。你看到某个 agent 在某个任务上惊艳，可能只是它的脚手架恰好适配了这个任务类型；你换了个场景翻车，也不代表模型不行。以后再看到"某某 agent 屠榜"的消息，先问一句：是模型强，还是脚手架调得好？这个区分，是这篇观点长文送给读者的第一个实用判断力。

四个腐烂点：为什么 agent 第三十次会话会犯蠢

文章把 agent 的长期衰退拆成了四个具体病症，每个都配了一剂处方。这种"病症—处方"的写法是全文最值得借鉴的地方，因为它把模糊的"agent 不靠谱"变成了可修复的配置问题。

第一个病症是纪律（Discipline）：agent 会跳过测试、悄悄扩大需求范围。处方是"每次会话必读的宪法文件"——一份精简的、声明不可谈判项的文件。第二个病症是上下文（Context）：agent 总在重新学习这个仓库。处方是分层维护的 CONTEXT.md，由钩子自动更新。第三个病症是记忆（Memory）：被纠正过的错误会重复犯。处方是持久化的、按事实分文件的记忆库。第四个病症是评审（Review）：单一视角的盲区会被均匀地应用到每一处。处方是多视角的 agent 评审团。

这四个病症的排列其实有讲究：它们按 agent 协作生命周期的顺序展开——先有纪律（知道该怎么做），再有上下文（知道这是什么项目），再有记忆（记住过去的教训），最后有评审（有人挑刺）。对个人开发者来说，这四个里面最痛的往往是第二和第三个：你肯定经历过 agent 在同一个仓库里第三次问你"这个项目怎么跑测试"，也肯定经历过它重复踩你上周刚纠正过的坑。这两个病症的处方，恰好是后面要细讲的"分层 CONTEXT.md"和"持久记忆"，也是整篇文章里最可以直接复制到你个人项目里的部分。

六件套之壹：宪法文件——每次会话必读的几条铁律

所谓"宪法"（constitution），就是一份精简的、每次会话都加载的文件，声明那些不可谈判的东西：工作流循环是"计划→文档→实现→测试→评审→提交"；测试必须和实现在同一个 diff 里；不留死代码；提交信息遵循规范；适配器纪律——领域代码里不直接依赖厂商 SDK。

关键约束是"保持简短"。因为这份文件每次对话都要读，每一行都在消耗上下文预算。所以宪法只写"不可谈判项"，不写操作手册。这是一个很实用的设计原则：很多人给 agent 写的 AGENTS.md 动不动上千行，把指南、规范、历史背景全塞进去，结果 agent 在长会话里反而抓不住重点。原文的态度很明确——宪法是法律条文，不是百科全书。写不进一页纸的，就不配叫宪法。

对 vibe coder 的直接启发：如果你已经在项目里放了 AGENTS.md，不妨做一次"宪法化"手术——只保留那些"违反了你就想骂人"的条款，把教程式的内容挪到别处。少即是多，在这里是字面意思：每一行都省上下文。

六件套之贰：自主边界——可逆的事放手，不可逆的设卡

这是全文我认为杠杆最高的一个决策：让 agent 在一切可逆的事情上自由发挥，只在两件不可逆的事情上设卡——推送到远端，和部署。用权限配置表达出来就是：允许读、改、写、搜索、git add/commit、跑测试和构建；需要你确认的是 git push、npm publish、aws、terraform apply、kubectl apply；直接禁止的是 git push --force 和带 --no-verify 的操作。

这个设计的妙处在于它重新定义了"自主"的边界。很多人的做法是两个极端：要么每一步都让 agent 请示，累死自己；要么全权放开，然后在某个深夜发现它把 main 分支 force push 了。而原文的方案是：按"可逆性"切分。本地改代码、跑测试、提交到本地分支——这些都可逆，放手让它干；push 和部署——不可逆，才需要人类 checkpoint。这样 agent 可以连续工作一小时、提交十几次，你只需要在 push 的时候看一眼。

还有一个容易被忽略的工程细节：原文提醒要核实你所用运行器的匹配语义——前缀匹配和子串匹配不一样，否则 --no-verify、--force 的拒绝规则和 npm publish 的拦截可能根本没触发；像 npm:* 这样宽泛的通配还会悄悄放行 npm publish。这是一个典型的"以为设了护栏其实没设上"的坑。复制这个权限配置时，务必在自己的环境里实测一条拒绝规则真的生效，别只看配置文件写得漂亮。

六件套之叁：分层 CONTEXT.md——根 200 行，过期即 bug

一个巨型上下文文件会腐烂，还会烧光预算。原文的方案是分层：根目录的 CONTEXT.md 是地图——项目是什么、怎么跑和测试、模块的一行索引、不变量、状态存在哪，限制在 200 行左右，每次会话启动时读；每个模块自己的 CONTEXT.md 写职责、关键文件、依赖、坑、怎么单独测这个模块，编辑该模块前读；DECISIONS.md 是 append-only 的决策记录——日期、决策、原因、被否决的备选方案。

这里最狠的一条规则是："过期上下文就是 bug，和让它过期的那次改动在同一个 change 里修掉，不是什么'以后再说'。"（stale context is a bug, fixed in the same change that invalidated it）。这句话把文档维护从"良心活"变成了"构建红线"。想想我们平时：改了模块职责，CONTEXT.md 里还写着旧的；agent 下次读到旧描述，做出错误决策，根因却是你三个月前那次没更新的改动。把"更新上下文"变成和改代码同一个 diff 的强制动作，这条规则本身比任何工具都值钱。

对个人项目的实操建议：先只做根 CONTEXT.md，200 行封顶，写清楚"怎么跑、怎么测、模块索引"这三样。等项目大到一个文件装不下，再拆模块级。DECISIONS.md 可以从今天就开始 append——它的完整形态（多 agent 共享时的决策日志）后面会细讲，但单人单 agent 阶段它就是个"为什么当初这么定"的备忘录，三个月后的你会感谢现在的你。

六件套之肆：持久记忆——回答"改这里会坏什么"

上下文描述的是代码，记忆存放的是代码告诉不了你的、跨会话的东西。原文给的结构是：memory/ 目录下，MEMORY.md 做索引（一行一个事实），每个事实单独一个文件（类型分用户偏好、反馈、项目、参考），再加一个 graph.jsonl，用 {from, rel, to} 三元组把模块和决策表示成节点，关系是 depends-on（依赖）、adapts（适配）、supersedes（取代）。

这个图要回答的问题，是 agent 最不擅长的那一个："如果我改这里，会坏什么？"（what breaks if I change this?）这是全文里我最喜欢的一个细节。它精准地指出了当前 coding agent 的能力断层：agent 擅长"读懂这段代码在干什么"，但极不擅长"推断改动的影响半径"。人类工程师靠的是在脑子里维护一张依赖关系图，而 agent 每次会话都是失忆的。把这张图写下来、持久化，就是在给 agent 外挂一个它自己长不出来的器官。

对 vibe coder 来说，这部分的 ROI 可能被低估了。你不需要一开始就建完整的图，可以从记录"坑"开始：每次 agent 踩坑、你纠正它之后，把"别这么干+为什么"写成一条记忆。下次它再想这么干，记忆先把它拦下来。积少成多，三个月后你的 agent 会比别人的"更懂你的项目"——这种项目专属的默契，是换再强的模型也买不来的。

六件套之伍：多视角评审团——五个透镜，一个 verdict

与其让 agent 自己 review 一遍（本质上是用同一套盲区再检查一遍），不如并行跑几个聚焦的子 agent，每个只戴一个透镜，输出格式严格统一：产品视角（解决的是不是当初说的那个问题？有没有范围蔓延？在计划阶段介入）、架构视角（正确性、数据模型、失败模式、耦合）、基础设施视角（资源限制、部署回滚、韧性）、安全视角（鉴权、输入校验、密钥、审计链）、测试工程视角（这个测试套件是真的，还是 happy-path 的样子货？每次改动都介入）。

每个评审员的输出格式是：[BLOCKER|MAJOR|MINOR]（置信度%）——文件:行号——问题——修复建议；最后给一个 VERDICT。只有高置信度的 BLOCKER 和 MAJOR 才真正设卡，用置信度阈值防止评审团把你淹没在鸡毛蒜皮里。

这个设计里有两个值得玩味的判断。第一，评审的多样性比评审的"智能"更重要——五个平庸但视角不同的评审员，比一个聪明但只有一个视角的评审员更能发现问题。这和人类代码评审的经验一致：最有价值的 comment 往往来自那个"不懂你这块业务、但懂安全/性能"的人。第二，置信度阈值是防噪音的关键。没有阈值的多 agent 评审会迅速退化成"大家来找茬"，把真正重要的 BLOCKER 淹没在几十条 MINOR 里。对个人开发者，实操上可以先只上两个透镜：测试工程（每次改动）和安全（涉及鉴权和外部输入时），等流程跑顺了再加。

六件套之陆：PostToolUse hook——把"记得更新文档"变成自动的

这是把前五件套粘在一起的那一块：一个在每次编辑后触发的钩子（PostToolUse hook）。在 settings.json 里配好，指向一个很小的脚本：每次 Edit/Write/MultiEdit 之后，脚本从标准输入读到工具事件，吐出一段 checklist 作为上下文——"这次改动有没有改变模块职责/关键文件/坑？有就更新最近的 CONTEXT.md；有没有动依赖或 API？有就给记忆/图谱加一条边；有没有形成先例？有就在 DECISIONS.md 里记一行；有没有产生持久事实？有就更新记忆。并且这些更新就在本次 change 里做——过期上下文就是 bug。"

关键的设计选择是：钩子只负责"提醒"，不负责"悄悄改写"——agent 在同一个 diff 里做出这些更新，全部可评审、可见。这和某些"自动整理文档"的工具形成对比：后者在你没注意的时候改了你的文档，前者把提醒变成上下文、把执行留给 agent、把 diff 留给你看。

这也是全文工程味道最浓的一处：它承认了一个现实——"记得更新文档"靠自觉是靠不住的，靠 code review 抽查也是靠不住的，只有把它变成每次编辑后自动触发的机制，才靠得住。对 vibe coder 来说，这是成本最低、见效最快的一件：一个几十行的小脚本，解决的是"文档永远落后代码三个版本"这个老大难问题。如果你这六件套只想先抄一件，抄这个。

一个 agent 的完整回路：六件文物 + 一个循环

把六件套串起来的工作流是这样的：会话开始时读根 CONTEXT.md 和 MEMORY.md；每个任务走"计划→评审团审计划→你批准→实现子任务（测试在同一个 diff）→评审团审 diff→全量测试+lint→提交→钩子刷新上下文/记忆/图谱→下一个"；只有 push 和部署会停下来等你。

原文的总结是：这就是一个 agent 的全部脚手架——六件文物加一个循环。每一件单独看都只是几行配置或一个 markdown 文件，但合在一起，就是"一个惊艳一下午的 agent"和"第一千次编辑依然可信的 agent"之间的区别。

这个"第一千次编辑"的提法值得停留一下。我们评估 coding agent 时，几乎只看"第一次会话"的表现——demo 惊艳、benchmark 高分。但真实项目的成本发生在第 30 次、第 300 次会话：那时候拼的不是模型的聪明程度，而是脚手架能不能阻止熵增。原文实际上提出了一个新的评估维度：agent 的"保鲜期"有多长。下次你选 agent 工具，除了看它首跑多惊艳，不妨问一句：它有没有机制保证自己三个月后不犯蠢？

多 agent 协作：别让它们"聊天"，让它们"读写同一个世界"

一个 agent 被脚手架管好了，能稳定产出几个月。但当你让好几个 agent 同时工作在同一个仓库里，一种新的失败模式出现了：它们互相撞车——改同一个文件、撤销彼此的工作、重新争论另一个 agent 已经定下来的决策。直觉的解法是让它们"互相沟通"，但原文明确反对：沟通不可扩展、不可靠。真正管用的是人类团队并行协作的老办法——通过共享的、写下来的状态来协调，而不是通过对话（coordinate through shared, written state, not conversation）。Agent 之间不直接发消息，它们读写一小批共享文件：谁拥有哪块、什么定了、什么被认领了、什么做完了。每个 agent 作用于"世界"（仓库加这些文件），下一个 agent 读世界来决定做什么。协调变成共享状态的属性，而不是对话的属性——这意味着它经得起重启、可审计。原文还打了个比方：昆虫就是这么盖大工程的，靠改变和读取共享环境，而不是靠开会。

具体的共享状态有四样。所有权地图（ownership map）：谁拥有哪块路径，默认按目录划分，改别人地盘或共享目录（比如 shared/contracts/**）需要先认领。认领/释放（claim/release）：便宜的互斥机制，不需要锁服务器——开工前写一条 CLAIM（时间、agent、任务、路径、预估），完工写一条 RELEASE（时间、agent、任务、commit）。进度日志：append-only、带时间戳，agent 启动时读最近一天的，快速知道"做到哪了、谁在干哪块"。决策日志：append-only，阻止 agent-B 悄悄推翻 agent-A 深思熟虑过的决定——这个重要到值得单独展开。

其中最诚实的一处，是原文对 claim/release 的自我拆台：它直说这套机制是建议性/乐观的，不是真锁——两个 agent 可能同时扫描、同时看到"没人认领"、同时认领同一块路径（经典的 TOCTOU 竞态）。真要互斥，得用带原子 check-and-set 的原语：比如名字唯一的 git 分支（已存在的 push 会失败），或者协调存储的条件写入。文件追加式的认领，只在"碰撞很少、有人来合并"的场景下够用，"别把它当锁来卖"。这种"先给出方案、再亲手标出它的边界"的写作方式，是这篇文章可信度的重要来源，也是我们转述时不该丢掉的部分。

另外三条防散架的规则同样实在：每个任务一个分支、人类负责合并（未评审的改动不进 main，合并就是人类的 checkpoint）；禁止 agent 之间直接调用（掐掉隐藏的旁路，所有协调留在可审计的文件里）；每个模块声明稳定的公开接口（防止并行的重构互相打断）。以及两条铁律：决策 append-only 且有约束力；碰共享路径或别人的地盘，先认领。

决策日志：append-only 的 DEC-017，和"状态是算出来的"

每个有点规模的系统都会积累决策：用什么数据存储、agent 只能提议不能执行、模型流量走统一网关、哪个组件允许循环、哪个不允许。六周之后没人记得为什么，有人"顺手修"了一个，承重的选择就被悄悄推翻了。经典解法是架构决策记录（ADR）。在 AI 参与建设的项目里，决策日志不只是卫生习惯——它是阻止人类和 agent 互相矛盾的机制。人类团队有走廊记忆，agent 没有。一个 agent 接手任务时读日志，学到必须遵守的约束，就不会去推翻一个它看不见原因的选择。

原文给的示例条目是 DEC-017："我们把所有模型流量都走一个网关。原因：限流、成本统计、 kill switch、换供应商都在一个地方。被否决的备选：各服务直调 SDK（成本和耦合会散得到处都是）。"条目短而结构化，值钱的是"原因"和"被否决的备选"——正是这两样阻止了决策每季度被重新争论一遍。

更精妙的是"状态是派生的"这个设计：你想改主意，不编辑旧条目，而是追加一条新条目，比如 DEC-031："取代 DEC-017：网关同时处理 embeddings，不只处理 chat"。每条条目有个 supersedes 指针，而"是否被取代"这个状态不是存下来的字段，是算出来的——当且仅当存在一条更新的条目把 supersedes 指向它，它才算被取代。于是历史（包括反悔）本身就有价值：它讲述了系统思考是怎么演化的，而一条半旧的条目永远不会"悄悄变错"，它只会被明确地标记为已取代。

但光记下来不够，记了没人执行的日志会腐烂。所以要把日志接进评审：让 diff 里违反已接受决策的改动被打回。实现抓手是两个字段：governs（这条决策约束哪些路径——没有它，门禁不知道哪些决策适用于这个 diff）、forbids_imports（一条便宜的、完全可机器检查的违规规则，比如禁止引入某些 SDK；更复杂的检查交给人类或 agent 评审员）。这样决策日志就从"会腐烂的文档"变成了"构建过程主动维护的约束"。要改决策，agent 写一条取代条目并 flag 人类，永远不许绕过它悄悄写代码。

原文还给了"记什么、不记什么"的清单：记那些不显然、难逆转的——架构、数据存储、安全姿态、agent 自主边界、以及"被人悄悄 undo 你会恼火"的东西；不记代码里已经写明白的、 transient 的实现细节、可以随便改的东西、 trivia（注水会淹没重要的条目）。这个清单本身就很值得抄：很多团队的 ADR 死因就是什么都记，最后没人读。

我们的判断：模型正在变成商品，差异化在往脚手架迁移

把这篇观点放在 2026 年的时间线里看，它其实是对上半年叙事的一次纠偏。上半年大家卷的是模型：参数、上下文长度、benchmark 分数；下半年越来越多有分量的动作出现在模型之外——执行层、脚手架、可观测性、技能沉淀。结合本站周期 40 那篇 Agnes Harness 的报道看，趋势很清晰：模型在商品化，差异化正在往脚手架和执行层迁移。

对 vibe coding 读者的直接意义有三层。第一，选工具别只看模型：下次评估一个 coding agent，问三个问题——它有没有持久记忆机制？它的上下文策略是什么？它的评审/护栏长什么样？这三个问题的答案，比"它背后是某某模型"更能预测你三个月后的体验。第二，从今天开始攒你自己的脚手架：宪法文件、分层 CONTEXT.md、记忆目录、PostToolUse 钩子，这些都不依赖任何厂商，今天就能在你的项目里落地。你的 agent 越来越"懂你的项目"，这种项目专属的默契是换模型买不来的，它是你作为独立开发者真正的护城河。第三，用"保鲜期"思维评估一切：demo 惊艳不重要，第一千次编辑还靠谱才重要。任何 agent 工具，先看它有没有对抗熵增的机制。

最后说点冷静的。这是一篇观点长文，不是论文：13.7 个百分点这个数字来自 LangChain 自己在 Terminal-Bench 2.0 上的实践，原文没有给出完整的实验对照细节（比如脚手架各组件的消融实验），把它当成"方向性证据"比当成"精确科学结论"更合适。另外，六件套全套落地的成本不低——多视角评审团意味着每次改动的 token 开销翻几倍，对个人项目要量力而行，先上钩子和宪法这种"便宜又大碗"的。观点可以激进，落地要渐进。

但方向本身，我们认为是站得住的：当所有人都能用上差不多聪明的模型时，拉开差距的恰恰是模型之外的那九成。而那九成，是你今天就能开始造的东西。