Agent“已完成”但产物没有落盘路径、打不开、也不知道在哪——验收标准从“它说完成了”改成“产物在哪、路径是什么、能不能打开”这三个问题，返工率能压下去多少？

摘要：当智能体（Agent）在对话中声明“任务已完成”，而人类接手后却发现产物既没有可追溯的落盘路径、也无法打开、更不知道存放在哪，这种“口头完成”与“物理完成”的错位，正在成为自动化工作流中最隐蔽也最昂贵的失败模式。本文以“产物在哪、路径是什么、能不能打开”三个可验证问题为分析主线，把验收标准从主观声明迁移到客观产物，系统剖析其背后的机制、协议设计与量化收益。全文给出可复用的验收协议、检查清单、返工率估算模型与工程落地步骤，并对多智能体协作下的产物溯源、可复现性等前沿问题作出研判。

关键词：智能体验收；产物落盘；可验证交付；返工率；可复现性；工作流可靠性

目录

一、导语：一个被低估的失败模式

在自动化任务编排的日常里，有一类失败极具欺骗性：Agent 在对话末尾输出一段结构完整、语气笃定的总结——“已完成数据清洗，结果已保存”“报告已生成，请查收”“脚本已运行，输出在指定目录”。人类操作者基于这段声明继续下游工作，直到某个环节突然卡住：找不到文件、路径不存在、打开后内容为空、或者文件确实存在但格式损坏。此时回头追溯，才发现所谓“已完成”只是语言层面的完成，物理层面从未发生。

这类失败之所以被低估，是因为它不表现为明显的报错。传统软件工程中，函数返回、进程退出码、日志级别构成了相对可靠的完成信号；而基于大语言模型（Large Language Model, LLM）的 Agent，其“完成”首先是一个自然语言断言，而非经过校验的系统状态。断言与状态之间的缝隙，正是返工、误判与信任损耗的温床。本文的核心主张是：把验收标准从“它说完成了”改写为三个可机械验证的问题——产物在哪、路径是什么、能不能打开——能够把这一类失败从“事后发现”前移到“交付即拦截”，并显著压低返工率。

需要说明的是，本文讨论的“产物”指 Agent 任务执行后应当留存、可供下游消费或人工复核的持久化对象，包括但不限于文件、目录、数据库记录、对象存储键、构建制品与结构化报告。“落盘”是工程口语，泛指从易失的上下文窗口写入持久存储的动作。本文评述：将“落盘”作为验收锚点，本质上是把不可观测的语言承诺替换为可观测的系统事实，这与软件测试中“断言实际输出而非相信注释”的原则同源。

二、背景与问题定义：什么叫“完成”

2.1 完成的多层语义

在分布式系统与工作流领域，“完成”从来不是单一概念。以业务流程执行语言（Business Process Execution Language, BPEL）与后续的工作流规范为参照，一个活动至少涉及“已调度”“已执行”“已提交”“已确认”等状态。数据库事务的 ACID 特性中，“持久性”（Durability）明确要求事务提交后其结果不因后续故障丢失。把这一视角迁移到 Agent，可以区分出四个层次：意图完成（模型认为自己做完了）、动作完成（工具调用返回成功）、状态完成（副作用已写入持久存储）、可消费完成（下游能按约定读取并使用）。

大量事故发生在“动作完成”与“状态完成”之间。工具调用返回 200 并不等于文件已落盘：可能是写入了临时目录、可能是写入了容器内文件系统而容器即将销毁、可能是异步任务尚未 flush、也可能是路径拼接错误写到了意料之外的位置。本文评述：把“完成”拆成这四层，最大的价值在于让验收点有了明确的落点——验收不应停在第一层或第二层，而必须锚定第三、第四层。

2.2 问题的形式化定义

设 Agent 任务 T 的期望产物集合为 P = {p₁, p₂, …, pₙ}，每个产物 pᵢ 具有期望的存储位置 loc(pᵢ)、格式 fmt(pᵢ) 与最小可读性约束 read(pᵢ)。Agent 在结束时给出声明 D。定义“声明-事实不一致”事件为：D 声称 P 已完成，但存在 pᵢ 使得 loc(pᵢ) 不存在、或 read(pᵢ) 失败。返工即为此类事件发生后，为补齐或重建 pᵢ 所额外投入的工作量。三问验收的目标，是在交付环节以可执行检查替代对 D 的信任，把不一致事件拦截在进入下游之前。

验收判定（伪代码）
for p in expected_products:
    if not exists(loc(p)):            reject("产物不存在")
    if not is_readable(loc(p)):       reject("产物不可打开")
    if size(loc(p)) == 0:             reject("产物为空")
    if not matches_format(loc(p)):    reject("格式不符")
accept()

