Workspace 产物验收契约：别让 AI Agent 把交付留在聊天窗口

Axon AI 2026-05-24 AI 数字员工 Agents 数字员工
#AI数字员工#Workspace#Agent验收#Axon
Workspace 产物验收契约：别让 AI Agent 把交付留在聊天窗口
摘要：产物验收契约把文件路径、证据包、验收标准和拒收原因写清楚，让 AI Agent 的输出能被复查、复用和返工。

产物验收契约，是团队在运行 AI Agent 前定义“交付物应该放在哪里、满足什么标准、用哪些证据验收、什么情况必须拒收返工”的工作协议。很多 AI 办公流程看起来完成了，实际却把结果留在聊天窗口：一段摘要、一张表格截图、几句“已经处理好”。第二天要复用时，没人知道文件版本、数据来源、负责人、修改理由和最终路径，重复整理、手动核对、低效返工又回来了。

Axon 的 Agent 不应该只会回答。它应该把 Skills 调用结果、Office 文件、Markdown 中间文档、PDF 报告、图片素材和运行记录放进受控 workspace。前一篇 workspace 可靠性复盘文章 关注运行后怎么复盘；本文更前置，关注运行前怎么定义验收。没有产物验收契约，AI 数字员工很容易从“可交付工作流”退化成“聊天式临时帮忙”。

聊天文字可以解释过程，但不能替代交付物。真正可运营的 Agent 输出，必须有文件、有路径、有证据、有拒收理由。

聊天窗口不是交付地点

企业使用 AI Agent 的目的，不是让对话更热闹，而是让任务有可复用产物。研究摘要要能变成 Markdown 或 PDF；Excel 处理要能留下表格文件；邮件草稿要能说明收件人、附件和确认状态；封面素材要能进入素材目录。否则，每次运行都像一次没有归档的会议纪要。

OpenAI 的 Codex 文档 将 Codex 描述为可以读取、修改并运行代码的编码 Agent，这类产品让用户更容易理解“Agent 应该交付可检查产物”这件事。Axon 面向非研发知识工作，也需要同样的产物意识：不是 PR，而是 PDF、Word、Excel、Markdown、HTML、图片和任务记录。

验收契约的六个字段

字段 示例 验收含义
deliverablePath workspace/reports/weekly-brief.pdf 最终文件必须落在指定路径
evidencePath workspace/evidence/sources.md 支撑材料和来源能被复查
sourceSnapshot workspace/input/source-data.json 运行时输入不依赖聊天上下文
qualityRule must include source table and risk section 验收不是主观感觉
rejectionReason missing source date 拒收原因能回写给 Agent
ownerRole ops-reviewer 谁有权通过或拒收

产物路径和证据路径要分开

交付文件和证据文件不要混在一起。交付文件面向业务使用，证据文件面向复查和返工。比如一份市场简报 PDF 是交付物，网页链接、抓取时间、引用摘要和原始 Source Data 是证据包。把两者分开，能让审核人快速判断“内容能不能用”和“问题出在哪里”。

如果任务涉及 PDF、邮件和研究材料，可以参考 Research PDF Email 工作流；如果输入同时包含文件、图片、网页和邮件，可以继续看 多模态办公 Agent 资料入口。

验收轨迹不要靠记忆补全

验收人应该能从 workspace 里看到输入快照、交付文件、证据包和拒收理由，而不是靠回忆“当时 Agent 好像读过哪些文件”。轨迹完整，返工才会变成明确动作。

一个可执行的验收配置

产物验收契约可以写得很轻，但要让 Agent 和审核人都看得懂：

[acceptance]
run_id = "weekly-brief-2026-05-24"
owner_role = "ops-reviewer"
deliverable_path = "workspace/briefs/2026-05-24/weekly-brief.pdf"
evidence_path = "workspace/briefs/2026-05-24/evidence.md"
source_snapshot = "workspace/briefs/2026-05-24/source-data.json"

[[acceptance.rules]]
name = "source coverage"
must_have = ["source title", "source url", "retrieved date"]

[[acceptance.rules]]
name = "business usefulness"
must_have = ["one-page summary", "risk section", "next action list"]

[[acceptance.reject_if]]
condition = "output only exists in chat"
reason = "deliverable must be saved to workspace"

这类配置能把“感觉还不错”改成“能否通过验收”。它也能减少反复沟通：如果输出只在聊天里，直接拒收；如果缺少来源日期，回到 Agent 补证据；如果产物路径正确但内容缺风险段，再返工对应章节。

拒收规则比通过按钮更重要

很多团队只设计“确认”按钮，却没有设计“为什么拒绝”。这会导致 Agent 下一次仍然犯同样的错。拒收规则应该能转化为可执行改进：

  1. 路径错误：要求 Agent 重新保存到指定 workspace，而不是重写内容。
  2. 证据缺失：要求补充来源、时间、文件版本或截图，不急着改正文。
  3. 格式不符：要求调用 Word、PDF、Excel 或 Markdown Skill 重新生成。
  4. 风险未说明：要求补充影响范围和人工确认建议，再进入 Trust Mode。

NIST 的 AI 风险管理框架 强调风险需要被识别、管理和复盘。落到 Axon，就是让每次拒收都能变成下一轮运行的明确输入，而不是一句“再优化一下”。

和定时运行的关系

产物验收契约对定时 Agent 尤其重要。手动运行时，人还可以盯着过程；每天或每周自动运行时，团队只能依赖路径、证据、状态和拒收理由。开启自动化前，建议先看 定时 Agent 手动验收文章。只有手动验收稳定，定时才有意义。

FAQ

Q1：小任务也需要产物验收契约吗？
如果只是一次性草稿，可以很轻。但只要任务会复用、会定时运行、会交给别人查看，就应该至少写明产物路径、证据路径和拒收条件。

Q2：为什么不能把结果留在聊天窗口？
聊天窗口适合解释，不适合归档。业务交付需要文件路径、版本、来源和验收状态，否则后续复查和复用都会变成手动劳动。

Q3：Axon 的 workspace 是否等同于企业文档系统？
不是。workspace 是 Agent 运行和产物管理的受控工作区，适合保存本次任务的输入、输出和证据；正式归档仍可按团队规则进入企业文档系统。

给审核人的下一步

下次创建 Axon Agent 前，先写一份最小产物验收契约，再让 Agent 运行。不要只问“结果好不好”，而要检查文件是否在 workspace、证据是否完整、拒收原因是否能回写。下载 Axon 后，可以从周报、研究摘要或合同资料包开始试验；需要继续了解自动化边界时，阅读更多 Trust Mode、定时验收和 workspace 可靠性内容。