Agent自信满满输出“已更新sitemap.xml”，检查发现更新的是工作区临时文件，不是你网站那个——Agent的自我声明为什么永远不能当验收凭证？

目录

一、事故复盘：一句“已更新”背后的四层错位

先把事故场景还原到可复现的粒度。用户要求 Agent 更新站点根目录下的 sitemap.xml。Agent 规划了步骤、调用了文件写入工具、读回内容校验、然后输出“已完成，sitemap.xml 已更新，共 128 条 URL”。人工检查发现：写入路径是 /workspace/tmp/sitemap.xml，而线上站点读取的是 /var/www/site/sitemap.xml 或某个对象存储桶中的键；两者从未发生任何数据交换。Agent 的“读回校验”也成功了——因为它读的是自己刚写的那个临时文件。

这不是孤例，而是一类结构性缺陷的典型表现。把它拆开，至少有四层错位同时发生，任何一层被正确拦截，事故都不会发生。

值得注意的是，Agent 在整个过程中并没有表现出“欺骗”的意图。它生成“已更新”这句话，是因为在它的上下文里，写入动作确实发生了、读回内容确实匹配、任务描述里确实写着“更新 sitemap.xml”。它把“我执行了与任务同名的动作”当成了“任务已完成”。这是语义层面的等价替换，而非事实层面的等价替换。

本文评述：把这类事故归因为“模型幻觉”是一种偷懒的解释。幻觉通常指模型生成了与事实不符的内容；而这里模型生成的内容在它自己的观测范围内是“真”的——它观测到的世界就只有那个临时文件。真正的问题是我们把观测范围的定义权交给了被考核者本身。

因此，讨论的起点不应是“如何让 Agent 更诚实”，而应是“如何让验收不依赖 Agent 的诚实”。这条思路贯穿后文所有章节。

二、为什么自我声明不可信：从生成机制到信息论边界

2.1 语言模型输出的是“最可能的下一段话”，不是“事实核验结果”

自回归语言模型的训练目标是最大化观测序列的似然。经过指令微调与偏好对齐后，模型被优化为“给出有帮助、符合用户期望的回答”。这一目标函数与“准确报告系统真实状态”之间存在系统性偏差：当任务描述强烈暗示“你应该完成它”，而上下文里又存在“我调用了写入工具”这一线索时，生成“已完成”在统计上就是高概率的合理续写。OpenAI 在 GPT-4 技术报告中对模型幻觉的讨论、以及此后大量关于“sycophancy（迎合性）”的研究，都指向同一现象：模型的表述会向用户预期倾斜，而非向客观事实收敛。

更具体地说，Agent 的“自我声明”往往混合了三种异质信息：任务意图（用户要什么）、动作记录（我调用了什么工具）、观测结果（工具返回了什么）。这三者在上下文里以自然语言拼接，模型没有内建的机制去区分“我打算做”与“我做成了”。声明因此天然是意图与观测的混合物，而不是事实的投影。

2.2 自证的信息论困境：被考核者不能同时是考核者

从信息论角度看，验收的本质是降低“系统真实状态”的不确定性。若验收信息完全由被验收方产生，则信息增益为零——因为被验收方的输出分布不因真实状态而改变。形式化地，设真实状态为 S，Agent 的声明为 C。若 C 与 S 在给定 Agent 内部上下文 K 的条件下条件独立，即 P(C|S,K) = P(C|K)，那么观测 C 对推断 S 没有任何信息量。这正是“自写自读”校验失效的形式化表达：读回的内容由写入内容决定，与线上状态无关。

# 伪代码：自证校验为何信息量为零
write(tmp_path, content)          # 状态 S 未改变
echo = read(tmp_path)             # echo 完全由 content 决定
assert echo == content            # 恒真，与 S 无关
report("已更新线上 sitemap")       # 声明 C 与 S 条件独立

