Artifact 与 Workspace

Artifact 是有身份和生命周期的产物

Artifact 至少有稳定 ID、类型、标题、内容或存储引用、Owner、权限、来源、敏感级别、版本、状态和 Run/Message 关联。大文件与二进制只保存受控引用、大小、MIME 与完整性，避免复制进聊天记录。状态可区分 draft、proposed、validated、accepted、published 和 archived。

Artifact 身份不能由标题或消息位置决定。用户重命名、刷新页面或开启新会话后仍能引用同一对象；复制应创建新 lineage，分支应记录共同 base version。删除还要定义软删除、外部副本和合规保留边界。

对话与产物承担不同任务

Chat 记录目标、约束、解释和决策；Workspace 呈现可编辑内容、结构、Diff、评论、预览和验证。当前选区、光标、对象与版本形成局部 Context，发送给 Agent 时以稳定引用表达，不能只说“改这里”并依赖屏幕像素。

桌面双栏允许对话与产物互相定位，窄屏应优先当前主任务并提供清晰切换，而不是把两栏缩到不可用。消息中的提案链接到 Artifact 与 Diff；Artifact 侧也能回到产生该修改的 Run、理由和证据。

Agent 修改应以可审查 Patch 表达

小型文本可用统一 Diff，结构化文档可用 JSON Patch，整文件格式变更或二进制可用全量替换。无论形式，都携带 artifact ID、base version、目标 version、修改理由和影响范围。RFC 6902定义的 test操作可表达前置条件，但业务层仍要校验权限与不变量。

提交使用 If-Match/ETag 或等价 Compare-and-Set。base 已过期时不要覆盖：读取最新版本，尝试三方合并；无法证明语义兼容则生成新提案或请求人工。Patch 应可逆时保存 inverse 或恢复点，但外部发布等副作用不能只靠内容回滚。

interface ArtifactPatch {
  artifactId: string;
  baseVersion: string;
  operations: JsonPatchOperation[];
  reason: string;
  authorRunId: string;
  idempotencyKey: string;
}

预览不是最终成功

预览回答“渲染出来像什么”，验证回答“产物满足哪些可检查约束”。代码需要编译、测试、安全扫描和必要的运行证据；文档检查结构、链接和事实；表格验证 Schema、公式、数据范围与重算一致性。验证结果成为版本化附属证据，记录工具、版本、输入、时间与状态。

Agent 不能把“页面打开了”写成“验收通过”。验证失败时保留失败输出和对应 Artifact version，允许局部修复并重跑受影响检查。若检查未执行或环境不具备，显式标为未验证，不用绿色视觉暗示成功。

人、Agent 与多人协作的冲突

冲突策略由编辑模型决定。低冲突文档可用乐观锁与三方合并；实时共同编辑可采用 Operational Transformation 或 CRDT，但它们解决并发收敛，不自动解决语义正确；高风险结构变更可使用提案分支和单一合并者。Agent 默认提交提案，不应与用户直接输入在同一缓冲区无标记竞争。

评论、接受、拒绝和部分采纳都关联 Patch 片段与版本。最终提交者是明确的人或服务角色，承担验收责任；Agent 的作者身份、模型/策略版本与 Run 保留在 lineage。合并后还要重跑验证，因为两个各自正确的修改组合后可能违反整体不变量。

版本历史支持信任与恢复

历史记录作者、Run、Prompt/Tool 安全摘要、基础版本、Patch、时间、理由和验证。用户可以比较任意版本、撤销某次可逆变更、从旧版本分支或恢复整个 Artifact；恢复创建新版本，不篡改历史。

大文件与二进制使用内容寻址、增量存储或外部对象版本，配置保留周期与删除策略。敏感 Prompt、Token 和原始 Tool 输出不为“完整审计”而无界保存；审计引用经过分类、最小化和访问控制。恢复演练要证明存储、权限和依赖资源同时可用。

评估是否真正改善任务

与纯聊天基线比较任务完成时间、修改轮数、Patch 接受率、冲突/覆盖率、恢复成功率和验证通过率。还要测试用户能否回答“Agent 改了什么、为什么改、哪些未验证、怎样撤销”，这比停留时长更接近信任与控制。

如果用户仍要在聊天中复制整段内容比对，或验证证据无法绑定到具体版本，Workspace 只是视觉分栏。分类验收应至少包含并发编辑、过期 Patch、部分采纳、验证失败、撤销与恢复演练。