Harness驾驭工程：从提示词到操作系统，如何让AI Agent更可靠高效？

OpenClaw 将 AI 主权从模型厂商转移到了用户手中，但调教 AI 并非易事，甚至令人烦躁。这一背景加速了 Harness 驾驭工程的市场共识。

Harness 一词来源于马具。马是强大的 AI 模型，因其黑盒属性而难以捉摸；Harness 是缰绳、马鞍和护具等驾驭系统，代表着工程管理学；骑手则是人类工程师，负责明确意图、设计环境并构建反馈回路。

01 你的客厅里来了一条龙

2026 年 2 月，OpenAI 发布了一篇名为《Harness Engineering: Leveraging Codex in an Agent-First World》的技术博客。文章披露了一个惊人的实验：一个仅由 3 名工程师（后扩展到 7 人）组成的团队，在 5 个月内用 Codex Agent 生成了超过 100 万行生产级代码，合并了约 1500 个 Pull Request，没有一行代码是人类手写的。

但这篇文章真正引爆行业讨论的，并非“AI 写了 100 万行代码”这个数字本身，而是它提出的一个全新工程范式：Harness Engineering（驾驭工程）。

正如一篇广为流传的文章所比喻的：我们的客厅里来了一条龙。它聪明、强大，目前看起来还算温顺。但龙会长大，我们需要的不是更粗的铁链，而是一套完整的驾驭系统，以及一个懂得如何与龙共处的骑手。

02 工程演进：提示词、上下文、驾驭

为了更深刻地理解 Harness Engineering，让我们把视野拉长到更宏大的技术史尺度上：

▍ 工业革命：驾驭物理力量
蒸汽机释放了远超人类肌肉的物理力量。但蒸汽机本身不知道该驱动什么、转多快、何时停。于是，人类发明了飞轮调速器、安全阀、传动系统等，这些就是工业革命时代的“Harness”。没有这些，蒸汽机只是一个危险的热水壶。

▍ 信息革命：驾驭计算力量
计算机释放了远超人类大脑的计算力量。但裸机不知道该算什么。于是，人类发明了操作系统、编程语言、软件工程方法论，从瀑布模型到敏捷开发，每一步都是在构建更好的“Harness”来驾驭算力。

▍ AI 革命：驾驭认知力量
大语言模型释放了远超人类个体的认知力量，它能自主规划、推理和生成。但模型本身不知道该解决什么问题、遵循什么约束。Harness Engineering 就是 AI 时代的操作系统和软件工程方法论的统一体，包括 Agent 范式下的记忆、系统提示词、知识库、编排，以及 OpenClaw 范式下的文本流（如 Agent.md、Soul.md），都是为了更好地与模型对话。

Harness Engineering 的出现，是 AI 驾驭系统开始成形的信号。但提到驾驭工程，我们不得不回顾下它的前身：提示词工程和上下文工程。

▍ 提示词工程 Prompt Engineering

• 核心问题：怎么跟模型说话？
• 人类角色：用户精心雕琢每一句指令的措辞、格式、示例，试图从黑盒中诱导出正确答案。Few-shot、Chain-of-Thought、角色扮演……本质上是在一个固定的对话窗口里做文章。
• 局限：单次交互、无状态、高度依赖个人经验，更像是大师手艺，而非工程。

▍ 上下文工程 Context Engineering

• 核心问题：模型应该看到什么？
• 人类角色：角色从用户转化为 AI Agent Builder。Builder 们系统性地设计、构建并维护一个动态系统，在 Agent 执行任务的每一步为其提供恰当的上下文（知识库、工具调用、记忆管理）。关注点从“用户说什么”转向“让模型看到什么”。
• 2025 年 6 月，Andrej Karpathy 明确表态：上下文工程比提示工程重要得多。

▍ 驾驭工程 Harness Engineering

• 核心问题：整个环境应该如何运作？
• 人类角色：角色再次交还到用户手里。通过设计完整的运行环境，包括约束、反馈回路、自动验证、熵管理、生命周期治理等。
• 个人见解：驾驭工程能在这个阶段引发共鸣，与 OpenClaw 的出现紧密相关。它促使 AI 主权从模型厂商转移到用户侧。权责对等，拥有了调试 Agent 的权利，也需要学会 Harness，懂得如何与 Agent 共处。

图源：瑶池数据库举办的虾搞数据库杭州站

03 4个案例进一步了解 Harness Engineering

读到这里，你可能会怀疑：Harness Engineering 是不是只是把好的软件工程实践重新包装了一下？写好文档、做好反馈、跑好 CI，这些事我们不是一直在做吗？

这个怀疑值得认真对待。我们先来看 4 个真实案例，它们揭示了传统工程与驾驭工程之间的根本差异。

▍ 案例一：一个编辑工具的改变，让 15 个模型同时变强
来源：Can Duruk, “I Improved 15 LLMs at Coding in One Afternoon”, 2026.02

独立开发者 Can Duruk 维护着一个开源编码 Agent 框架。他发现一个被忽视的核心问题：Agent 修改代码文件的编辑工具本身就是一个巨大的失败源。