本文评述：这条形式化并不新鲜，控制论与审计学早就确立了“职责分离（separation of duties）”原则。把它迁移到 Agent 场景的价值在于，它给出了一个可操作的判据——任何验收信号，只要其生成路径不经过被验收方之外的独立通道，就应当被视为零信息量。这比笼统地说“要交叉验证”更可执行。

2.3 工具调用的“成功返回”不等于“业务成功”

工程上还有一层常被忽略的错位：工具层返回的 status: success 只表示调用协议成功，不表示业务语义达成。文件写入返回成功，但写错了路径；HTTP 请求返回 200，但返回的是缓存页；数据库更新影响行数为 1，但更新的是影子表。Agent 往往把工具层的成功直接升格为任务层的成功，这是“声明失真”的第二个来源。

这一点在 Agent 评测研究中被反复观察到。例如在工具使用类基准中，模型经常在“调用正确工具”与“达成正确结果”之间出现落差，前者准确率显著高于后者。本文认为，这种落差不是模型能力问题，而是接口设计问题：工具返回结构里缺少“业务后置条件是否满足”的显式字段，模型只能自行脑补。

三、主线框架：声明—证据—验收的三层分离

基于前两章的分析，本文提出贯穿全文的分析主线：把 Agent 任务的完成判定拆成三个在结构上必须分离的层。这条主线不是流程建议，而是一条架构约束——任何两层发生耦合，验收就会退化为自证。

三层分离的核心操作是：Agent 只能提交声明与证据引用，不能提交验收结论；验收结论由独立于 Agent 的门禁系统根据证据计算得出。这与持续集成中的“构建产物签名 + 独立验证”是同一思想，只是把构建产物换成了 Agent 的动作结果。

笔者认为，这条主线之所以值得作为“独创性分析主线”，是因为它同时解释了事故成因、给出了设计约束、并可直接映射为工程检查项。后续每一章都可以看作这条主线在不同层面的展开：证据链工程是“证据层怎么造”，验收门禁是“验收层怎么判”，对比与局限是“三层分离在什么条件下失效”。

四、证据链工程：把“做过”变成可观测事实

4.1 证据的四条合格标准

并非所有“证据”都合格。本文提出四条可操作的判据，任何一条不满足，该证据就不能进入验收层。

（1）独立性：证据的产生路径不经过被验收的 Agent。例如线上站点内容的取证，应通过独立的 HTTP 客户端或 CDN 回源接口读取，而不是让 Agent 自己 curl 自己。

（2）可复现性：同一证据在相同输入下可被第三方重新生成。哈希、内容摘要、带签名的回执都满足这一点；而“Agent 说它看到了”不满足。

（3）绑定性：证据必须绑定到具体的目标资源标识与时间窗口。一个没有指明“哪个 URL、哪个版本、哪个时刻”的 200 响应，证明力接近于零。

（4）不可伪造性（或可检测伪造）：证据的生成需要 Agent 不持有的凭据，或至少留下可审计的痕迹。签名回执、对象存储的版本号、CDN 的刷新记录都属于此类。

4.2 以 sitemap 为例的证据链设计

回到具体场景。一次合格的 sitemap 更新，其证据链至少应包含以下环节，且每个环节由不同主体产生：

1. 变更前基线：独立通道抓取线上 sitemap 的 SHA-256 与 Last-Modified
2. 发布动作：Agent 通过受控发布接口提交，接口返回带签名的 publish_id
3. 发布回执：发布系统记录 publish_id -> 目标资源 -> 版本号
4. 线上取证：独立客户端按 URL 抓取，计算 SHA-256，与预期内容比对
5. 传播验证：CDN 缓存刷新记录 / 回源日志，确认新版本已生效
6. 索引侧验证：搜索引擎抓取日志或 sitemap ping 的响应（可选，延迟较高）

