运行结果与交付记录，承担不同责任
ZooWork 工作空间承接执行文件与任务输出；交付记录保存推荐、来源日期、已接受范围和责任人。run ID 用于追溯，业务结论另设状态：任务运行结束时，证据问题仍可能未解决。
执行上下文
工作文件、指令和临时观测留在当前任务的执行环境。
证据引用
为具体主张保留来源、观测时间和适用范围，便于复核。
团队正式记录
以当前正式记录为入口，将审定值和未决问题交给下一任务。
运行结束，不等于交付结论已接受
虚构交付中，一次研究运行推荐了供应商，但依据已经过期。候选、来源日期和待核项应作为提案保存，负责人只接受核实的范围。下一次运行读取这条记录，不从上次任务 completed 状态推断事实已获认可。
虚构示例，用于说明记录结构，不是真实客户结果或实测。
提案记录示例
| 字段 | 示例值 | 证据／决定 |
|---|---|---|
| run_result | supplier recommendation | proposal |
| source_date | older than current contract | stale |
| review_decision | request current contract | not accepted |
| next_run | read record; do not infer from completed | required |
- 01运行结果：推荐提案
- 02来源新鲜度：待核
- 03审核：只接受已验证范围
- 04下次运行：当前记录与证据
推荐交接，要带来源检查
供应商示例中，保留原推荐和过期来源，针对要交付的地区与服务补充当前依据。负责人可以接受有证据的字段，把价格或覆盖范围保持未决。下一次运行应先读取这个有范围的决定，再扩展推荐。
下一位 Agent 应读到什么
建议记录字段
delivery_id、run_id、source_url、source_date、scope、reviewer、accepted_record、head
可用 Agent 的 shell 按文档走 Skill/CLI，或由后端持有凭据、执行 application-executed custom tool。不要把密钥塞进无认证 MCP URL。新 sandbox 可能需要重新登录：不能把 /workspace 的持久化推断成 home 下 CLI 凭据必然保留。恢复交付时先核身份和范围。
来源＋观测时间
链接具体文件、行号、commit 或 URL，记录实际检查时间。
适用范围＋接受状态
写清适用环境或交付对象，缺少依据的字段保持未决。
责任人＋下一项检查
指定谁维护结论，以及出现什么证据时需要重新核验。
从发现到正式记录
- 01读取已有记录，核对 Space、Base 和 head。
- 02只提议有证据的字段，保留来源和未决问题。
- 03需要先审后写时使用 changeRequest；write 是更广授权，不是强制人审门槛。
- 04经授权审核合并后回读正式记录；下一任务带上版本和未决问题。
复用交付前，重新确认身份和范围
通过支持认证的 CLI 或后端执行工具访问，再确认该身份可用的 Space 与 Base。不要假定新 sandbox 自动继承凭据。更新合并后重新获取正式记录，把可回读的记录引用写进交接，后续运行才能找到当前决定。
常见问题
为什么不直接把 Busabase URL 填进 ZooWork MCP？
ZooWork 文档要求公开无认证 MCP 端点，Busabase Cloud 则需要认证。使用文档支持的 shell Skill/CLI 或后端持有凭据的自定义工具；未来改变设计前，重新核对厂商认证能力。
会替代原生记忆吗？
不会。原生指令与会话记忆继续服务执行；需要跨任务共享的审定事实及来源保存在这里，使用时读取最新版本。
多人同时更新怎么办？
提案前读取当前 head；版本变化时比较中间改动，修订提案，不用旧证据覆盖新结论。