星澜

天接云涛连晓雾，星河欲转千帆舞

04. AI Agent 与 Harness：V2 Harness 的验证设计

mingzaily / Codex / 2026-03-29

前面几篇把概念、演进背景和外部文章都铺开了，但真正落到工程里，最难的一层往往不是“怎么让 agent 开始做事”，而是“怎么确认它真的做成了”。

很多团队已经有 prompt、skill、AGENTS.md、MCP 和常用工具，agent 也确实能开始干活。
问题通常出在交付阶段：测试会漏跑，状态会漏校验，模型会以为自己完成了，系统却没有真的过关。

所以这一篇只想回答一个非常落地的问题：

验证阶段的 harness，到底应该怎么设计？

尤其是下面这个追问：

如果你还没看前面的三篇，可以先按《01. AI Agent 与 Harness：概念梳理》、《02. AI Agent 与 Harness：从 Prompt 到 Harness》、《03. AI Agent 与 Harness：Anthropic 和 LangChain 的 Harness Engineering》这条线补完，再回来看这一篇会更顺。

结论

很多团队其实已经有了 V1 级别的 agent setup，但还没有真正进入 V2 agent harness。

比如开发团队里，大家已经开始做这些事：

这些都很有价值，而且已经远远不只是“写好提示词”了。
但它们更多解决的是：

这更多还是：

V1 级别的 agent setup

而 V2 agent harness 的关键增量是：

把“请你验证一下”升级成“系统里真的有验证闭环”。

V1 和 V2 的分水岭到底在哪

可以直接把它理解成：

V1：轻量 agent harness

典型特征：

目标是：

让 agent 更容易做事。

V2：验证型 agent harness

典型特征：

目标是：

不只是让 agent 会做事，而是让 agent 做完之后真的过关。

所以 V1 和 V2 的分界，不在于工具数量，而在于：

有没有验证循环。

为什么很多团队会自然停在 V1

因为 V1 很自然，V2 很反直觉。

V1 的思路是：

这很像给一个新人发 onboarding 文档。
通常已经能显著提升表现。

但问题是，模型终究会：

所以如果没有验证闭环，V1 的上限就比较明显：

它能让 agent 更像一个守规矩的实习生，但还不能让它稳定交付。

验证到底在验证什么

一说“验证”，很容易变成一句空话。
更精确一点，验证其实至少可以拆成三层：

1. 输入前验证

先确认这单任务能不能做。

比如：

2. 动作前验证

在真正调用工具前，再做一次硬校验。

比如：

3. 动作后验证

动作做完后，系统再确认结果是否真的成立。

比如：

这三层都属于验证，也都可以出现在 V2 agent harness 里。
V1 和 V2 的分水岭，不在于有没有某个叫 validator 的节点，而在于：

系统里是不是真的存在验证闭环。

如果再往下细分，前两层更像防错：

第三层更像验收：

做完之后，结果是不是真的成立。

而真实系统里，最容易缺的往往恰恰就是最后这一层。
很多系统会做输入检查，也会做权限和规则检查，但动作执行之后，并不会继续确认结果有没有真的生效。

下面要重点讲的 Post-condition Validator，对应的就是这层“动作后验收”。

Post-condition Validator 到底是什么

它的定义其实很朴素：

动作执行完之后，系统去检查“世界是不是已经变成预期的样子”。

它不是检查：

而是检查：

你可以把它理解成：

它之所以值得单独拿出来讲，不是因为前两层不重要，而是因为 agent 最常见的问题往往不是“不知道能不能开始做”，而是：

所以 Post-condition Validator 更像 V2 里最能体现“闭环”价值的一层。

所以，如果一个 agent：

那本质上都是：

缺少 post-condition validation

这里的 Post-condition Validator 是为了说明问题做的归纳词。
Anthropic 和 LangChain 原文不一定直接用这个术语，但它们都在强调同一件事：

退款 Agent 的验证 harness 流程图

下面这张图更接近实际落地时的结构：

flowchart TD
    A[用户发起退款请求] --> B[LLM 解析意图与关键信息]
    B --> C{输入前验证}
    C -->|信息不足| D[追问或转人工]
    C -->|可继续| E[查询订单 / 用户 / 政策]
    E --> F{动作前验证}
    F -->|reject| G[拒绝并解释原因]
    F -->|risky/manual| H[转人工审批]
    F -->|auto pass| I[调退款接口]
    I --> J{动作后验证}
    J -->|ok| K[回复用户结果]
    J -->|failed| L[进入返工 / 告警流程]
    K --> M[Trace / Audit / Replay]
    L --> M

