Harness Engineering：如何构建不会崩溃的AI Agents

大多数人面对失职的代理人会通过改变提示来应对。

然后他们改变了模型

然后他们添加了一个更大的上下文窗口

代理人仍然会忘记决定

它仍然使用错误的工具

它仍然跳过验证

它仍然陷入同样的​​循环

问题并不总是出在智力上。

问题出在它周围的环境上。

那种环境就是束缚

而设计它就是线束工程。

Anthropic 首席执行官 Dario Amodei在解释 Claude Code 的由来时直接提到了这一点。

“当然，你需要接口，你需要线束才能使用它们。”

我在 Substack 上发布对 AI 代理、工作流程和生产系统的实用分析。

该模型仅指推理引擎。

模型可以建议下一步行动

它自身无法创建可靠的运行环境。

这套装置决定了模型能看到什么、能触摸到什么、哪些东西能在两次实验之间保留下来、哪些东西会被当作证据，以及实验何时必须停止。

MODEL reasons and proposes actions HARNESS selects context exposes tools stores state enforces permissions checks results records traces recovers from failure

提示是该系统的一个组成部分。

该模型是另一个

该产品是所有相关组件协同工作的结果。

及时的工程设计可以改进教学。 机箱工程改善了指令执行的条件。

同一个模型可以变成完全不同的代理。

将同一个模型放入聊天框中，它就能回答问题。

把它放到一个具备终端访问权限、测试、浏览器工具、项目内存、隔离工作树和代码审查循环的仓库中，它就可以发布软件了。

重量没有变化

安全带

OpenAI 在构建以代理为先的代码库时，也描述了同样的转变（参见 Codex）。

他们早期进展缓慢，是因为环境描述不够详细，而不是因为模型本身缺乏基本能力。

回应并非要求经纪人更加努力。

其目的是探究缺失了哪些能力，并使这种能力既清晰易懂又切实可行。

“环境描述不够详细” OpenAI驾驭工程：在以代理为先的世界中利用 Codex

这是中心思想

当代理多次失败时，停止编辑提示中的形容词。

检查模型周围的系统

生产线束有七个功能

1. 将请求转化为合同

在代理执行操作之前，将请求转换为有界对象。

{"goal":"ship the feature","inputs":["issue","repository","design"],"output":"reviewable pull request","constraints":["no schema changes","preserve public API"],"done_when":["tests pass","visual check passes","review passes"]}

合同保护任务免受悄然重新定义。

如果没有它，代理人可以完成另一项任务，仍然宣布成功。

2. 给代理人一张地图

经纪人需要项目知识

他们不需要在每个上下文窗口中都放置每个文档

使用一份简短的根系指南，告诉代理人应该在哪里查找。

AGENTS.md ->architecture map ->testing map ->product rules ->security rules ->task-specific guides

地图保留了上下文

一本厚厚的手册吞噬了它

将详细知识与它所控制的代码、工具或工作流程紧密联系起来。

仅在当前任务需要时加载它

3. 在合适的环境中提供合适的工具

Tool access is not a list of buttons

It is an interface between the model and the real world

Every tool needs a clear purpose, predictable output, explicit failure state, and a permission boundary

READ FILES allowed by default RUN TESTS allowed inside sandbox WRITE FILES allowed inside workspace ACCESS NETWORK scoped by task DEPLOY requires approval DELETE DATA requires approval

Good tools reduce ambiguity before the model has a chance to reason badly

Bad tools force the model to guess what happened

4. Externalize memory into durable state

The conversation is not the system of record

Store decisions, artifacts, failures, and open risks outside the context window

{"task_id":"task_042","current_step":"verify_ui","artifacts":["build.zip","report.md","screenshot.png"],"decisions":["keep existing schema"],"failures":["mobile overflow at 390px"],"pending":["human approval"]}

The next session should inherit the state of the work, not a lossy retelling of the conversation

This is how an agent survives context resets, crashes, and handoffs

5. Add sensors before adding autonomy

An agent cannot correct what it cannot observe

Tests, linters, screenshots, logs, metrics, and schema validators turn vague quality into evidence

CODE ->tests +typechecks + lint UI ->render + screenshot + visual inspection RESEARCH ->sourcecheck + contradiction check DATA ->schema + range + freshness checks

The model creates an artifact

The environment produces evidence about the artifact

The harness decides whether that evidence is enough to continue

6. Enforce permissions outside the model

The model can recommend an action

The harness must authorize it

MODEL SUGGESTS ->POLICY CHECKS ->TOOL EXECUTES

This separation matters most when the action is expensive, irreversible, or touches another person

Do not ask the same probabilistic system to invent the plan, approve the risk, and execute the side effect

7. Record traces and recover locally

Every run should leave a readable trail

request selected context tool calls state changes verification results retries cost final artifact rollback point

Without traces, failure becomes a mystery

With traces, failure becomes input for the next harness improvement

Instructions should become infrastructure

Most teams keep important rules in prose

The agent reads them

Then eventually ignores one

The stronger pattern is to encode the important rule twice