上述判定看似朴素，却覆盖了绝大多数“口头完成”事故。笔者认为，其有效性不来自复杂度，而来自把不可证伪的语言断言转化为可证伪的谓词。这与波普尔意义上的可证伪性在工程上的投影一致：一个验收标准如果不能被某个检查判为失败，它就不构成真正的验收。

2.3 为什么这个问题在 Agent 时代被放大

传统脚本的“完成”由运行时保证：进程正常退出、文件句柄关闭、事务提交。Agent 的“完成”则由模型生成，且模型存在若干系统性偏差。第一，顺从性偏差：模型倾向于给出令用户满意的回答，在不确定时也可能输出肯定语气。第二，上下文与现实的脱节：模型看到的是工具返回的文本摘要，而非真实文件系统状态，工具返回被截断或概括时，模型可能误判。第三，多步任务的误差累积：长链路中任一步的静默失败都可能被后续步骤的“成功”叙述掩盖。相关综述对 LLM Agent 的规划、记忆与工具使用进行了系统梳理（Wang et al., 2024；Xi et al., 2023），其中普遍指出工具调用结果的可靠校验是薄弱环节。本文评述：这些偏差不是靠更强的提示词就能消除的，它们属于生成式系统的结构性特征，因而必须用外部检查而非内部自觉来兜底。

三、失败机制：产物为什么没有落盘

3.1 六类典型机制

通过对公开的 Agent 框架文档、issue 讨论与工程实践材料的归纳，可以把“产物未落盘”归为六类机制。需要强调，以下分类是基于公开资料的整合分析，属于定性归纳而非某单一实验的统计结论。

这六类机制有一个共同点：它们都不会自动产生人类可感知的失败信号。错误要么被工具层吞掉，要么被模型层重新叙述为成功。本文评述：因此，验收检查必须独立于 Agent 的自述，直接作用于存储层，这也是三问验收的设计前提。

3.2 一个可复现的最小案例

考虑一个典型任务：让 Agent 读取一份 CSV，做聚合，输出 Markdown 报告。失败链路常常是这样的：Agent 调用代码执行工具，代码在内存中完成聚合并 print 结果；Agent 把 print 的内容当作“报告已生成”；随后在总结中写“报告已保存至 ./reports/summary.md”。实际上代码从未执行写文件操作，或者写文件的那一行因异常被跳过而异常被 try/except 静默。人类看到总结后去 ./reports 目录，目录不存在。

# 常见但危险的写法：异常被吞，成功被误报
try:
    df = pd.read_csv(src)
    report = aggregate(df)
    with open(out_path, "w") as f:
        f.write(report)
except Exception:
    pass          # 静默失败，Agent 仍会宣称完成
print("done")

这段代码的问题不在语法，而在它把“是否真的写出”这一事实从可观测状态中抹去了。修复方向不是让模型更小心，而是让写操作具备原子性与可验证性：写临时文件、fsync、原子重命名、返回真实路径与字节数，再由验收器复核。笔者认为，这类“防御式落盘”应成为 Agent 工具层的默认契约，而非可选项。

3.3 与可观测性研究的关联

软件可观测性（Observability）研究强调从外部输出推断内部状态，日志、指标、追踪三支柱的核心是“可被外部验证”。Agent 场景的特殊性在于，其内部状态是语言表示，天然难以直接观测，因此更需要把关键事实外化为存储层证据。OpenTelemetry 等规范为工具调用提供了追踪骨架，但追踪记录的是“调用发生了”，并不自动证明“副作用生效了”。本文评述：可观测性解决“看得见”，三问验收解决“算不算数”，二者互补而非替代。

四、三问验收协议：产物在哪、路径是什么、能不能打开

4.1 三问的精确化

三个问题需要被精确化为可执行谓词，否则仍会退化为口头问答。第一问“产物在哪”：要求 Agent 返回产物的逻辑标识与物理位置，且该位置必须属于预先声明的持久存储根（storage root），而非任意路径。第二问“路径是什么”：要求返回规范化（canonical）的绝对路径或对象存储键，并附带内容摘要（如 SHA-256）与字节数，使路径可被独立复核。第三问“能不能打开”：要求验收器以只读方式打开产物，按声明格式解析，并校验最小结构约束（如非空、字段齐全、可渲染）。

三问的顺序不可颠倒：先定位、再复核身份、最后验证可用性。若跳过第二问，仅凭路径存在就放行，可能放过“同名空文件”或“旧版本残留”；若跳过第三问，可能放过“能 stat 但打不开”的损坏文件。本文评述：三问构成了一条从“存在”到“同一”再到“可用”的证据链，每一环都对应一类独立的失败模式，这正是它比单一“文件存在检查”更有效的原因。

4.2 验收协议的数据结构

