用 AI 写初稿、生代码、做方案，速度提升 5 到 10 倍。很多人据此判断：AI 已经能把事做完了。但真正交付的时候才发现——快的是前面，慢的是后面；省的是体力，费的是心智。从 0 到 90%（能跑通主流程）的效率爆炸和从 90% 到 100%（能上线扛住边界场景）的成本陡增之间，藏着一个吃掉所有收益的陷阱。

一个几乎所有 AI 项目都会掉进去的坑

用 CodeBuddy 搭了一套"文章编写 Agent Team"：scout 选题、architect 设计大纲、writer 写初稿、reviewer 审稿、polisher 润色终稿。五个角色各司其职，前三步跑得飞快——选题 2 分钟、大纲 3 分钟、初稿 8 分钟，加起来不到一刻钟就出了一篇 3000 字的技术文章。

然后问题开始暴露。reviewer 审稿时能看到 writer 的全部中间思考过程（五个角色共享同一个上下文窗口，上下文互相污染），审稿判断不独立；每个角色累积的输入输出撑满了上下文，越到后面的角色可用空间越少，polisher 润色时已经开始丢信息；prompt 里写的 send_message 互相传话——平台当时根本没提供这个 API，通信机制是虚构的。

初稿生成耗时 13 分钟。但 reviewer 退回修改 → writer 重写 → 再审 → 再改的循环跑了 3 轮，累计 token 消耗达到初稿的 4 倍以上，总耗时反而超过人工直接写。前面省下的 13 分钟，后面用 50 多分钟补回去了。

这不是个别现象，而是一条规律：

0 → 90%，靠大模型的泛化能力，很快就能跑通。90% → 100%，拼的是确定性、鲁棒性、边界控制和异常处理，难度指数级上升。

0 → 90% 为什么这么容易

第一，大模型的拟合能力极强。 只要给少量示例或提示词，就能覆盖大部分常规场景。写代码、做翻译、画流程、查资料、生成报告——这些任务的主路径，模型都能直接通过。

第二，工具链基本可用。 RAG、函数调用、代码执行、搜索引擎、MCP 工具链一搭，基础流程直接能跑。搭一条 Agent 研发流水线，从需求到代码，两天就能出 Demo。

第三，早期用户的容忍度高。 刚开始用 AI 的时候，大家看的是"能不能做"，不是"会不会错"。输出有瑕疵没关系，能跑就行。这个阶段，AI 看起来像神。

90% → 100% 为什么是工程地狱

90% 覆盖的是常规路径。剩下的 10% 是各种奇葩输入、歧义、格式错误、逻辑漏洞和边界场景。在真实系统里，10% 的异常足以导致 100% 不可用——用户不会因为"大部分情况都对"就信任一个偶尔出错的系统。

确定性缺失

同样的输入，输出可能飘。多轮对话后记忆错乱。规则和规则之间互相冲突。Agent 今天跑得好好的，明天换了个上下文就开始胡说。

这不是 bug，是大模型的本质特征——它是概率模型，不是确定性引擎。没有办法通过"写更好的 prompt"来彻底消除这种不确定性。

长尾异常

用户会输入各种想象不到的东西。半角全角混在一起、一个字段里塞了三种格式、一个请求里同时触发两条互斥规则。常规测试覆盖不到这些场景，AI 遇到了就会"创造性地"给一个看起来合理但完全错误的输出。

对齐成本爆炸

一个真实数字：在可观测性体系下跟踪一次 Agent 任务的执行，一次完整任务触发了 8 次 LLM 调用、消耗 12,340 token——这还只是"正常跑通"的情况。一旦触发反馈回路（reviewer 退回、重试、再审），每多一轮循环就再加一倍调用量。前面提到的文章写作 Team，初稿生成消耗约 3,000 token，但三轮退回修改累计消耗超过 12,000 token——修正偏差的成本是生成初稿的 4 倍。

据 Anthropic 官方数据，Managed Agents 相比标准提示循环，任务成功率提高多达 10 个百分点。这 10 个百分点的差距不是模型变聪明了，而是基础设施层面的失败被消除了（会话断连恢复、沙箱兜底、长任务持久化）。换个角度看：标准循环里有 10 个百分点的失败率来自环境因素，和模型能力无关——这就是 90% → 100% 的工程成本的一个侧面。

把这些数据抽象成量级关系：

区间	投入倍数	实际体感
0 → 90%	×1	初稿生成、主流程跑通
90% → 99%	×10	加反馈回路、加约束、加重试——每修一个偏差都是多轮调用
99% → 99.9%	×100	长尾场景逐个兜底、人工审核收口、全链路可观测

这不是精确测量——不同领域、不同项目差异很大——但在多个实际项目中反复被验证的趋势是：可靠性每往上提一个数量级，投入大约上升一个数量级。后面那 10% 的工作量，远超前面 90% 的总和。

信任与责任鸿沟

90% 的可靠性可以做 Demo。100% 的可靠性才敢说"交给它不会出事故"。在企业级、金融、法律、医疗场景里，这道鸿沟几乎是天堑。没人愿意为一个"大部分情况都对"的系统背责任。更现实的问题是：AI 生成的合同条款出了纰漏，谁来赔？Agent 自动审批的流程出了差错，算谁的决策失误？责任链一旦模糊，系统能跑和系统敢用就成了两回事。

为什么说这是"陷阱"而不只是"难"

效率陷阱的完整形态是这样的——难，是知道前面有坎要过；陷阱，是以为坎已经过了，其实还没开始：

先是 0 → 90% 带来极强的效率幻觉。写初稿、做方案、生成代码，速度提升好几倍，人很容易据此判断——AI 已经能把事做完了。