First as guidance the agent can understand

Then as a mechanical check the agent cannot bypass

GUIDE"UI code may not query the database directly"CHECK lint fails when UI imports the repository layer

The guide explains the reason

The check enforces the boundary

This turns a past failure into a permanent system improvement

The next agent does not need to remember the incident

The harness remembers for it

The loop belongs to the harness

Long-running work needs iteration

But “keep trying until it works” is not a control system

A useful loop has evidence, bounded retries, a budget, and an escalation path

for(let attempt=1;attempt<=3;attempt+=1){const artifact=await build(state)const evidence=await verify(artifact)if(evidence.pass)returnartifact state.failures.push(evidence.gap)state.repair=evidence.repair}returnrequestHumanReview(state)

The model should decide how to repair the local gap

The harness should decide whether another attempt is allowed

Anthropic reached a similar conclusion in its work on long-running agents

Structured artifacts preserve continuity across sessions, while a separate evaluator gives the builder concrete feedback instead of letting it approve its own work

“Find the simplest solution possible, and only increase complexity when needed” Anthropic,Harness design for long-running application development

Failure should upgrade the system

Most people repair the current output

Harness engineers repair the class of failure

MISSING CONTEXT ->adda map or retrieval rule WRONG TOOL ->improve tool description or routing BAD OUTPUT ->adda validator or stronger contract REPEATED LOOP ->adda retry cap and escalation UNSAFE ACTION ->adda permission gate LOST DECISION ->store itindurable state UNKNOWN FAILURE ->addtracing and evidence capture

The immediate patch fixes one run

The harness change improves every run after it

That is the compounding advantage

A good harness converts agent mistakes into infrastructure

Separate the brain, the hands, and the history

当三个组成部分彼此独立时，一个可靠的代理更容易被理解。

BRAIN the model that reasons HANDS the sandbox and tools that act HISTORY the append-only record of what happened

即使沙盒消亡，历史依然长存。

如果模型发生变化，工具和政策仍然可检查。

如果任务恢复，新的会话可以根据工件和跟踪信息重建状态。

Anthropic 的托管代理架构通过会话、工具和沙箱明确地实现了这种分离。

4月9日

介绍 Claude 托管代理：构建和大规模部署代理所需的一切。 它将针对性能优化的代理框架与生产基础设施相结合，让您可以在几天内从原型过渡到发布。 现已在 Claude 平台上进入公开测试阶段。

重要的不是供应商。

这是建筑风格

推理引擎不应同时兼任文件系统、权限系统、内存数据库和审计日志的功能。

每次跑步都应提供找零收据

当代理完成任务后，不要只保留最终输出。

保留一份简明扼要的收据，说明产出过程。

{"context_sources":["issue","repo_map","design_spec"],"policy_version":"v12","model_route":"complex_coding","tools_used":["shell","browser","tests"],"tests":{"passed":42,"failed":0},"human_corrections":1,"retries":2,"cost_usd":3.84,"accepted_artifact":"pr_1842","rollback_point":"commit_7f3a"}

这使得车型升级具有可比性。

它使回归分析可归因于

它使审计成为可能。

这样可以防止最终答案掩盖流程中的缺陷。

首先从能闭合回路的最小安全带开始。

工程设计并不意味着在第一个任务之前就构建平台。

首先从能够观察、验证和恢复的最小系统入手。

LEVEL0prompt + model LEVEL1project guide + tools LEVEL2structured state + tests + bounded loop LEVEL3permissions + traces + recovery + human gates

只有当任务值得增加复杂性时，才提升难度。

一项简短且风险较低的任务可能只需要一次提示和一次复习。

一个能够编辑文件、访问网络并提交拉取请求的六小时编码运行需要一个真正的工具箱。

安全带的尺寸应小于其所控制的失效面。

线束工程检查清单

在将实际工作委托给经纪人之前，请先询问清楚。

[]Is success defined before execution begins[]Can the agentfindthe right project knowledge without loading everything[]Does every tool have aclearcontract and failure state[]Is execution isolated from production systems[]Are important decisions stored outside the conversation[]Does every risky transition have evidence[]Are irreversible actions protected by approval[]Does every loop have a retry cap and budget[]Can the run resume after interruption[]Can you explain every tool call and state change[]Does failure update a guide, test, tool, or policy[]Can the final artifact be rolled back

如果多个答案都是否定的，那么更强大的模型并不能使系统可靠。

这样做只会让失败的代价更加高昂。

真正的转变

及时的工程设计会告诉模型该做什么。

上下文工程决定了模型可以看到什么。

线束工程构建了模型运行的世界。

PROMPT ->instruction CONTEXT ->working view HARNESS ->operating system LOOP ->localimprovement GRAPH ->coordination

该模型下个月可能会有所改变。

工具、测试、状态、策略和跟踪可以不断改进。

这就是为什么持久优势正从即时性转移到围绕它的系统上。

最优秀的建筑商不仅会问哪种模型最智能，还会问哪种模型最智能。

他们会问，什么样的环境才能使这种情报可靠？

这就是线束工程