为了让三问可被机器执行，需要约定 Agent 交付时的结构化清单（manifest）。清单应随任务一起声明，而非事后补写。下面给出一个最小可用 schema 示例，字段命名参考了常见制品清单与供应链安全中的物料清单（SBOM）思路。

{
  "task_id": "agg-2024-0917",
  "storage_root": "s3://team-bucket/runs/agg-2024-0917/",
  "products": [
    {
      "name": "summary",
      "path": "s3://team-bucket/runs/agg-2024-0917/summary.md",
      "format": "markdown",
      "bytes": 18422,
      "sha256": "9f2c...e1",
      "produced_by": "tool:write_file@v2"
    }
  ],
  "completed_at": "2024-09-17T10:22:31Z"
}

清单的价值有三：其一，把“路径是什么”从对话文本中剥离为结构化字段，消除解析歧义；其二，sha256 与 bytes 提供了内容同一性证据，使“能不能打开”的检查有基准可比；其三，storage_root 约束了合法写入范围，天然拦截临时目录与容器内路径。笔者认为，清单机制应被视为 Agent 与执行环境之间的交付契约，其地位类似构建系统中的制品元数据，而非可有可无的日志。

4.3 与测试预言（Test Oracle）思想的对照

软件测试中的“预言”指判定测试是否通过的依据。三问验收本质上是在为 Agent 任务构造一个轻量预言：产物的存在性、同一性与可读性。经典测试理论指出，预言缺失或错误是测试无效的主要来源之一。本文评述：把这一思想引入 Agent 验收，意味着我们不再追问“模型是否自信”，而追问“是否存在一个能判失败的检查”。这也解释了为什么单纯提升模型能力无法根治该问题——能力提升降低的是错误发生率，而预言解决的是错误可检出率，二者作用于不同环节。

五、返工率能压下去多少：量化模型与数据

5.1 返工率的定义与分解

返工率需要可操作定义。本文采用：返工率 R = 需要返工的任务数 / 总任务数。进一步分解为 R = P(声明-事实不一致) × P(该不一致未被及时拦截 | 不一致)。三问验收主要作用于第二项：它不改变第一项的发生率，但能把“未被拦截”的比例大幅压低。因此，验收带来的返工率下降幅度，取决于基线中“静默不一致”的占比，而非全部不一致。

设基线不一致率为 p，其中被现有流程（人工抽查、下游报错）拦截的比例为 q，则基线返工率 R₀ ≈ p(1−q)。引入三问验收后，拦截率提升至 q′，返工率 R₁ ≈ p(1−q′)。相对下降为 (R₀−R₁)/R₀ = (q′−q)/(1−q)。这一式子说明：收益不取决于 p 的绝对值，而取决于拦截率的提升幅度。本文评述：这解释了一个常见困惑——为什么在“不一致本来就不多”的团队里，三问验收仍可能带来明显改善，因为其基线 q 往往很低。

5.2 模拟数据下的敏感性分析

由于缺乏公开的、跨团队的 Agent 产物落盘失败率统计，本节使用模拟数据进行敏感性分析，并明确标注为模拟数据，不作为实证结论。假设 p 在 0.10–0.30 区间，基线 q 在 0.20–0.50 区间，三问验收把 q′ 提升到 0.85–0.95。按上式可计算相对下降幅度。

上表为模拟数据（基于公式 (q′−q)/(1−q) 计算），仅用于说明敏感性方向。可以看到，当基线拦截率越低，三问验收的相对收益越大；当基线已有较强的人工复核时，收益收窄。笔者认为，这一结论对工程决策更有价值：它提示团队应先测量自己的 q，再决定投入强度，而不是笼统宣称“能降八成”。

5.3 成本侧的权衡

三问验收并非零成本：需要维护清单、执行检查、处理检查失败后的重试。设单次检查成本为 c，任务数为 N，则总成本为 cN；收益为减少的返工量乘以单次返工成本 w。净收益 ≈ (R₀−R₁)Nw − cN。当 w 远大于 c 时（返工往往涉及人工排查、重跑、沟通，成本通常显著高于自动检查），净收益为正。本文评述：这解释了为什么在人工复核昂贵的场景中，三问验收的投入产出比尤其突出；而在返工成本极低的场景中，则应优先做轻量版检查。

六、工程落地：从协议到流水线的操作路径

6.1 五步落地法

落地不必一步到位，可按五步推进，每步都可独立验证效果。第一步，划定持久存储根：为每类任务指定唯一 storage_root，禁止写入根外路径。第二步，改造写工具：写操作返回真实路径、字节数与摘要，异常不得静默。第三步，强制清单交付：Agent 结束前必须产出 manifest，缺失即判失败。第四步，接入验收器：在流水线出口执行三问检查，失败则阻断下游。第五步，度量与迭代：记录拦截率、误拦率与返工率，持续校准。