然后 90% → 100% 开始暴露可靠性黑洞。格式不对、逻辑漏边界、上下文乱、重复矛盾、幻觉频出。每一个小问题都要人去校验、修正、兜底、重跑。修正、调试、返工叠在一起，经常就超过原来人工直接做的时间（前面的文章写作 Team 案例里，reviewer 退回 3 轮、累计 token 消耗达到初稿的 4 倍以上，总耗时反而超过人工直接写）。

最终整体 ROI 被吃掉。单看"生成"环节，效率爆炸。看端到端交付，快的是前面，慢的是后面。

组织层面的隐蔽陷阱

还有一层更隐蔽的陷阱在组织层面：管理层看到 0 → 90% 的效率提升，以为可以大幅提人效。一线发现 90% → 100% 巨难，不敢说，只能硬扛。最终：指标好看，实际更累。

问题摆出来了，接下来是：有没有一种系统化的方式，能把 90% → 100% 的成本压下来？

直觉上的三条路，为什么都不够

面对 90% → 100% 的可靠性缺口，最自然的反应是三种：写更好的 prompt、换更强的模型、加更多测试。但这三条路各有结构性天花板。

更好的 prompt → 不确定性是概率模型的本质。 前面已经说过——大模型不是确定性引擎，它是概率模型。无论 prompt 写得多精确、few-shot 示例给得多齐全，同一输入在不同上下文下仍然可能产生不同输出。prompt engineering 能提高平均质量，但无法消除概率性波动。把可靠性寄托在"把 prompt 调到完美"上，等于用沙袋堵概率的洪水——每堵住一个漏点，旁边又冒出两个。

更强的模型 → 能力提升但可靠性没有根本变化。 据 Anthropic 官方数据，同一个模型在标准提示循环和 Managed Agents 环境下，任务成功率差距可达 10 个百分点——而这个差距来自基础设施层面的失败被消除（会话断连恢复、工具执行沙箱兜底、长任务持久化保障），不是模型推理能力变强了。换句话说，模型升级解决的是"能不能做到"的问题，不是"做到后能不能稳定复现"的问题。GPT-4 照样幻觉，Claude 照样偶尔跑偏——更强的模型把天花板抬高了，但地板没有跟着抬。

更多测试 → 长尾场景写不完。 用户会输入各种想象不到的东西——半角全角混合、一个字段塞三种格式、一个请求同时触发两条互斥规则。长尾是无穷的，测试用例是有限的。靠穷举覆盖所有异常，和靠人工审核每一条 Agent 输出一样，都是不可持续的。

这三条路的共同点是：都在试图让模型本身更靠谱。但如果不确定性是概率模型的结构性特征，那解法就不能只在模型内部找——得在模型外面建工程体系来兜住它。

Harness Engineering 在解决什么

Harness Engineering 切入的正是这个位置。它不优化模型本身，而是优化模型运行的环境——让 AI 从"高效率的不稳定生成器"变成一个能复用、能上线、出了问题有人兜得住的自动化单元。

具体怎么对应：

90% → 100% 的障碍	Harness 怎么解	具体动作示例
确定性缺失	约束机制——状态机、权限门禁、工具白名单做硬卡控，不满足约束就不让进入下一阶段	token 预算 > 20,000 时自动截断上下文
长尾异常	沙箱隔离——执行环境与真实环境物理隔离，Agent 行为异常也只影响沙箱内部	Agent 只能写 /tmp 下的文件，不能碰生产目录
上下文乱 / 记忆错乱	上下文管理——按需检索、结构化交接、超阈值重置，让 Agent 在正确时间看到正确信息	每个角色只接收前一角色的输出摘要，不看中间过程
自我评估不可信	反馈回路——编排层自动跑测试、lint、端到端验证，不过就打回，超重试次数升级人工	reviewer 退回 > 3 次自动升级人工介入
出了问题找不到原因	可观测性——每次调用、执行、阶段跳转都有迹可查，顺着 trace 即可定位	一次任务 8 次 LLM 调用、12,340 token 全部可追溯

这五个要素不是让 AI 更聪明，而是让 AI 更可控。它们组合在一起，说到底做的是一件事：把 90% → 100% 的非线性成本曲线，通过工程化手段压平一些。

行动指南：判断该投入多少工程量

不是所有场景都需要跨过 90% → 100% 这道悬崖。内部原型、一次性脚本、探索性分析——这些场景 90% 就够了，硬要堆到 99.9% 反而是浪费。关键是先判断具体场景需要几个 9 的可靠性，再决定投入多少工程量。

三个维度做决策：

• 出错后果有多严重？ 内部工具出错重跑就行，线上金融系统出错可能是事故。
• 使用频次有多高？ 跑一次的脚本和每天跑一万次的服务，容错要求天差地别。
• 有没有人在旁边兜底？ 有人盯着可以容忍偶尔翻车，无人值守必须高可靠。

判断自己在哪个阶段很简单：如果不敢不盯着 AI 跑，那就还在 90% 以内。 只有当 AI 能在无人值守的情况下持续产出可靠结果，才算真正跨过了那道坎。

Harness Engineering 不是银弹，不会让这道坎消失。但对于需要持续运行、对可靠性有要求的系统，它提供了一套系统化的方法：约束管住行为、反馈回路保证质量、可观测性让问题可追溯——一层一层加上去，每加一层，就能更放心地少盯一点。

从能用到可用，中间隔着一道工程鸿沟；可用到可靠之间还有一座山，而大多数人在第一道沟前面就停了。认清这个成本结构，才能不掉进效率陷阱里。前面 90% 的速度感是真的，后面 10% 的工程量也是真的——快的部分不能省掉慢的部分，这才是 AI 工程化最该记住的一句话。

---

本文由本人构思并把控，借助 AI 辅助整理成文，仅代表个人观点，欢迎交流。