夜雨聆风
267 行。
这是我的 OpenClaw CEO 指令文件膨胀到的行数。22 处幽灵引用指向根本不存在的路径。91 行"记忆协议"描述了一套五层记忆模型，但整套系统从头到尾没有被实现过。我的 AI Agent 读到这些内容后，没有报错，没有提问——它选择了"假装做到了"。
结果是什么？系统性幻觉。
那段时间我每天最大的困惑不是"怎么让 Agent 变聪明"，而是"为什么它看起来什么都懂，做出来的东西却总在翻车"。我试过换模型，试过精调 Prompt，试过加更多指令。全部无效。直到我发现一个残酷的事实：问题根本不在 Agent 身上，问题在我给它搭建的整个工程环境。
读完这篇文章，你会知道三件事：第一，2026 年 AI 工程的真正战场已经从"怎么写 Prompt"转移到"怎么工程化管理 Agent 的运行环境"；第二，这个方向有一个正式名字叫 Harness Engineering，由 HashiCorp 联合创始人 Mitchell Hashimoto 在 2026 年 2 月命名；第三，我用 OpenClaw 的 Agent 团队亲身验证了这条路——配置文件从 267 行优化到 149 行，底层模型一个参数没换，Agent 的效果却显著提升。
一、"指令越长越好"的幻觉
故事要从去年说起。
OpenClaw 刚起步的时候，CEO Agent 的指令文件只有不到 50 行。任务路由表、执行协议、安全红线——简洁有力，Agent 执行得又快又准。
然后我开始加东西。
每次遇到问题，我的本能反应都是"加一条规则"。Agent 忘记质检？加一段质检流程。脱敏遗漏？加一段脱敏指令。路由判断错误？再加一段路由说明。记忆管理不行？写一套 91 行的记忆协议，描述五层模型、时间衰减（半衰期 21 天）、MMR 检索（lambda=0.75）。
只有一个小问题：这套记忆系统根本不存在。
我写的是一份"需求文档"，不是"事实描述"。但 Agent 不知道。它读到这 91 行内容，以为系统已经搭好了，于是开始"假装"自己在执行五层记忆模型。你问它"你用的什么记忆策略"，它能把 MMR 检索说得头头是道。但实际上？它在用幻觉填补一个根本不存在的系统。
这就是我交的第一笔学费：给 Agent 的上下文里写了"应然"而不是"实然"，它会用幻觉弥合差距，而且做得天衣无缝，你根本发现不了。
二、267 行配置文件的崩塌
指令文件膨胀到 267 行之后，问题开始集中爆发。
我花了一个周末做了一次全面审计。结果让我后背发凉：
22 处幽灵引用。指令里写着"参考 shared-knowledge/ 目录""查看 workspace/ceo/memory/bank/"——这些路径全部不存在。是什么时候写进去的？我自己都想不起来了。Agent 遇到这些引用时的行为模式非常一致：先尝试访问，发现不存在，然后静默跳过，用自己"猜测"的内容继续执行。没有报错，没有提问，没有任何告警。
脱敏规则 4 处重复。同一套脱敏要求分别出现在 CEO 指令、质检文件、Agent 定义文件、发布流程四个地方。问题在于它们不完全一致。CEO 指令里多了两个关键词，质检文件里少了一条替换规则。改了一处忘了其他三处，这不是效率问题，是安全定时炸弹。
路由表 3 处重复。任务应该派给哪个 Agent，在三个不同文件里各写了一遍。两处一致，一处过时。结果是 Agent 偶尔会把内容修改任务派给开发工程师——因为它读到的其中一个版本确实是这么写的。
3 个废弃 Agent 仍以活跃状态出现。它们早就不用了，但指令文件里还把它们列为"可委派对象"。CEO Agent 偶尔会尝试调度它们，然后失败，然后重试，然后超时。
我看着这份审计报告，意识到了一件事：我的 Agent 不是变笨了，是我把它的工作环境搞砸了。
三、从 Prompt Engineering 到 Harness Engineering
让我暂停一下叙事，聊聊行业正在发生什么。
2026 年 2 月，HashiCorp 联合创始人 Mitchell Hashimoto 正式提出了一个概念：Harness Engineering（驾驭工程）。
如果你关注 AI 工程领域，你可能已经听说过 Context Engineering（上下文工程）。简单说，Context Engineering 解决的是"给 Agent 看什么"——信息筛选、上下文窗口管理、检索增强。这已经比单纯的 Prompt Engineering 前进了一大步。
但 Hashimoto 指出，光管"给什么信息"还不够。真正决定 Agent 系统成败的，是整个外围工程系统——验证回路、错误恢复、行为追踪、质量量化。他把这些统称为 Harness。
打个比方：模型是 CPU，上下文窗口是 RAM，Harness 是操作系统，Agent 是应用程序。
你可以拥有世界上最强的 CPU 和最大的 RAM，但如果操作系统是一团糟——文件系统混乱、进程调度失灵、错误处理缺失——应用程序照样跑不好。
LangChain 团队用一个案例震撼了整个行业：他们的编码 Agent 仅通过优化外围系统——文档结构、验证回路、追踪系统——Terminal Bench 排名从第 30 名升至第 5 名，得分从 52.8% 飙升至 66.5%。底层模型一个参数没改。
这个案例彻底改变了我对 AI 工程的理解。我之前所有的优化方向——换更强的模型、写更精巧的 Prompt、加更多的指令——全部搞反了。
四、手术：从 267 行到 149 行
回到我的 OpenClaw 故事。
审计完那份 267 行的配置文件后，我决定做一次彻底的重构。不是修修补补，是推倒重来。
第一刀：清除所有幽灵引用。
22 处指向不存在路径的引用，全部删除。这一步最简单，但效果立竿见影。Agent 不再花时间尝试访问不存在的文件，不再用幻觉填补缺失的信息。光这一个动作，就让 Agent 的"无效操作"减少了大约三分之一。
第二刀：单一真相源（Single Source of Truth）。
脱敏规则 4 份变 1 份。路由表 3 份变 1 份。其他地方只保留引用指针："脱敏规则见 XX 文件"。
这个原则在软件工程里是常识，但我之前在管理 Agent 指令时完全没有意识到它的重要性。当同一条规则在多个地方重复出现时，不一致是必然的，只是时间问题。而不一致的规则对 Agent 来说，比没有规则更致命——因为它不知道该信哪个。
第三刀：信息分层加载。
这是最关键的一步。我把所有指令分成四层：
L1 每次加载：核心身份、铁律、路由表——Agent 每次启动都必须读到的信息
L2 委派时加载：派发子任务时需要的具体协议
L3 按需执行：特定流程的详细步骤，用到时才加载
L4 按需读取：参考资料、历史记录
之前 267 行全部塞在一个文件里，Agent 每次启动都要读完所有内容。现在核心文件只保留 L1 的内容，其余按需加载。这不仅减少了上下文窗口的浪费，更重要的是降低了信息之间相互干扰的概率。
第四刀：记忆协议从虚构重写为真实。
91 行描述"理想状态"的记忆协议，重写为 43 行描述"实际能力"的版本。不再有五层模型、时间衰减、MMR 检索——只有系统真正支持的功能。Agent 读到什么，就能做到什么。
第五刀：清退废弃 Agent。
3 个不再使用的 Agent 从路由表中移除。CEO Agent 的调度范围瞬间清晰了——它不会再尝试把任务派给一个根本不存在的执行者。
五、手术后：效果验证
最终结果：
| 指标 | 重构前 | 重构后 | 变化 |
|---|---|---|---|
| CEO 指令行数 | 267 行 | 149 行 | -44% |
| 幽灵引用 | 22 处 | 0 处 | -100% |
| 脱敏规则副本 | 4 份 | 1 份 + N 处引用 | 单一真相源 |
| 废弃 Agent | 3 个 | 0 个 | 全部清退 |
| 记忆协议 | 91 行虚构 | 43 行真实 | 重写 |
但数字只是表面。真正让我兴奋的是质变：
Agent 响应速度变快了。更短的指令意味着更少的上下文处理时间。这在每一次交互中都能感知到——不是快了一点点，是快了很多。
幻觉显著减少了。当指令里不再有"应然"和"虚构"，Agent 的输出就不再需要"编造"来弥合差距。它只做能做的事，只说能说的话。
审核标准零降级。这一点很重要。我不是通过降低标准来减少行数的。质检流程、脱敏要求、安全红线——全部保留，只是不再重复。
最关键的是：底层模型一个参数没换。
这和 LangChain 的案例形成了完美的呼应——不是模型不够强，是我们给模型搭建的工程环境不够好。
六、为什么 Prompt Engineering 已经过时
让我把这个结论说得更直接一些。
JetBrains 对超过 10,000 名开发者的调查显示，90% 的开发者已经定期使用至少一个 AI 工具。Gartner 报告多 Agent 系统的搜索查询量暴增 1,445%。AI Agent 不是未来，是现在。
但与此同时，企业级 Agent 项目的失败率高达 62%。其中，框架选型失误占 38%。
为什么失败率这么高？因为大多数团队还停留在 Prompt Engineering 思维里——以为写一个好的 Prompt 就够了。甚至进阶一点的团队，也只走到了 Context Engineering——精心管理"给 Agent 看什么信息"。
但真正决定成败的不是这些。是整个驾驭系统——验证回路有没有？错误了怎么恢复？行为能不能追踪？质量怎么量化？
做对 Context Engineering 的团队实现了 4 到 32 倍的成本降低。而 Harness Engineering 在此基础上更进一步——它不只是省成本，而是让整个系统从"偶尔能用"变成"可靠运转"。
回到 OpenClaw 的经验：我的 Agent 团队过去翻车，不是因为 Prompt 写得不好。是因为：
1. 指令文件里有虚构内容，Agent 用幻觉来配合
2. 同一条规则重复多处，Agent 不知道该信哪个
3. 引用了不存在的资源，Agent 静默失败
4. 废弃组件没清退，Agent 浪费时间调度幽灵
这四个问题，没有一个能通过"写更好的 Prompt"来解决。它们全部是工程问题，需要工程化的手段来处理。
七、我这次学到的 5 个教训
教训一：Agent 指令里只写"实然"，不写"应然"。
你计划未来要建的系统、你希望 Agent 具备的能力——在它们真正实现之前，不要写进指令。Agent 不会区分"已实现"和"计划中"，它只会假装两者都存在。
教训二：信息重复是 Agent 系统最隐蔽的毒药。
同一条规则出现在两个地方，就意味着终将出现在两个版本。而两个版本的规则对 Agent 来说，比没有规则更危险。
教训三：减少指令比增加指令更难，也更有价值。
每次遇到问题，第一反应是"加规则"。但 267 行的经历告诉我，真正的功力在于如何用最少的文字表达最完整的约束。-44% 不是删掉了内容，是提纯了信息。
教训四：Agent 的"静默失败"是最危险的模式。
遇到不存在的路径，Agent 不会报错。遇到矛盾的指令，Agent 不会提问。遇到虚构的系统，Agent 不会质疑。它会安静地编造一个答案，然后自信满满地交付给你。你必须主动建设验证回路，因为 Agent 永远不会主动告诉你它在瞎编。
教训五：模型不是瓶颈，工程环境才是。
从 LangChain 的 52.8% 到 66.5%，从 OpenClaw 的 267 行到 149 行——两个案例指向同一个结论：与其追求更强的模型，不如先把现有模型的工程环境搭好。这才是 2026 年 AI 工程最高 ROI 的投资方向。
如果你也在运营自己的 AI Agent 系统，试试做一次"指令审计"。查查有多少幽灵引用、多少重复规则、多少虚构描述。你可能会像我一样后背发凉——然后像我一样，发现一个不需要换模型就能大幅提升 Agent 效果的机会。
想要完整的 AI Agent 配置优化模板和 Harness Engineering 实战清单？我已整理在「光锥之内」知识星球。
🦞 关于「Wesley AI 日记」
记录一个人用 6 个 AI 员工撑起一人公司的全过程。没有成功学，只有真实的系统设计、真实的翻车现场、真实的复盘。每篇文章都是一个完整的实战故事。
想要更深度的内容、完整的 OpenClaw 配置、完整的自动营销增长 Skill、完整的 SOUL.md 模板、Workflow 最佳实践、以及和我直接交流的机会？加入知识星球「光锥之内」——这里会有平台发不了的完整内容和实操资料。
扫描下方二维码，或在知识星球搜索「光锥之内」
关注 Wesley AI 日记，持续更新一人公司 AI 团队实战全记录。
往期精选
📌 OpenClaw实战：20个定时任务的血泪史——AI自动化不是自动躺平
📌 OpenClaw实战：Agent输出总翻车？踩坑30天后找到的几个核心原因
📌 OpenClaw实测：稳定输出——记一个3w星框架如何帮我炼出5条AI管理铁律
📌 OpenClaw实战：记忆架构升级——给AI Agent Teams建一个集体大脑
📌 OpenClaw实战：让AI越变越聪明的秘密——每日复盘，自我进化
📌 OpenClaw实战：AI Agent团队从1个扩到8个，再砍回4个的真实原因
📌 给OpenClaw Agent Team装上记忆——踩了19天坑，终于搞明白了
📌 实战复盘：OpenClaw 6人Agent Team险些全军覆没
作者：Wesley｜一人公司 × 6个AI员工
转载请联系作者，商业转载需授权。