当前主流的编辑方式有三种，各有严重缺陷：

1. OpenAI 的 apply_patch：要求模型生成特定格式的 diff。
2. Claude Code 的 str_replace：要求模型精确复现旧文本的每一个字符。
3. Cursor 训练的专用 70B 合并模型。
   例如，Grok 4 使用 patch 格式的失败率高达 50.7%。

他设计了一种叫 Hashline 的新方案：当模型读取文件时，每一行都附带一个 2-3 字符的内容哈希标签。模型编辑时只需引用这些标签，而非复现原始文本。

// 模型看到的文件：
11:a3| function hello() {
22:f1|   return "world";
33:0e| }
// 模型的编辑指令：
"replace line 2:f1 with: return 'universe';"

结果：在16个模型、180个任务的测试中，Hashline 在几乎所有模型上都匹配或超越了传统方案。最极端的案例是 Grok Code Fast 1，成功率从 6.7% 飙升至 68.3%，提升十倍！Grok 4 Fast 的输出 token 也下降了 61%。

传统软件工程中，人类用 VS Code 还是 Vim，不影响代码质量。但在 Agent 世界里，模型表达意图的接口设计直接决定了它能否把正确的想法变成正确的代码。Can Duruk 的原话是：“你在怪飞行员，但问题出在起落架上。”

▍ 案例二：技术债的指数级放大效应
来源：AgentsMesh 开发者，“52 Days, 350K Lines Solo”, Reddit r/ClaudeAI, 2026.03

一位开发者在 52 天内用 AI Agent 独自构建了 35 万行代码。他发现了一个传统开发中不存在的现象：技术债会被 Agent 指数级放大。

当你做了一个临时妥协（如绕过 Service 层直接查数据库），Agent 会把这个模式当作“先例”。下次生成类似功能时，就会系统性地复用。人类工程师遇到烂代码知道“绕着走”，Agent 则不会，它看到代码库中存在某个模式，就把它当作合法方案。

当好的实践占主导时，Agent 放大好的实践；当捷径占主导时，Agent 放大捷径。

在传统团队中，技术债是线性累积的。但在 Agent 协作开发中，技术债变成了自我复制的病毒：一个坏模式可以在几小时内被 Agent 复制到代码库的每一个角落。这就要求一种全新的“代码库卫生”策略。

OpenAI 的实践是：将“品味”编码为自动化规则，并定期运行清理 Agent 扫描偏差、发起重构 PR。大多数可自动合并，功能类似于垃圾回收。

• 品味示例：
  • 更倾向于使用共享的实用程序包，而非手工编写的辅助工具。
  • 会验证边界，不基于猜测的结构进行构建。
  • 定期运行后台任务进行质量扫描和重构。

技术债务就像高息贷款：不断小额偿还，远比让债务累积后再一次性痛苦解决要好得多。人类的品味一旦被捕捉为规则，就会持续应用于每一行新代码。

▍ 案例三：子 Agent 作为“上下文防火墙”
来源：HumanLayer, “Skill Issue: Harness Engineering for Coding Agents”, 2026.03

HumanLayer 团队在大量企业项目中发现：Agent 的上下文窗口会随着工作推进而“腐烂”。每一次工具调用、文件读取都会留下残留。当上下文膨胀到一定程度，Agent 就进入了“笨蛋区”，简单任务也开始出错。

研究提供了实证：18 个模型在 Terminal Bench 2.0 上的表现随上下文长度增加而显著下降，当存在低相关性干扰信息时，退化更加陡峭。

HumanLayer 的解决方案不是“加大上下文窗口”，而是引入子 Agent 作为“上下文防火墙”：

• 父 Agent：负责规划和编排，使用昂贵的高推理模型（如 Claude Opus）。
• 子 Agent：在隔离的上下文窗口中执行具体任务，使用便宜的快速模型（如 Claude Sonnet）。
• 信息压缩：子 Agent 只返回高度压缩的结果 + 源引用，中间过程不污染父 Agent 的上下文。
• 效果：父 Agent 始终保持在“聪明区”，可以跨越数十个子任务维持连贯性。

阿里开源的 HiClaw 项目采用的 Manager-Workers 架构，也可视为一种“上下文防火墙”。传统软件工程中，上下文管理是人类大脑自动完成的。但 LLM 的上下文窗口是有限且会退化的资源。子 Agent 防火墙模式解决的是一个非人类认知体独有的问题：如何在有限的注意力预算内，完成需要无限注意力的工作。

▍ 案例四：反馈回路的重新设计
来源：HumanLayer 实践 + LangChain “Improving Deep Agents”

HumanLayer 团队早期犯了一个错：每次 Agent 修改代码后，都运行完整的测试套件。结果 4000 行通过的测试输出涌入上下文，Agent 开始对测试文件产生幻觉，丢失任务追踪。

他们总结出反直觉原则：“成功应该是沉默的，只有失败才应该发出声音。”

