TL;DR： Harness Engineering 是围绕模型建立的运行时控制面：能力白名单、身份与资源策略、有界执行、证据、人类决定和恢复机制。MCP 可以暴露能力，工作流库可以协调状态，沙盒可以降低爆炸半径；它们单独都不能让自主代码修改变得安全。

引言

在 Harness Engineering 的理论篇中，我们明确了“Agent = Model + Harness”的公式。现在，让我们进入工程实战：如何从零开始搭建这套约束系统？

可版本化的 Harness 设计

不存在适用于所有团队的统一技术栈。生产设计通常需要明确以下关注点：

  1. 能力接口：MCP 或其他适配器暴露范围受限的工具；服务器和运行时仍需执行身份、资源、网络、速率和副作用策略。
  2. 工作流状态机：LangGraph、队列或应用代码可以协调状态、重试、取消和持久化，但不会暴露或保证模型的私有思维链。
  3. 执行边界：容器、虚拟机或 WASM 可能降低进程爆炸半径，但仍需镜像/运行时加固、文件系统和网络策略、密钥隔离、配额和宿主机监控。

实战步骤：构建一个“自愈式代码 Agent”

下面是一个自动修复 Lint 错误的示意 Agent；它不是开箱即用的生产实现。

第一步：定义节点与状态 (LangGraph)

首先，我们需要在 Harness 层定义 Agent 的工作流逻辑：

python 
# 示意伪代码；版本、状态 schema、沙盒 API 和授权策略省略。
from langgraph.graph import StateGraph, END

def generate_code(state):
    return {"proposal": model.generate(state["task"], state["allowed_context"])}

def run_linter(state):
    result = sandbox.run(
        ["npm", "run", "lint"],
        cwd=state["workspace"],
        network="deny",
        timeout=state["budgets"].command_seconds,
    )
    return {"lint": result.to_bounded_record()}

def fix_errors(state):
    return {"proposal": model.revise(
        state["proposal"], state["lint"], state["allowed_context"]
    )}

# 构建图：generate -> lint -> (if error) fix -> lint
workflow = StateGraph(AgentState)
workflow.add_node("generate", generate_code)
workflow.add_node("lint", run_linter)
workflow.add_node("fix", fix_errors)

workflow.add_conditional_edges(
    "lint",
    lambda s: "fix" if s["lint"].has_actionable_errors else END,
)

运行时必须校验补丁，将其限制在授权工作区内，限制输出和重试预算，以隔离身份运行测试，并在提交或外部写入前要求独立的策略决定。

第二步：配置 MCP 工具集

MCP 配置声明传输和服务器，但不能证明调用者有权读写某个路径。应使用运行时签发的身份以及资源和操作白名单：

json 
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/workspace"]
    }
  }
}

第三步：设计人机协作 (Human-in-the-Loop)

审批应是绑定到具体 diff、仓库、分支、操作者、过期时间和策略的持久化认证决定；终端输入本身不是授权控制：

python 
def human_approval(state):
    decision = approval_service.request(
        actor=state["principal"],
        effect="repository_write",
        diff_digest=state["diff_digest"],
        target=state["target_branch"],
    )
    return {"approved": decision.is_valid_for(state)}

Harness 优化的三大秘诀

1. 差异化模型策略 (Model Tiering)

不要用最贵的模型做所有的事。应在代表性质量、安全、延迟、隐私和成本切片上比较模型版本；确定性检查优先使用解析器、编译器和 Lint 工具，而不是模型。

2. 上下文清理 (Context Pruning)

在“生成-报错-修复”的循环中，上下文会迅速堆积。可以摘要或裁剪重复日志，但必须保留源版本、策略决定、失败信息和审计/复现所需的来源。

3. 环境快照 (Environment Snapshot)

修改前创建隔离工作区，记录源版本和补丁摘要。Git 分支或快照只能帮助恢复仓库状态，不能回滚邮件、部署、数据库写入等外部副作用；这些需要幂等键和补偿流程。

典型架构图

graph TD User["用户需求"] --> Harness["Harness 控制器"] Harness --> LLM["LLM 推理 (Brain)"] LLM --> Tools["MCP 工具集 (Hands)"] Tools --> Sandbox["Docker 沙盒 (Safety)"] Sandbox --> Feedback["结果反馈 (Logs/Errors)"] Feedback --> Harness Harness -- "结果合格" --> User

总结

Harness Engineering 的核心是把模型输出当作不可信提案，并在运行时执行策略。流程控制、能力适配器、执行隔离、证据、人类决定和恢复机制都应分别测试，不能因为使用某个框架名称就默认安全。

下一步，你可以了解如何将多个这种受约束的 Agent 组合成一个 多 Agent 系统 (Multi-Agent System)。

相关阅读：

一手来源