Harness Engineering：AI Agent复杂长任务的工程秘方
输入“/”快速插入内容
Harness Engineering：AI Agent复杂长任务的工程秘方
Harness Engineering：AI Agent复杂长任务的工程秘方
用户4242用户42422月27日修改
原创 Fighter Fighter Fighter的世界2026年2月21日 09:21 北京
Views are my own.
“Yet Another Chapter”，Generated by Google Lyria
OpenAI 的一个团队在五个月内用 Codex 写了一百万行代码，三个工程师平均每天合并 3.5 个 PR，没有一行代码是工程师手写的。Anthropic 的 Claude Code 能连续工作数天构建完整应用。LangChain 的 Coding Agent 在 Terminal Bench 2.0 上从 52.8% 跃升至 66.5%，却 只改了 harness，模型没动 。
随着 Coding Agent 能力过去一段时间的突飞猛进，软件工程师的工作变了：从“写代码”变成了“设计让 AI 可靠工作的环境”。
这种设计能力，有个名字：Harness Engineering。
一、什么是 Harness Engineering?
Anthropic 在其官方文档中给出了它们的定义：
“An agent harness (or scaffold) is the system that enables a model to act as an agent : it processes inputs, orchestrates tool calls, and returns results.”
“Agent Harness（或称 scaffold）是 让模型能够作为 Agent 工作的系统 ：它处理输入、编排工具调用、返回结果。”
——Anthropic, Demystifying evals for AI agents
Parallel AI 提供了更详细的定义：
Harnesses emerged as a way to formalize planning and guardrails so that the agent’s output is actually useful and correct. Especially for long-running agents, harnesses provide a way to maintain state and continuity .
Harness 的出现是为了 形式化规划和护栏 ，使 Agent 的输出真正有用且正确。对于长时间运行的 Agent，Harness 提供了一种 维护状态和连续性 的方法。
用直白的话说： Harness 是设计一个系统，让 AI 能可靠地完成复杂任务 。
从一个简单例子开始
假设要让 AI Agent 帮你重构一个 10 万行的代码库。
裸 Agent ：把代码扔给 GPT 5.2 或者 Claude 4.6，说“帮我重构”
→ Agent 看了 1000 行就开始瞎改，3 小时后代码库崩了
有 Harness :
1.
先给 Agent 注入架构文档
2.
限制每次只能改一个模块
3.
强制改完后必须跑测试
4.
检测到失败时自动回滚
→ Agent 花了 2 天，成功重构了 80% 的代码
Harness Engineering 的作用是：设计一个环境，让 AI 能可靠地完成复杂工作。
核心维度
常见的误区是把 harness 当作“给 LLM 接工具的胶水层”，但实际的 Harness Engineering 包含三个核心维度：
Context Engineering ：提供充分的结构化上下文
•
不是把所有信息扔给 Agent，而是给它一个“地图”
•
OpenAI 的 AGENTS.md 只有 100 行，但它指向完整的知识库
Tool Engineering ：设计受控的高效工具
•
不是让 Agent 直接操作数据库，而是提供封装好的、带约束的 API
•
Hightouch 的 Agent 不能执行任意 SQL，只能调用预定义的查询函数
Workflow Engineering ：构建信任的验证循环
•
不是让 Agent 自己判断“做完了”，而是用外部标准验证
•
LangChain 的 middleware 强制 Agent 在退出前跑测试
解决的核心问题是： 如何让 LLM 在长时间、多步骤的复杂任务中保持一致性和可靠性 。
二、Harness Engineering 为什么会出现？
Agent 的核心挑战
当我们说“AI Agent 能自主完成复杂任务”时，隐含了一个假设：Agent 能够在长时间、多步骤的复杂任务中保持一致性。
但这个假设与 LLM 的特征存在冲突：
LLM 是无状态的 ：每次推理都是独立的函数调用， f(context) → output
复杂工作是有状态的 ：需要记住“我做了什么”、“为什么这么做”、“下一步该做什么”
LLM 的模式是 next token prediction：给定 context，预测下一个 token。这个模式本身就是无状态的。但 Agent 需要完成的是 task completion：记住目标，规划步骤，执行，验证，直到完成。这是有状态的工作。