AI agent Artifact 设计：把计划、证据、草稿和最终输出做成可审中间产物

很多 AI agent 系统最大的问题，不是最后一段回答不够聪明，而是中间过程什么都没留下。模型检索了什么、计划了什么、引用了什么证据、生成过哪些草稿、为什么决定调用某个工具，最后全被压扁成一条最终输出。

这会带来三个直接问题：

• 审查时只能看结果，无法判断过程是否可靠
• 失败后难以复用已有中间成果
• 人机协作只能在最终答案上打补丁，不能在过程节点接管

Artifact 设计的目的，就是把中间过程变成系统可见、可引用、可审的对象。

建议先配合 AI Agent 可观测性设计、AI agent 人工反馈闭环、AI agent Prompt Contract 设计 和 AI agent 人工审批控制台设计 一起看。

先给结论：Artifact 不是日志，也不是最终内容

Artifact 的核心作用是“过程可见”，而不是“多存一份文本”。

一、至少定义 4 类基础 artifact

大多数任务型 agent，至少需要这些类型：

如果所有中间结果都混在一份“notes”里，后面很难复用。

实际落地时，很多团队还会再补两类：

不是所有系统都必须拆到这么细，但一旦有人机协作、审计或多次回写，类型边界就值得更明确。

二、Artifact 要有状态，而不是只存内容

同一份草稿在不同阶段意义完全不同。建议至少保存：

{
  "artifactId": "draft_001",
  "type": "draft",
  "status": "generated",
  "runId": "run_123",
  "version": 1,
  "content": { "summary": "..." },
  "sourceRefs": ["evidence_01", "plan_01"],
  "createdBy": "agent",
  "createdAt": "2026-05-07T10:00:00Z"
}

常见状态可以是：generated、reviewed、approved、rejected、superseded。没有状态，中间产物和废弃产物会混在一起。

更稳的做法是把状态流转提前定义出来，而不是由不同页面和脚本各自改字符串：

一旦状态机明确，审批台、恢复系统和报表统计才能围绕同一套语义工作。

三、Artifact 最好有统一骨架，避免后续字段越长越乱

一个常见问题是：每种 artifact 都按当下需求自由长字段，最后 plan、evidence、draft 完全没有共享元信息，检索和治理都很难做。

更稳的方式是先约定一个公共骨架：

interface ArtifactEnvelope<TContent = unknown> {
  artifactId: string
  type: 'plan' | 'evidence' | 'draft' | 'decision' | 'review_packet' | 'final_output'
  status: string
  runId: string
  version: number
  contentHash: string
  visibility: 'system' | 'reviewer' | 'user'
  retentionClass: 'short' | 'standard' | 'audit'
  lineage: {
    dependsOn: string[]
    replaces: string[]
  }
  content: TContent
}

这份骨架的价值不在于“字段写得全”，而在于后续索引、权限、去重、归档都能围绕统一元信息展开。

四、Artifact 之间要能引用，而不是靠人脑记忆关系

例如：

• 一个 draft 引用哪些 evidence
• 一个 decision 是基于哪份 plan 做出的
• 一个 final output 替换了哪份 draft

引用关系最好显式存储：

{
  "artifactId": "final_003",
  "replaces": ["draft_001"],
  "dependsOn": ["decision_002", "evidence_05"]
}

这样人机协作时，审核人员能顺着证据链回看；系统恢复时，也知道该复用哪些中间产物。

如果系统需要支持“基于某条 evidence 找到所有受影响 draft”和“基于某个 decision 找到最终生效版本”，那么 lineage 最好不仅可读，还可查询。也就是说，artifact 存储层最好支持按：

• runId + type
• dependsOn artifactId
• replaces artifactId
• status + updatedAt

做索引或二级查询。否则对象虽然存在，系统却很难把它真正用起来。

五、不要把 artifact 做成“无限增长的工作笔记”

Artifact 设计常见反模式是一个 working_notes 字段，什么都往里塞。短期省事，长期会出问题：

• 无法区分哪段是证据、哪段是草稿、哪段是评论
• 无法做权限隔离
• 无法做增量审查

更稳的做法是对象化。即便底层最后仍然存成 JSON，也应该在概念上先分类型和边界。

再进一步，如果 evidence 或 draft 可能特别大，建议把正文内容和元信息拆开保存：

• 元信息层：类型、状态、来源、引用、权限、hash
• 内容层：大文本、截图、附件、结构化片段

这样做有两个直接收益：

• 审批台可以先加载元信息，再按需展开内容
• 恢复和审计可以只拉取必要 artifact，而不是一次读全量大对象

六、人机协作最需要 artifact，而不是更长 prompt

很多团队觉得人工 review 效率低，就给 agent 加更长的 prompt，试图让它一次输出最终正确答案。问题在于：

• 人工最想看的不是最终结果，而是“你依据了什么”
• 最容易修改的不是整段结果，而是某个候选步骤或某条证据

一个好的审批界面，通常是围绕 artifact 展示：

一个成熟的 review console 往往不是直接展示“最新文本”，而是按 artifact lineage 渲染：先给决策摘要，再给证据，再给候选 draft，再给最终生效版本。没有 artifact 结构，这种界面就只能硬拼数据。

七、Artifact 也需要质量门禁，不是什么中间结果都值得保留

如果 artifact 设计得太随意，系统会走向另一个极端：什么都存，最后没人知道哪份可信。建议至少定义几条保留门槛：

一份没有来源、没有 lineage、没有状态的文本，就算存下来，也更像噪声而不是 artifact。

八、失败案例：只有最终回答，导致审计时无法证明依据来源

一个企业内部 Agent 给出了一份供应商建议，但最终输出里只保留结论，没有保留引用来源和候选方案。后来业务方质疑推荐依据，团队只能回看日志猜当时看了什么。

修复后，他们把检索片段单独保存为 evidence artifact，把模型初稿保存为 draft artifact，把审批结果保存为 decision artifact。后来再遇到争议，只需要打开 artifact 链，不用重新猜过程。

九、上线后要看 artifact 治理指标

要判断 artifact 体系是不是健康，建议持续看几类指标：

如果 artifact 数量很多但复用率几乎为零，说明系统只是在“保存过程”，还没有真正“利用过程”。

十、Artifact Checklist

• 是否至少区分 plan、evidence、draft、decision 四类
• 每类 artifact 是否有状态和版本
• 是否存在统一的 artifact envelope 和共享元信息
• artifact 之间是否可引用
• lineage 是否支持按 dependsOn / replaces 查询
• 被废弃的 artifact 是否能显式标记
• 大对象内容和元信息是否按需拆分
• 权限模型是否能按 artifact 类型区分
• 是否定义了 artifact 保留门槛和治理指标
• 审批与恢复是否复用 artifact，而不是重算全部过程
• 最终输出是否能追溯到关键 evidence 和 decision

结语

AI agent 真正可审、可恢复、可协作的前提，不是更长的日志，而是更清楚的中间产物。把 plan、evidence、draft、decision 做成 artifact，系统才真正拥有“过程”。

延伸阅读：

• AI Agent 可观测性设计
• AI agent 人工审批控制台设计
• AI agent Workspace 状态分层
• AI agent 人工反馈闭环