这张图里最重要的不是框，而是你会发现验证被拆成了三层：

而 Post-condition Validator 就处在“动作后验证”这一层。
这整张图表达的是完整的验证闭环，不是说只有最后这层才算 V2；只是对 agent 系统来说，最容易缺、也最能体现闭环价值的，通常正是最后这道验收门。

如果是 coding agent，验证为什么还是会忘

在 Codex、Claude Code 这类 coding agent 里，我们经常会这样写规范：

这些都对，但它们大多还是：

软约束

也就是写在：

里的要求。

软约束很重要，但它解决不了所有问题。
模型仍然可能：

所以 coding agent 如果要进入 V2，也要把验证做成更硬的东西，比如：

业务 agent 和 coding agent 的差别，到底在哪

差别不在于“需不需要验证”，而在于“测试”的形式变了。

coding agent 的验证通常是：

业务 agent 的验证通常是：

所以业务 agent 不能只靠提示词提醒它：

这些依然只是软约束。

更成熟的做法是：

把验证做成系统里的硬流程。

在 agent harness 里，Post-condition Validator 怎么落地

这里是最硬的一层。

最底层当然可以就是 if else

比如退款 agent：

result = refund_tool.invoke(order_id=order_id)

if not result.ok:
    return {"status": "failed", "reason": "refund api failed"}

order = order_service.get(order_id)
if order.refund_status != "pending":
    return {"status": "failed", "reason": "refund status not updated"}

crm_record = crm_service.find_by_order(order_id)
if not crm_record:
    return {"status": "failed", "reason": "crm record missing"}

return {"status": "passed"}

这已经是一个 Post-condition Validator 了。

所以答案是：

是的，在 agent harness 的底层实现里，它当然可以就是 if else。

但更成熟的做法，是把它做成独立节点或模块

更像样的工程落地通常是：

比如统一返回：

{
  "passed": false,
  "retryable": true,
  "severity": "medium",
  "reason": "refund status not updated",
  "next_step": "retry_or_manual_review"
}

这样 orchestration 才能继续决定：

如果用 LangChain / LangGraph，应该怎么理解

如果用 LangGraph，我会更建议这样看：

Validator 不是一句 prompt，而是 action 之后的固定节点。

一个很常见的结构会是：

flowchart TD
    A[用户请求] --> B[意图解析节点]
    B --> C[查询订单节点]
    C --> D[退款执行节点]
    D --> E{Post-condition Validator 节点}
    E -->|pass| F[回复用户]
    E -->|retry| G[回到执行 / 修复节点]
    E -->|manual| H[转人工节点]
    E -->|fail| I[结束并告警]
    G --> D

所以在 LangGraph 里，重点不是“能不能写 if else”，而是：

在仓库规则、验证命令和 CI 流程里，验证闭环怎么体现

这类仓库级约定通常没法把系统内部的 validator 直接嵌进实现里，但它可以把整套验证闭环外置成团队流程里的硬门。

所以更常见的体现，会是：

1. 固定验证命令

比如在 AGENTS.md 里，不只写：

而是写成：

这时候真正的验证器是那个命令，不是那句提示词。

2. 固定验证报告

要求 agent 最终必须给出：

这相当于让验证结果被结构化暴露出来。

3. CI / PR 阻断

这类工作流里最硬的 validator，很多时候不是 agent 自己，而是：

这其实就是团队层的验收 gate。

4. replay case

比如团队积累：

每次改 skill、改 prompt、改 workflow 后都重放一遍。
这就是仓库工作流里的回归验证器。

两层验证怎么分

可以压成两句话：

所以一个业务 agent 的 V2 agent harness 通常包括什么

压成组件列表，大概就是这几个：

对团队来说，最现实的升级路径是什么

如果团队现在已经有这些：

那大概率还停留在 V1。

下一步最值得补的，不一定是更多 skill，也不一定是更多 MCP，而是：

1. 明确 done 定义

比如：

2. 把关键验证变成硬门

比如：

3. 给高风险动作设计人工接管口

不要追求“全自动化”，而是追求：

低风险自动，高风险稳妥。

4. 开始积累 replay case

也就是把历史真实案例沉淀下来，变成：

这一步很朴素，但对 V2 agent harness 非常关键。

一句话总结

如果只留一个定义：

V1 级别的 agent setup 让 agent 更容易做事，V2 agent harness 让 agent 做完之后真的过关。

或者更硬一点：

V2 agent harness 的本质，就是把“请你验证一下”升级成“系统里真的存在验证闭环”。

如果你想继续把 agent harness 和仓库规则 / skills / workflow 分开看，可以接着读：

参考