去年 6 月刚开始做 AI 工程化的时候，想法很朴素：让模型帮忙写代码，快一点。真跑起来才发现，问题不在"写不写得出来"，而在"写出来之后怎么办"。生成快，但验证慢；单次能跑通，换个场景就崩；一个人的经验调出来的 prompt，换个人完全不是那回事。
过去大半年，我从单点提效逐步走到系统化的工程治理，认知被反复推翻了好几次。这篇系列写的是目前在 Harness 这个方向上的理解和实践。
这篇先不讲具体实现，只回答四个问题：
- 模型原生能力的缺口在哪里。
- 哪些缺口会被模型能力缓解，哪些仍需要工程手段补位。
- 额外建设一套 Harness 工程体系，在成本结构上是否成立。
- 如果成立，接下来到底要做哪几件事。
第一节：模型原生能力的六个缺口
在实际项目中，模型出问题很少是因为"它不够聪明"。更多时候，是模型原生能力和企业工程交付之间存在缺口。这些缺口不是某一次 prompt 没写好，而是当前主流大语言模型架构和 Agent 工作方式下的系统性限制。
这六个缺口可以分成三组。
第一组是信息问题：该知道的不一定进得来，进来了也不一定看得见、留得住。上下文窗口限制、注意力衰减、知识断层与记忆衰减，都属于这一类。
第二组是生成问题：模型拿到了信息，也可能在生成过程中编造、跳步、推理链退化。生成幻觉和推理退化属于这一类。
第三组是行为一致性问题：同一套规则、同一个模型，换一个模块、换一段上下文，行为不一定稳定复现。泛化不稳定属于这一类。
具体到工程实践里，反复撞上的主要是六个。
实践里反复撞上的六类问题
1. 上下文窗口限制：信息装不下
对话一长，前面的信息要么被截断，要么被摘要压缩。不是"记不清"，是物理上消失了。在一次长会话中执行多步骤任务时，模型在第三步突然跳过了协议指令：它本该停下来等人确认，但早期的指令已经被上下文压缩吞掉了。窗口装不下，再精确的约束也会变成模糊印象。
2. 注意力衰减：信息在，但没被用上
上下文窗口限制是物理消失，注意力衰减更微妙：信息还在窗口里，没被截断，但模型"视而不见"。注意力机制天然倾向近期内容。早期制定的架构约束，那些在对话第三轮就定下来的关键规则，到了第三十轮仍然在上下文里，但模型对它们的注意力权重已经被最近十几轮的讨论稀释了。不是忘了，是"没注意到"。
3. 生成幻觉：没有依据，也会给答案
编造不存在的 API、数据库表、框架方法，这是概率生成机制带来的系统性风险。模型不是在"查资料"，是在"预测下一个 token"。当训练数据和当前上下文里没有可靠依据时，它仍可能生成一个"看起来合理"的 token 序列，而不一定主动暴露不确定性。更麻烦的是，模型通常无法稳定识别自己正在编造，除非有人指出，或者编译报错。
4. 推理退化：步骤越长，偏差越会累积
比幻觉更隐蔽的是多步推理的质量下降。单步任务模型表现很好；但当任务需要连续多步，比如先理解需求、再设计方案、再生成代码、再对照需求自检，每一步的微小偏差都会在链条中累积放大。越是复杂的 Feature，模型的自主完成度越低。不是因为不够强，而是推理链本身在退化。
5. 泛化不稳定：同一套规则，换场景就失效
同一套规范，同一个模型，A 场景严格遵守，B 场景完全无视。在一个真实项目中，同一个 Feature 类型的两个不同模块，同一套代码规范，一个严格遵守，另一个却出现了违反架构约束的生成。Prompt 中的微小差异，比如上下文长度、前置对话的语气、任务的复杂度，都会影响注意力分布。只靠同一套 prompt，很难获得稳定、可预期的质量。
6. 知识断层与记忆衰减：不知道，也留不住
模型的知识有两个天然断层。时效断层：训练截止日期后的框架更新、API 版本升级，模型一概不知。私有断层：企业自研的组件库、内部框架，互联网上没有，模型训练数据里没有。它不知道一个内部方法会悄悄修改参数，也不知道团队的异常处理约定是什么。
记忆是同一枚硬币的另一面。对话关了，所有上下文、决策过程、修复记录全部消失，下次从头开始。即使不关对话，上下文压缩和注意力稀释叠加，后期产出质量也会持续下降。同一个问题的两种表现：模型无法跨时间保持知识的一致性。
关键认知
这六个缺口中，有一些正在被模型侧快速缓解（头部模型的上下文窗口已经从 128K 扩展到 1M），有一些短期内仍很难只靠模型自己解决（私有知识断层、跨 session 记忆）。搞清楚这个分界线，才能决定该把工程化投入花在哪里。这些不是普通 bug，而是当前模型能力和企业工程交付要求之间的结构性错位。好的工程化不是假装消除它们，而是系统性地管理它们。Harness 做的每一件事，都可以回溯到"在补哪个能力缺口"。
第二节：行业在往哪走
行业也不是原地等这些问题消失。各厂商正在从不同方向突破。看清这些方向，才能判断哪些问题需要 Harness 承担补位，哪些问题会随着模型能力提升而逐步变薄。
方向一：长任务持续执行 + 自我验证
智能体不再满足于单轮问答，而是执行跨度数小时甚至数天的复杂任务：读代码库、写代码、跑测试、修 bug、继续写。最关键的进展是：不仅跑得久，而且跑的过程中能主动验证自己的产出。
2026 年 4 月，Anthropic 发布 Claude Opus 4.7。公开数据中，SWE-bench Verified 达到 87.6%，SWE-bench Pro 达到 64.3% （引用1）。但比分数更重要的是一个新的能力：自我验证。模型在生成代码后会主动写测试、运行 sanity check、检查自己的输出，确认没问题才交回来。
同月，OpenAI 发布 GPT-5.5，把模型能力重点放在长链路 Agent Runtime 上。给它一个多步骤任务，让它自己规划、使用工具、持续执行。Terminal-Bench 2.0 达到 82.7%（引用2）。
开源侧，月之暗面发布 Kimi K2.6（1T 参数 MoE，32B 激活，MIT 开源），在长达 12 小时的自主任务中完成了 4000+ 次工具调用，包括阅读代码、编写优化方案、运行测试、修复失败用例，将目标推理引擎的吞吐从 15 tokens/sec 提升到 193（引用3）()。
方向二：SDLC 重塑，从"写代码"到"编排智能体"
Anthropic 2026 年趋势报告给出了一个判断：软件工程师的角色正在从"写代码"转向"编排写代码的智能体"（引用4）。这句话背后对应的是软件开发生命周期的重组。
传统 SDLC 是线性的：需求 → 设计 → 编码 → 测试 → 部署，人在每个环节手动推进。AI 工程化之后的 SDLC 变成了一个流：人定义意图 → 智能体集群并行执行 → 自动验证 → 人审查关键决策点 → 发布。编码环节从"人类的主要工作"变成了"智能体的战术执行"，人的角色从"写代码的人"变成了"编排智能体的人"。
同一份报告还给出了具体数字：开发者约 60% 的工作中使用了 AI，但能"完全委托"给 AI 的任务只占 0-20%；约 27% 的 AI 辅助工作是"没有 AI 就不会去做"的增量（引用4）。有效的 AI 协作不是简单替代，而是重新分工：人做战略决策，模型做战术执行。
这对 Harness 意味着：工程化的重心从"怎么写好代码"转向"怎么设计智能体可理解、可执行的规范体系"。Spec 推导链路、验收体系、Hooks 约束，不是附加的优化项，而是新 SDLC 运转起来必须的基础设施。
方向三：应用范围扩展，智能体正在进入更多领域
前面两个方向解决的是"怎么做得更可靠"。还有一条线容易被低估：智能体正在进入过去只有人类能做的领域，不只是写后端代码，而是操作完整的计算机、理解视觉界面、甚至直接服务非技术用户。
最直观的体现是视觉层面。Anthropic 的 Computer Use 让 Claude 可以实际操作桌面：打开浏览器、运行应用、截取屏幕、用视觉模型分析界面状态、对比预期行为。OSWorld-Verified 上达到 78.0%，超过了人类基线（72.4%）（引用5）。这不是传统的"看图写代码"，而是反向的：看自己写出来的代码跑成什么样，然后判断是否符合预期。产品完成度验证是 Harness 当前最依赖人力的环节，当模型能通过视觉自己判断完成度时，人的角色从"逐屏检查"退到"抽查确认"。
但视觉只是一个切面。同一份趋势报告显示，法务、市场、产品经理这些非技术角色也开始用智能体编码。乐天的工程师让 Claude Code 在一个 1250 万行的代码库中自主工作了 7 小时，实现了特定算法 99.9% 的数值精度（引用6）。智能体的应用范围正在从"辅助写函数"扩展到"独立完成系统级任务"。
这件事的关键不只是多模态，而是模型开始具备自己的"完成标准" 。不是人告诉它"这里不对"，而是它自己看界面、自己判断"这跟设计稿不一致"。从"人定义完成"到"模型判断完成"，这是自主性的质变。
这对 Harness 意味着什么
这三条趋势落到 Harness 上，不是看热闹，而是会改变工程层的厚度分布：
| 趋势 | 缓解的缺口 | Harness 的变化 |
|---|---|---|
| 长任务执行 + 自我验证 | 推理退化、生成幻觉 | 编排层可以少做过程看护，把重心转向结果验收；验证层仍保留，但从"发现低级错误"转向"确认业务完成度" |
| SDLC 重塑 | 行为一致性问题、知识断层 | Harness 的重心从 prompt 技巧转向工程协议：Spec 怎么表达、Agent 怎么分工、门禁在哪里触发、人在哪些节点拍板 |
| 应用范围扩展 | 知识断层、完成度验证不足 | 模型可以参与 UI、交互、非编码任务的完成度判断；人工验收从逐项检查退到抽查和关键决策确认，但最终标准仍由人定义 |
所以，模型变强并不意味着 Harness 消失，而是 Harness 的厚度重新分布：少一点过程看护，多一点验收设计；少一点 prompt 约束，多一点结构化 Spec；少一点人工逐项检查，多一点关键节点拍板。这也是"可拆卸设计"的来源。每一层都要知道自己在补哪个缺口，也要知道什么时候可以变薄。
国内外的能力断层：公开基准之外的实践观察
但这里有一个现实：上面三个方向的领先者，主要还是国外闭源模型。
先看公开数据：上面提到的 SWE-bench Verified 上 Claude Opus 4.7 达到 87.6%，GPT-5.5 在 Terminal-Bench 上达到 82.7%。月之暗面的 Kimi K2.6 在开源模型中已属顶尖，但在部分长任务和编码基准上，与头部闭源模型之间仍有分差。
但公开数据只讲了一半的故事。下面这段来自作者在企业项目中的主观评测，样本涉及内部代码和业务语义，不公开细节，也不作为通用模型排行榜。它只用于解释 Harness 厚度差异。
在这些内部任务里，我观察到的差距常常大于 benchmark 分差。原因在于，SWE-bench 和 Terminal-Bench 衡量的是一个相对"干净"的任务切片：给定的代码库、明确的修改目标、有限的上下文长度。而真实项目中的 AI 编码是长程的、累积的：模型要在几十轮对话后还记得前面定的架构决策，要在数千行上下文中精确找到需要修改的位置而不改错别处，要在连续几个小时的任务执行中保持一致的代码风格和质量水平。
在实践里，Claude 主要是在这里拉开体验差距。它对长上下文中的早期约束更稳定，自我验证行为也更主动：生成代码后写测试、跑 sanity check、确认没问题才提交。这个行为模式未必能被单一 benchmark 完整测出来，但在真实编码中会直接影响"交回来的代码能不能直接用"。
当一个团队在真实项目里跑了几十个 Feature、累计上万行代码之后会发现：基准分数上的差距，会在可用率、返工次数、人工介入频率上被进一步放大。这些东西不在大多数公开 benchmark 里，但它们正是 Harness 要解决的核心问题。
同一个 Harness 概念，不同厚度的实现。
用 Claude 构建 Harness：模型自己能猜对更多隐性约定，能主动验证自己的输出，能跑更长时间不跑偏。Harness 可以做得更薄，少一些显性规则、少一些硬约束、少一些中间验证步骤。
用国内模型构建同一套 Harness：相同的架构概念、相同的三层结构、相同的 Hook 机制，但每一层都要做得更厚。知识显性化要更细（模型猜不对的隐性约定更多），硬约束要更多（模型自我纠错能力弱），验证层要更密（首过成功率更低）。工具链的厚度是被模型能力缺口撑出来的。
这不是贬低国内模型。它反而解释了 Harness 为什么存在：Harness 的厚度，是对模型能力缺口的工程化补偿。 缺口越大，补偿越厚；模型能力追上来，Harness 就可以变薄。"可拆卸设计"的价值不在于一开始就追求极致精简，而在于不被技术进步抛弃。
能力断层正在催生两种不同的运行模式。
在国外，模型厂商开始做一件更激进的事：Managed Agents（托管 Agent 运行）。 OpenAI 把 GPT-5.5 定位为"agent runtime, not a chat model"。它不是只给你一个 API 让你自己去调，而是在他们的基础设施上直接运行整个 Agent 生命周期。Anthropic 的 Claude Code 也在向这个方向演进。这背后有两个前提：一是模型能力强到可以长时间自主执行不出大错，二是厂商自己有充足的算力来托管这些 Agent 的运行环境。
在国内，情况更微妙。强模型并非没有，GLM 5.1 本身就针对长任务做了优化，实际效果并不差；在简单任务上，配合足够厚的 Harness，已经可以实现托管运行。模型可以自己写 CRUD、跑编译、修 bug，人工盯守的频率明显下降。
但任务复杂度一上去，涉及架构决策、跨模块边界判断、修复方向选择，模型的自洽性就不够了。不是模型不够努力，而是这些决策需要的信息不在当前上下文里：历史决策的 trade-off、团队的隐性约定、对业务语义的深层理解。这些在目前主流模型上仍很难稳定解决，只是 Claude 的容错空间更大。
所以更准确的描述不是"人在环内"还是"不在环内"，而是在哪个层级介入：简单执行层可以放手，复杂决策层需要人拍板。Harness 的角色，就是尽可能把这两层的边界用工程手段往外推，让更多任务从"需要人决策"降级为"模型可自主"。
问题最终落到一个点上：在哪个层级介入。
对做 Harness 的人来说，这意味着必须面对一个双重设计约束：既要在国外强模型上做得足够薄以保持效率，又要在国内模型上提供足够的厚度以保障质量。不能因为今天用的模型需要很厚的工程补偿，就把 Harness 固定成一个厚度；也不能因为国外模型已经很强，就假设工程层可以全部扔掉。
这也是为什么 Harness 更适合设计成模型无关的。 它的每一层都应该有明确的"退出条件"：当模型能力达标时，这层可以关闭或瘦身。可拆卸设计的每一层，都不应该假设"模型永远需要我"。
但"可拆卸"不是免费的。每一个"拆"或"不拆"的决策背后，都是成本在说话：用更贵的模型省工程投入，还是用工程投入省模型费用？在哪一层补位、用多大力度补，都是经济决策。要回答这些问题，得先把 AI 工程化的成本结构拆开看。
第三节：企业引入 AI 工程化的经济账
引入 AI 工程化，不是把人的工资换成 API 费用那么简单。真正要算的是六项成本，其中有两项在传统研发中不突出：知识显性化成本，以及人员学习与规模化成本。
总成本 = 模型调用成本 + 设计输入成本 + 知识显性化成本 + 质量返工成本 + 工具链建设维护成本 + 人员学习与规模化成本
关键区分：设计输入 vs 知识显性化
这两项最容易混淆，但它们有本质区别：
| 设计输入成本 | 知识显性化成本 | |
|---|---|---|
| 人不引入 AI 也要花吗？ | 要。PRD、原型、接口定义，不引入 AI 也得有 | 基本不要。 人脑子里有，自动就用了 |
| 具体是什么？ | 写清楚"系统要做什么、边界在哪、怎么验收" | 写清楚"按什么规矩做" |
| 举例 | 用户故事、原型、业务规则、接口边界、验收标准 | "分页用这个类""异常统一用 BusinessException""表名下划线字段驼峰" |
| 本质 | 业务需求的格式化 | 把人的隐性经验翻译成模型能消费的结构化知识 |
人对团队规范是肌肉记忆。"项目里用 MyBatis-Plus，分页参数是这个类，返回格式是这个"，对同一个团队的人来说几乎是零成本，因为他天天这么干。但模型不知道，不写清楚它就会用"互联网上的通用做法"。
这种翻译成本是专门为 AI 额外花的。它不是需求澄清，不是架构设计；它是因为模型没有"在这个团队里干了两年"的经验，而不得不做的知识搬运。
还有一项成本也容易被低估：人员学习与规模化成本。AI 编码效率高度依赖使用者对模型、上下文、工具链和验证方式的理解。同样一个模型，熟练的人能把任务拆好、上下文喂准、失败后快速定位；不熟的人可能反复试 prompt、把错误代码合进去，最后返工更多。
这意味着，个人层面的高效率不一定天然规模化。企业要把 AI 效率从少数熟练者扩展到大多数开发者，需要培训、规范、模板、最佳实践沉淀，也需要接受一段时间内的试错成本。换句话说，提高个人效率本身也会增加成本，只是这部分成本常常藏在学习曲线和团队磨合里。
六项成本的耦合关系
六项成本不是独立变量，而是拧在一起的。每个工程选择都在改变成本分布：
| 工程选择 | 直接增加 | 主要降低 | 成立前提 |
|---|---|---|---|
| 工具链做厚 | 工具链建设维护成本 | 模型调用成本、质量返工成本 | 规则能被机制化，且复用频率足够高 |
| 设计输入做深 | 设计输入成本 | 模型调用成本、质量返工成本 | 输入能减少歧义，而不是把需求文档写厚 |
| 知识显性化做深 | 知识显性化成本 | 质量返工成本、模型调用成本 | 写进去的是企业私有知识，不是模型本来就会的通用知识 |
| 使用更强模型 | 模型调用成本 | 知识显性化成本、质量返工成本 | 强模型确实能稳定吃下隐性约定和长上下文 |
| 知识封装复用 | 初次显性化成本 | 后续知识显性化成本 | 同类项目或同技术栈会反复使用 |
| 人员培训做深 | 人员学习与规模化成本 | 质量返工成本、工具链误用成本 | 培训内容能沉淀为规范和模板，而不是只停留在个人经验 |
不存在全局最优，只存在各阶段的最优平衡。Harness 的每一个设计选择，都应该能回答两个问题：它在降低哪一项成本？它又把成本转移到了哪里？
经济学价值
Harness 核心的经济学价值，是把知识显性化的一次性投入封装为可复用的知识资产。第一次花时间把"这个框架怎么用""异常怎么处理""命名规范是什么"写清楚，之后每次让模型干活时自动加载，后续使用的增量成本会显著下降。这不等于零成本：业务在变、框架在升级，知识包仍要维护和演进，只是不再每次都从零解释一遍。
这也解释了 Delta 原则的由来：只封装"外面没有的"企业独有知识。开源框架的用法模型本来就会，不需要花成本去显性化。只把真正需要翻译的那部分隐性经验写进去，让每一份投入都落在最需要的地方。
成本锚点
最后落到一个判断：Harness 不是和"纯手写代码"比，而是和企业当前真实可达到的研发方式比。
这个基准会因企业而异。一个团队如果还停留在传统开发方式，AI 工程化的收益很容易显现；如果大多数开发者已经熟练使用 Cursor、Claude Code、Copilot 这类工具，甚至已经形成个人层面的 vibe coding 工作流，那么 Harness 要比较的就不是"AI vs 人"，而是"系统化 AI 工程化 vs 分散的个人 AI 使用"。
所以更准确的等式是：
Harness 总成本 < 企业当前基线成本
这里的"企业当前基线成本"，不是抽象的纯人工成本，而是当前组织里大多数开发者在既有工具、AI 使用水平和协作习惯下完成同类 Feature 的真实成本：花多少时间写输入、试多少轮、返多少工、需要多少人审查、最后代码能不能稳定合入。
即便用最贵的模型，一个标准 Feature 的完整生成链路（分析 → 建模 → DDL → API 契约 → 后端代码 → 前端代码）的模型调用成本，通常也不是主要矛盾。真正决定经济账是否成立的，是 Harness 能不能在现有 AI 使用水平之上继续压低系统性成本：设计输入是否可复用，知识显性化是否沉淀，返工是否减少，质量是否更稳定，工具链维护是否可控，个人经验能否规模化成团队能力。
第四节：要做什么
不是做一个更好的 Prompt，也不是选一个更强的模型。是做一套系统化的研发基础设施。
六个设计目标：
- 管理上下文：不该进的不进，该进的尽量不漏。模型不需要的信息不喂给它，喂给它的信息尽量精确、结构化。
- 对抗衰减：用结构化的 Spec 而不是自然语言传递关键信息。不依赖模型从长文中"注意到"某条约束。
- 硬约束：用机制而不是自觉来保障规则执行。不靠模型"遵守"，靠 Hook 在代码落地前拦截。
- 自动验证：编译→静态分析→测试→架构校验→人工验收，五层验证闭环。失败了自动修复，最多两轮重试。
- 沉淀知识：企业专有知识封装为可复用的资产。一次投入，之后每次任务自动加载，后续增量成本显著下降，但仍要随业务和栈演进维护。
- 可移植：新项目 fork 后改几行配置就能用。路径不硬编码、模块名不写死。
这六个目标不是并列的愿望清单。它们之间有一条执行主线：前两个定义信息怎么流转，中间两个定义质量怎么保障，最后两个定义这套东西怎么复用和推广。接下来的文章就是沿着这条主线逐层展开。
下一篇会展开我这套实践的整体样貌：三层执行架构、从 PRD 到代码生成的实战历程，以及这套设计是如何尝试应对那六个模型原生能力缺口的。
参考资料
- Anthropic, Introducing Claude Opus 4.7；llm-stats, Claude Opus 4.7: Benchmarks, Pricing, Context & What's New。
- OpenAI API Docs, Using GPT-5.5；llm-stats, Terminal-Bench 2.0 Leaderboard。
- Moonshot AI, Kimi K2.6 技术博客。
- Anthropic, 2026 Agentic Coding Trends Report。
- OSWorld, Benchmark Project；llm-stats, OSWorld-Verified Leaderboard。
- Rakuten Today, Rakuten accelerates development with Claude Code。 ↩