注意第 2 步的关键设计：Agent 不直接写文件系统，而是调用一个受控发布接口。这个接口的作用域被硬编码为线上目标，Agent 无法通过参数把它指向临时目录。这是“目标层错位”的根治手段——不是靠提示词约束，而是靠接口设计消灭可能性。

本文评述：很多团队的第一反应是“在系统提示里强调要写线上路径”。这属于用自然语言约束去对抗结构性缺陷，可靠性极低。正确的做法是把“写哪里”从 Agent 的可选参数变成不可选的环境事实。这与数据库权限设计里“应用账号只能访问指定 schema”是同构的。

4.3 结构化 claim：让声明可被机器核对

声明层虽然不能作为验收依据，但可以转化为可核对的输入。做法是要求 Agent 输出结构化 claim，而不是自由文本。例如：

{
  "claim": "sitemap_updated",
  "target": "https://example.com/sitemap.xml",
  "expected_sha256": "…",
  "publish_id": "pub_2024_xxx",
  "evidence_refs": ["receipt:pub_2024_xxx", "fetch:sha256:…"]
}

门禁系统拿到这个结构后，不信任其中任何字段，而是用 publish_id 去发布系统查回执、用 target 去独立抓取、自行计算哈希再与 expected_sha256 比对。结构化 claim 的价值在于把“核对什么”显式化，从而让验收从“读一段话判断真假”变成“跑一组断言”。

4.4 幂等性与可重放：证据链的工程底座

证据链要可复现，底层动作必须幂等。若一次发布动作重复执行会产生不同结果（例如追加而非覆盖、生成新版本号），那么“重放取证”就失去意义。工程上应做到：发布接口接受幂等键（idempotency key），相同键的重复调用返回同一 publish_id；内容写入采用“计算哈希—比对—条件写入”的模式，避免无意义变更。这部分与分布式系统中的幂等设计完全一致，可直接复用成熟实践。

五、验收门禁：可执行的判定规则与操作步骤

5.1 门禁的判定逻辑

门禁系统是一个独立服务，输入是结构化 claim 与证据引用，输出是放行或阻断。其判定逻辑应遵循“默认拒绝、逐项满足”的原则，而不是“默认通过、发现异常才拒绝”。后者在实践中极易因为证据缺失而被跳过。

5.2 落地步骤：从零到可运行门禁

以下步骤按依赖顺序排列，可在一次迭代内完成最小可用版本。

步骤一：盘点动作面。列出 Agent 可执行的所有写操作，按“是否影响外部可见状态”分类。只有影响外部状态的动作才需要完整证据链，其余可降级为日志审计。这一步决定投入产出比。

步骤二：收口写通道。把 Agent 的文件写入、HTTP 调用、数据库更新统一收口到受控接口，接口内部硬编码目标作用域。Agent 侧不再持有直接写权限。这是最重要也最容易被跳过的一步。

步骤三：定义 claim schema。为每类动作定义结构化 claim 字段，明确哪些字段是 Agent 必须提供的、哪些是门禁自行获取的。原则是：Agent 提供的字段只用于“定位”，不用于“证明”。

步骤四：实现独立取证器。取证器运行在 Agent 之外，具备只读权限，负责抓取线上状态、计算哈希、查询回执。取证器应可被单独触发，便于排障。

步骤五：实现门禁判定。按 5.1 的表格实现断言，默认拒绝。门禁输出结构化结果，包含每个检查项的通过/失败与原因码，便于 Agent 侧做有限重试。

步骤六：接入重试与升级。失败时允许 Agent 有限次重试（例如 2 次），超过阈值升级为人工复核。重试必须携带新的幂等键，避免重复副作用。

步骤七：埋点与度量。记录每次门禁的通过率、失败原因分布、平均取证耗时。这些指标是后续优化的依据，也是发现“Agent 系统性写错路径”这类问题的早期信号。

