聊聊现在大火的“Harness Engineering”

AI工程的三次认知升级

当你花了三天打磨一份系统提示词。格式清晰，角色定义明确，边界案例全覆盖。在测试环境里，Agent 表现稳定，几乎挑不出毛病。

上线第一天，它开始循环调用同一个工具。第三天，遇到一个从未出现过的错误，它的处理方式一塌糊涂。你修提示词，重新测试，下周它又换了个新姿势出错。

这个循环，你熟悉吗？这不是模型的问题，也不是你提示词写得不好。

2022 年你在优化提示词，2025 年你在管上下文，2026 年你该认识 Harness Engineering 了。这不是新框架，是一次思维方式的升级------从把话说好 到把环境建好。而作为测试工程师，可能是最早该读懂它的那批人。

阶段	核心思路	典型做法与局限
2022-2023 Prompt Engineering	把话说清楚。用更好的指令让模型输出更好的结果。	Few-shot 示例、Chain-of-Thought、角色扮演。单次对话有效，但任意任务变长就失控。
2024-2025 Context Engineering	管好上下文窗口。决定模型每一步"看到什么"。	RAG 检索、对话压缩、动态注入。跨越多轮对话有效，但无法处理会话的状态。
2026~ Harness Engineering	把环境建好。设计 Agent 运行的全部基础设施：约束、反馈循环、质量门控。	工具执行、记忆持久化、错误恢复、状态管理、人工审批门。这才是让 Agent 真正可靠的层。

注意到了吗？这三层是 叠加关系 ，不是替代关系。就像你不会因为学了集成测试就扔掉单元测试一样，Harness Engineering 是在前两层之上又加了一层「生产级防护」。

缺了这一层，Agent 在 demo 里天衣无缝，上了生产就漏洞百出。这不是玄学，是工程结构问题。

没有 Harness 的 Agent 是在裸奔，有 Harness 的 Agent 才能真正干活。

没有 Harness 时，一个 Agent 项目的典型死法：

一个生产级的 Agent Harness，通常由以下五个核心层构成。

管理 Agent 能调用哪些工具、怎么调用、出错了怎么处理。不是「什么都给」，而是「精准授权」------工具越少，Agent 越可靠。

LLM 本身是无状态的，每次调用都是「失忆重来」。Harness 负责在会话之间、任务之间维护状态，让 Agent 记得「上一步做了什么」

长任务中，上下文窗口会被大量工具输出「污染」，导致模型注意力退化。Harness 负责动态压缩、注入、隔离，保持 Context 的信噪比。

不是所有动作都应该让 Agent 自主执行。删库、大批量写入、发送外部请求------这些高风险操作需要人工审批门，而不是依赖提示词里的「请三思」。

你不能改善你看不见的东西。Harness 应该追踪每一次工具调用、每一步推理、每一次失败，让你能够真正调试 Agent，而不是瞎猜。

好的软件工程一直要求的东西：质量门控、错误恢复、环境隔离、状态管理，恰恰就是生产级 Harness 的组成部分。测试工程师天天在做这件事。

只不过过去你做的对象是代码，现在你做的对象是 Agent 的行为。底层逻辑，完全相通。