他们为 Claude Code 编写 Hook 脚本：修改后自动运行格式化和类型检查。如果通过，完全静默；如果失败，则只输出错误信息，并用退出码触发修复。

LangChain 的实践更进一步：

• PreCompletionChecklistMiddleware：在 Agent 试图交卷时拦截，强制其对照任务规格做验证。
• LoopDetectionMiddleware：追踪对同一文件的重复编辑次数，在 N 次后注入提示，帮助 Agent 跳出死循环。

结果是，LangChain 的编码代理在 Terminal Bench 2.0 中从前 30 名跃升至前 5 名。

传统 CI/CD 的反馈回路是为人类设计的：测试报告越详细越好。但 Agent 的反馈回路需要对上下文窗口友好：成功信号要压缩到零，失败信号要精炼到最小可操作单元。“循环检测”和“强制验证”是专门为非人类认知体的行为缺陷设计的补偿机制。

这 4 个案例说明：Agent 的竞争优势不仅在于用了哪个模型，更在于构建了怎样的 Harness。 Harness 成了新的护城河，不仅是 Agent Builder 的，也是 Agent User 的。

04 群体智能：企业业务创新的拐点

提效的故事已经不够性感，业务创新才是企业为 Token 付费的最强动力。

Harness Engineering 不仅让单 Agent 更可靠，也用于优化多 Agent 间协作，通过群体智能加速业务创新，克服知识孤岛和创意衰减。这一课题正被一系列开源项目推向实践前沿。

▍ CLI-Anything：群体智能的基础设施
来源：香港大学数据智能实验室，github.com/HKUDS/CLI-Anything

AI Agent 能推理、写代码，但让它打开 GIMP 去图片背景或用 Blender 渲染 3D 场景？它做不到。GUI 是为人类设计的。

CLI-Anything 是一个 Claude Code 插件，能分析任意软件的源代码，自动生成一套生产级的命令行接口（CLI），调用真实应用后端（如 LibreOffice 生成 PDF、Blender 渲染 3D 场景）。

一条命令完成全部工作：/cli-anything <path-or-repo>，经过分析→设计→实现→测试→文档→发布的 7 阶段全自动流水线，输出一个可 pip install 的 Python 包。

每个生成的 CLI 都自带 SKILL.md，一份机器可读的能力描述文件。这意味着 Agent 可以在运行时自动发现其他 Agent 能做什么，动态组建协作关系。这就是群体智能的基础设施。

▍ HiClaw：群体智能的操作系统
来源：阿里云，github.com/alibaba/hiclaw

但 CLI-Anything 只解决了部分问题。想象企业有10多个关键部门，基于单体 OpenClaw 构建群体智能会面临：

1. 可扩展性差：无法自由组合、按需引入新 Agent，需重新部署。
2. 模型不自由：所有 Agent 只能使用默认模型。
3. 越聊效果越差：多 Agent 在一个房间协作，记忆和 Skills 易被污染。
4. FinOps 难落地：Token 消耗不可控，ROI 面临挑战。

HiClaw 旨在解决这些问题：

• Manger-Workers 架构：可灵活创建代表各角色的 Worker，引入企业自建 Agent。所有 Worker 的 Skills 和记忆独立存储，避免污染。
• Agent 与模型可自定义：支持 OpenClaw、Copaw 及企业自建 Agent。每个 Agent 可自由配置后端模型（如代码生成用百炼，文本撰写用本地 Qwen），助力 FinOps。
• 引入 MinIO 共享文件系统：用于 Agent 间信息共享，大幅降低多 Agent 协作的 Token 消耗。
• 引入 Higress AI Gateway：实现鉴权路由、凭证安全、多模型接入与 fallback、限流降级、Skills 统一管理、实时监控与安全审计。AI Gateway 的可靠性直接关系到 AI 的稳定性。

来看一个基于 HiClaw 的实践案例：一家汽车生产商计划生产一款 700W 豪车，通过设计多个角色进行 100 轮讨论，挖掘目标人群价值点。

案例中，我们选择 3 位不同身份的目标用户进行自由讨论。在 100 轮对话中，他们从品牌认知、舒适需求、安全隐私、软价值等多个维度进行了激烈探讨。

由于内容较多，感兴趣的朋友可以去 GitHub 围观完整讨论过程：https://github.com/alibaba/hiclaw/issues

Harness Engineering 是让企业拥有一支可编排、可治理、可持续进化的数字化智能团队。个人效率的提升是线性的，而群体智能的涌现是指数级的。CLI-Anything、HiClaw 这类项目正是 Harness Engineering 在群体智能领域的探索和实践。

从单点提示到系统化驾驭，软件工程方法论正在因 AI 而重塑。无论是提升单 Agent 的可靠性，还是激发多 Agent 的群体智能，驾驭工程都为我们提供了一套全新的工具箱。未来，善于构建和运用 Harness 的团队，或许才能真正释放 AI 的全部潜力。关于这些技术的更多深度讨论和实践分享，欢迎关注 云栈社区，与广大开发者一起交流成长。