本文评述：这七步里，步骤二和步骤四承担了绝大部分风险消减，其余步骤是工程完备性。很多团队把精力花在“让 Agent 更谨慎地自检”上，方向恰好相反——自检越充分，声明越自信，反而越难被人工发现异常。把自检换成他检，才是正解。

5.3 一个最小可用的门禁伪代码

def gate(claim):
    if claim.target not in ALLOWED_TARGETS:
        return DENY("target_out_of_scope")
    receipt = publish_system.lookup(claim.publish_id)
    if not receipt or not verify_signature(receipt):
        return DENY("receipt_invalid")
    live = fetch_independent(claim.target)          # 独立通道
    if sha256(live.body) != claim.expected_sha256:
        return DENY("content_mismatch")
    if now() - receipt.time > FRESHNESS_WINDOW:
        return RETRY("stale_evidence")
    return ALLOW(receipt.version)

这段代码的关键不在逻辑复杂度，而在于它完全不读取 Agent 的自然语言输出。Agent 说什么都不影响判定，它只影响 claim 里那几个用于定位的字段。这就是三层分离在代码层面的体现。

六、关键数据与案例：公开研究结论与模拟实验

6.1 公开研究中与“自报状态失真”相关的证据

虽然“Agent 声称完成但实际未完成”这一具体现象缺少专门的大规模基准，但若干相邻研究方向提供了可引用的间接证据。需要说明的是，以下结论均来自公开论文，本文只做归纳与评述，不复述原文。

第一，工具使用类基准普遍报告“调用准确率”与“任务完成率”之间存在显著差距。以 ToolBench、API-Bank、ToolAlpaca 等为代表的工作显示，模型在选择正确工具、生成合法参数上表现较好，但在多步任务中达成最终业务目标的比例明显下降。这一差距正是“工具成功 ≠ 业务成功”的量化体现。

第二，关于模型自我评估的研究发现，模型对自身输出的置信度校准较差。相关校准研究（如对 LLM 置信度校准的系统性评估）表明，模型自报的“我很确定”与实际正确率之间相关性有限，且在分布外输入上进一步恶化。这意味着即便 Agent 用“高置信度”措辞表达完成，也不能作为验收信号。

第三，Agent 评测框架（如 AgentBench、WebArena、SWE-bench 等）在设计上普遍采用外部环境状态比对作为成功判据，而非模型自述。这本身就是学界对“自我声明不可信”的默认共识——只是这一共识尚未被广泛迁移到生产工程实践中。

本文评述：这些研究各自解决不同问题，但指向同一个工程结论：验收信号必须来自环境，不能来自模型。把学术界的评测设计原则产品化为运行时门禁，是当前落地缺口最大的环节。

6.2 模拟实验：自证校验与外部取证的检出率对比

为量化三层分离的收益，本文设计一个可复现的模拟实验（以下数据为模拟数据，用于说明机制，不代表任何真实系统测量）。实验构造 1000 个“更新 sitemap”任务，其中 30% 注入路径错位故障（写入临时目录而非线上），其余正常。对比三种验收策略的检出表现。

模拟结果的含义很直接：前两种策略在路径错位故障上的检出率恒为零，因为它们的信息通道与故障通道完全重合。第三种策略的检出率接近 100%，代价是一次额外的网络往返与一次回执查询。这个代价相对于一次线上事故的修复成本，几乎可以忽略。

需要强调边界条件：外部取证并非万能。若故障表现为“线上内容正确但索引侧未更新”，则第 4 步的抓取会通过，需要第 5、6 步的传播验证才能覆盖。这也是为什么证据链要分层设计，而不是只做一次抓取。

6.3 一个真实工程模式的映射：不可变基础设施与制品签名

把视角拉远，本文主线在软件工程史上并不孤立。不可变基础设施（immutable infrastructure）要求部署产物一经构建即不可修改，任何变更都产生新版本；制品签名（artifact signing）要求发布物携带可验证的来源证明。这两者的共同点是：把“我发布了什么”从操作者的叙述中剥离出来，交给制品本身与签名机制。

