提示词和 Harness

Agent 犯了个错，你打开系统提示词，加一句“请不要……”，然后它下次换个方式又犯了。

差距不仅仅在模型里。同一个模型，换一套 Harness，ARC-AGI 成绩能从 30% 拉到 95% 以上。LangChain 的编码 Agent 只改 Harness 基础设施，不改模型，在 Terminal Bench 上从 30 名开外冲进前 5。

Harness 是模型之外、决定 Agent 怎么跑的全部工程结构。

工具怎么接、状态怎么存、错误怎么拦、什么情况下不允许继续，都算。

Prompt 工程问的是“怎么说”。Harness 工程问的是“怎么让它不可能做错”。它们有个共同点，就是如何高效的和大模型打交道，如何调教好大模型乖乖做事。

Anthropic 拆解 Managed Agents 时把 Harness 叫“大脑”（应该要结合大模型一起），把沙箱叫“手”，把会话日志独立存起来。容器挂了，会话不丢；凭据放在沙箱外面，生成的代码碰不到。这是结构上的保证，不是提示词里的请求。

比如，用 linter 替代请求

你在提示词里写“请通过 service 层访问数据库”，模型可能照做，也可能忘了。你在 CI 里加一条自定义 lint 规则，禁止在 src/handlers/ 下直接 import @/db，违反就构建失败，它就不可能通过。

SitePoint 有篇关于 Agent 代码库设计的文章讲得很直白：linter 的错误消息本身就是给 Agent 的指令。当 Agent 试图绕过架构直接查库时，报错说“请使用 @/services 下的 service 函数”，它立刻知道该怎么改，不需要翻 wiki，不需要回忆 Slack /飞书/钉钉/企微里的讨论。

这就是硬约束和软请求的区别。提示词是建议，CI 是物理定律。

所以

第一，把系统提示削薄。 只留 persona、scope、输出格式。详细的规则、流程、禁止事项，拆到持久化的模块化文件里，按需加载。系统提示越厚，模型越容易在中段丢指令。

第二，在 CI 里加门禁。 格式校验、schema 检查、自定义 lint 规则、测试。任何一项不过，PR 合不进去。Agent 可以随便生成，但过不了门的东西不存在。Anthropic 的长周期 Agent 实验里，把单元测试结果反馈给模型，任务解决率从 63% 提到 94%。反馈回路比自我批评有用得多。

第三，别让 Agent 自己判自己。 生成和评估分离。写代码的 Agent 和跑测试的 Agent 是两个东西，后者没有写权限，只看结果打分。Anthropic 的实践反复验证了一件事：模型对自己的平庸产出会过度称赞，外部检查器不会。

总之，每当你发现 Agent 犯了一个错，不要只改提示词。花时间设计一个方案，让这个错误在结构上不可能再发生。这是 Harness 工程的全部含义。模型会继续变好。但可靠性的责任，从来不在模型那边。