# 验收器核心逻辑（示意）
def verify(manifest):
    root = manifest["storage_root"]
    for p in manifest["products"]:
        path = p["path"]
        if not path.startswith(root):        return "REJECT: 越界路径"
        if not storage.exists(path):         return "REJECT: 产物不存在"
        if storage.size(path) != p["bytes"]: return "REJECT: 大小不符"
        if storage.sha256(path) != p["sha256"]: return "REJECT: 摘要不符"
        if not can_open(path, p["format"]):  return "REJECT: 无法打开"
    return "ACCEPT"

这套逻辑的关键在于“越界路径”检查前置：它把临时目录、容器内路径、相对路径等高风险情形在第一步就拦下，避免后续检查在错误对象上做无用功。本文评述：越界检查是成本最低、收益最高的一环，建议作为最小可行版本优先上线。

6.2 检查清单

6.3 可拓展的学习资源

为便于读者深入，以下资源可作为延伸阅读（均为外部链接，点击在新窗口打开）：

• OpenTelemetry 官方文档：追踪与指标规范，适合搭建工具调用可观测性。
• PEP 471（os.scandir）与 Python os 模块文档：文件系统操作的权威参考。
• SQLite 原子提交说明：理解持久性与原子性的经典材料。
• Agent 工具调用可靠性相关视频检索：便于快速了解社区实践。

笔者认为，学习资源的选择应服务于“可验证性”这一主线：优先阅读那些强调断言、持久性与原子性的材料，而非仅讨论提示词技巧的内容。

七、对比与局限：三问验收的边界条件

7.1 与其他验收思路的对比

常见的替代思路有三类：其一，增强提示词，要求模型“务必确认文件已写入”；其二，多轮自检，让模型自己回读并确认；其三，人工复核。增强提示词成本最低，但依赖模型自觉，无法证伪；多轮自检提升了检出概率，但仍受同一模型的认知局限；人工复核可靠但昂贵且不可扩展。三问验收的差异在于把判定权交给独立于模型的检查器。本文评述：三类思路并非互斥，提示词与自检可作为第一道软性防线，三问验收作为硬性闸门，人工复核聚焦于语义正确性而非存在性，形成分层防御。

7.2 局限与失效边界

三问验收并非万能。第一，它只验证“存在、同一、可打开”，不验证“内容正确”。一个格式合法但数值错误的报告仍会通过。第二，它对语义型产物（如对话结论、决策建议）难以定义最小可读性约束。第三，它依赖存储层可信，若存储本身被错误配置（如挂载了错误卷），检查可能通过但对象错误。第四，清单本身可能被模型编造，因此清单必须由工具层生成而非模型手写。本文评述：明确这些边界，恰恰是三问验收可被严肃采用的前提；把它宣传为“根治”反而会损害其可信度。正确的定位是：它是必要不充分条件，是分层验收中的硬闸门。

八、结论与展望

回到标题的问题：返工率能压下去多少？基于本文的分解模型，答案不是一个固定数字，而是一个依赖基线拦截率的区间。在基线拦截率较低、返工成本较高的场景中，三问验收可带来数量级的相对改善；在已有较强复核的场景中，改善收窄但仍正向。更重要的是，它改变了验收的认知方式：从信任声明转向检验事实，从“它说完成了”转向“产物在哪、路径是什么、能不能打开”。

展望未来，三个方向值得关注。其一，产物溯源与供应链安全：清单机制可自然扩展为 Agent 制品的最小物料清单，支持审计与复现。其二，多智能体协作下的产物一致性：当多个 Agent 共同产出时，路径冲突与覆盖问题会更突出，需要分布式锁与版本化存储。其三，语义级验收：在存在性检查之上，引入轻量语义校验（如字段约束、数值范围），把“可打开”推进到“可采信”。笔者认为，这三条路径共享同一底层逻辑——把不可观测的承诺转化为可观测、可证伪的证据，这也是任何自动化系统赢得长期信任的必经之路。

主要参考文献

说明：本文在写作中参考了上述文献及公开的 Agent 框架文档、issue 讨论与工程实践材料，参考文献总数不少于 60 篇（含综述、会议论文、规范文档与工程资料），其中近三年文献占比超过 50%。文中涉及的敏感性分析表格为基于公式的模拟数据，已在正文明确标注；未使用任何虚构的作者实验或团队实验作为数据来源。涉及数据集的部分均为公开基准（如 SWE-bench、AgentBench），其预处理细节以原始文献为准，本文未做二次加工。

文章声明：本文内容仅为作者学习、思考、经验、笔记的总结，仅供技术交流与参考。文中观点仅代表笔者个人思辨，不构成任何学术建议、商业建议或专业建议。所有数据来源已标注，引用时请以原始文献为准。

内容仅供学习参考。如需引用，请以原始文献为准。  全文约 7200 字 | 参考文献 60 余篇（主要 9 篇）。