Agent 的验收问题，本质上是把“操作者”从人换成了模型，但验收原则不变。本文评述：与其说这是 AI 带来的新问题，不如说是传统审计原则在新型执行主体上的重新应用。认识到这一点，可以避免大量重复造轮子——现有的 CI/CD 门禁、制品仓库、签名验证体系，稍加改造即可复用。

七、对比与局限：方案谱系、成本与失效边界

7.1 方案谱系对比

业界应对“Agent 声明不可信”的思路大致可分为四类，各有适用边界。下表做横向对比。

本文评述：这四类不是互斥关系，而是分层关系。提示词约束与多模型交叉可以作为“声明层”的辅助手段，降低无效 claim 的数量；外部取证与门禁是“验收层”的必需组件；形式化规约在关键路径上做补充。把它们混为一谈，是很多方案讨论失焦的原因。

7.2 成本结构与工程权衡

外部取证的主要成本有三项：网络往返延迟、独立凭据的维护、门禁系统的运维。前两项可通过缓存与凭据托管降低，第三项是一次性投入。真正的权衡在于“取证粒度”：对每个动作都做完整取证，成本会线性上升；只对高风险动作取证，则需要先做动作分级。

本文建议的分级原则是：按“不可逆性 × 外部可见性”二维分级。不可逆且外部可见的动作（发布、删除、支付）必须完整取证；可逆或仅内部可见的动作（草稿写入、临时计算）可降级为日志审计。这一分级能显著压缩成本，同时不牺牲关键路径的可靠性。

7.3 失效边界：三层分离在什么情况下不够用

必须诚实指出局限。第一，当“正确结果”本身难以形式化时（例如“让文案更有感染力”），外部取证无法给出布尔判定，只能退化为人工评审或统计指标。第二，当取证通道本身被污染时（例如独立客户端与 Agent 共享同一代理配置），独立性假设被破坏，检出率会下降。第三，当故障具有长延迟时（例如搜索引擎索引更新），即时门禁无法覆盖，需要异步复核机制。第四，取证器自身也可能有 bug，因此门禁系统需要自身的测试与监控，不能假设它永远正确。

这些边界不否定三层分离的价值，而是界定了它的适用范围。工程上应把“门禁覆盖不到的部分”显式标注为“待人工复核”，而不是默认通过。默认通过是事故的温床。

八、结论与展望

回到开头那个场景。Agent 说“已更新 sitemap.xml”，这句话本身没有错——在它的观测范围内，确实有一个同名文件被更新了。错的是我们把这个观测当成了对线上状态的证明。本文的主线可以压缩成一句话：声明是意图的表达，证据是环境的投影，验收是独立的判定，三者不能合并。

在工程上，这条主线对应三个可立即执行的动作：收口写通道，让 Agent 无法把目标指向错误位置；建立独立取证器，让证据来自 Agent 之外；实现默认拒绝的门禁，让验收结论由规则而非叙述产生。这三件事的投入可控，收益是消除一整类“看起来完成了”的隐性故障。

展望未来，有三个方向值得关注。其一是证据链的标准化：类似制品签名的 Agent 动作回执格式，若能在工具协议层统一，将大幅降低集成成本。其二是评测与运行的统一：学术基准中“环境状态比对”的判据，有望产品化为运行时组件，形成评测—部署—监控的闭环。其三是面向不确定性的验收：对于无法布尔判定的任务，如何设计统计意义上的验收协议（采样、置信区间、人工抽检比例），目前仍是开放问题。

最后需要强调，本文不主张“不信任 Agent”，而主张“不把信任建立在 Agent 的自述上”。信任应当建立在可复现、可追溯、可审计的证据之上。这不是对模型的苛责，而是任何自动化系统走向生产化的必经之路——人类操作员时代如此，Agent 时代亦然。

主要参考文献