Agent 生成了一份“新客转化下降”的报告，任务还没有结束。业务负责人要知道结论能否支持决策，分析师要复算关键数字，运营团队可能要创建排查工单。三类接收者需要不同产物，也拥有不同数据权限。
交付完成的标准，不是模型输出了最后一个句号，而是接收者能理解、核验并在授权范围内使用成果。建议、批准、提交、确认生效和业务效果必须分开记录。
这条链的关键是两个分离：报告状态与动作状态分离，执行成功与业务有效分离。
按接收者定义“完成”
| 接收者 | 主要产物 | 完成条件 |
|---|---|---|
| 业务负责人 | 结论、证据、限制、风险和待决策事项 | 能区分事实、假设与建议，知道由谁做决定 |
| 分析人员 | 结果表、方法、查询/代码、数据与语义版本 | 能复核关键数字，不能复算的限制已说明 |
| 业务系统 | 结构化动作草稿、审批、执行与回读记录 | 目标系统状态已确认，部分失败和未知未被隐藏 |
同一分析可能需要多个可见范围不同的版本。生成者能读取明细，不代表所有报告接收者也能下载。交付前应按接收身份再检查数据范围。
把声明和证据绑在一起
报告里的每个重要事实声明都应指向结果表、查询/代码、数据快照、语义版本和验证记录。一个最小输出契约可以这样表达：
{
"task_id": "conversion-review-demo",
"report_version": 1,
"status": "partial",
"claims": [{
"kind": "observation",
"text": "已覆盖渠道中观察到转化下降",
"evidence_refs": ["result/channel-comparison"]
}],
"semantic_ref": "conversion/v3",
"data_snapshot_ref": "snapshot/demo",
"limitations": ["地区分支未完成，尚无因果证据"],
"artifact_refs": ["report/v1", "table/v1"],
"action": {"state": "draft", "type": "create_investigation_ticket"}
}
partial 不能在页面标题里被润色成“已找到全部原因”。动作仍是草稿，也不能对外声称工单已经创建。
图表和文件也要经过验证
表格应展示单位、时间、口径、分子分母、分页和截断。图表不能把缺失值画成零，也不能用截断坐标轴夸大变化。正文数字和图形最好来自同一结果对象，避免复制粘贴后漂移。
报告把关键不确定性放在结论附近，而不是埋在附录。Notebook 和应用要给出环境、输入版本、权限和成本提示，打开页面不应自动触发昂贵或有副作用的操作。
W3C 复杂图像无障碍指南建议为图表提供简短替代说明和传达核心信息的详细文本。对 Data Agent，这也能迫使系统用语言准确陈述图表到底证明了什么。
可复现不是把原始数据都打包
证据包可以把“数据快照—查询执行—结果表—报告声明”连接起来。W3C PROV 概览提供实体、活动和参与主体的溯源概念；实现时不必一开始完整采用标准，但关系要能查询。
复现至少分三层：能找到方法和来源，能在相同环境重跑，能在约定容差内得到等价结果。动态数据、过期依赖和外部服务会限制后两层，应明确标记。复制整份敏感原始数据并不是可复现的必要条件。
从建议到动作是一条独立流程
- 形成草稿：写清动作类型、目标、参数、依据和潜在影响，默认无副作用。
- 预检：检查身份、接收者、数据分级、版本、预算和预计变化。
- 授权：有权人员或策略批准具体参数与有效期，实质变化后重审。
- 提交：通过行动网关执行，使用稳定逻辑操作 ID 和下游支持的幂等机制。
- 回读：查询目标系统，区分“请求已接受”和“最终生效”。
- 恢复：分别处理部分成功、状态未知和不可逆动作。
Amazon Builders’ Library 关于幂等 API 的文章解释了客户端请求标识和安全重试。超时后应先按操作 ID 查询，不能直接重复提交。
案例：从渠道下降到排查工单
报告确认在已覆盖渠道中存在转化下降，并附结果表。落地页改版可能相关，但还没有因果证据，因此只能列为假设。Agent 生成排查工单草稿，包含现象、来源、缺口和建议核查项。
批准后，行动网关创建工单并回读 ID 与状态。如果调用超时，先查询该逻辑操作是否已经生效。创建工单不等于问题解决，更不等于用户授权调整预算。
反馈也需要治理
采纳、修改、分享、导出、动作成功和业务结果是不同信号。点赞反映体验，不是正确性认证；口径修改需要语义负责人确认，事实错误才进入回归集。涉及敏感数据的反馈样本需要最小化和权限控制。
可衡量：关键声明的证据支持率、目标用户打开或导出成功率、在约定条件下的复算成功率、获批动作的回读确认率、重复生效和未知状态数量。业务指标改善不能直接归因于 Agent，除非有明确基线与比较设计。
一个稳妥的落地顺序是：先交付可核验的只读成果，再建立模板化报告与反馈，最后才开放受控动作。最后一层的语言润色不能替前面任何一层消除未知；好的交付会让限制、责任和下一步同结论一样清楚。