把摘要、原件和审定事实分开
工具摘要帮助当前任务理解结果，结构化字段保留工具实际返回的值，图片、CSV 或资源原件则供审核人检查。三种引用放在同一条记录里，接受状态只赋给具体主张：读过摘要，不能把合同图片自动标为已核验。
执行上下文
工作文件、指令和临时观测留在当前任务的执行环境。
证据引用
为具体主张保留来源、观测时间和适用范围，便于复核。
团队正式记录
以当前正式记录为入口，将审定值和未决问题交给下一任务。
摘要写“通过”，JSON 却仍是待审
以虚构供应商资料为例：文字摘要说已通过，structuredContent 中却是 status=pending；合同图片尚未读，资源链接也未下载。不能挑一个看起来更完整的答案直接入库，应同时保留冲突值和实际读取状态。
虚构示例，用于说明记录结构，不是真实客户结果或实测。
提案记录示例
| 字段 | 示例值 | 证据／决定 |
|---|---|---|
| summary.status | approved | conflict |
| structuredContent.status | pending | unresolved |
| source_page_or_row | CSV page 1; pages 2–3 unread | incomplete |
| review_decision | request missing evidence | not accepted |
- 01摘要与 JSON 冲突
- 02合同图片未读
- 03CSV 分页未读完
- 04资源链接未下载
- 05原件无法共享
- 06有来源的已审定字段
先补齐证据，再接受供应商结论
下一任务应收到一个具体补证动作：读完剩余 CSV 分页、核对合同图片，或对照原始 JSON 解释状态冲突。每个修正值都对应页码或行号。审核人可以接受已核实字段，同时保留其他字段未决，不必给整条供应商记录盖一个笼统的“通过”。
下一位 Agent 应读到什么
建议记录字段
claim_id、raw_value、source_page_or_row、attachment_ref、evidence_status、review_decision
Busabase 不能被描述为能直接读取 kimi-file://。只有获准后，才把原件导出或上传到团队可访问的位置，保留哈希和敏感等级，再验证引用。原件缺失时结论保持未决；MCP 工具调用获准也不等于业务事实已接受。
来源＋观测时间
链接具体文件、行号、commit 或 URL，记录实际检查时间。
适用范围＋接受状态
写清适用环境或交付对象，缺少依据的字段保持未决。
责任人＋下一项检查
指定谁维护结论，以及出现什么证据时需要重新核验。
从发现到正式记录
- 01读取已有记录，核对 Space、Base 和 head。
- 02只提议有证据的字段，保留来源和未决问题。
- 03需要先审后写时使用 changeRequest；write 是更广授权，不是强制人审门槛。
- 04经授权审核合并后回读正式记录；下一任务带上版本和未决问题。
会话结束后，证据仍要能访问
复用前，从接收任务的身份实际打开共享原件。访问失效时保留原结论与历史，同时标记需要重新核证。新来源改变数值时，提案要同时带上旧来源和替代来源，说明修改哪些字段，不静默替换历史附件。
常见问题
其他 Agent 能直接读 kimi-file:// 吗？
不能默认能读。这类引用属于 Kimi 会话存储；获准后把原件转到审核人可访问的位置，保留来源和哈希，并在接收任务中验证访问。完成前，证据状态标为不可用，不把摘要当作原件。
会替代原生记忆吗？
不会。原生指令与会话记忆继续服务执行；需要跨任务共享的审定事实及来源保存在这里，使用时读取最新版本。
多人同时更新怎么办？
提案前读取当前 head；版本变化时比较中间改动，修订提案，不用旧证据覆盖新结论。