两个 Agent 读取同一条记录，各自完成了合理的修改。编辑检查时，两份提案单独看都没有明显问题；但其中一份已经合并，另一份还基于更早的内容。
此时要核对的不只是修改是否合理，还包括它针对的是哪个版本。审核回答“这项变化能不能接受”，版本检查回答“这份提案现在还能不能按原样进入正式记录”。共享业务表需要同时处理两件事。
读到的版本，是提案的一部分
Busabase 用 ChangeRequest保留变更与提交历史。合并推进记录指针，让接受后的内容成为当前正式记录。一个提案在等待期间，当前记录仍可能被其他获准作者更新。
因此，Agent 读取记录时应保留该次读取的版本。当前记录修改接口支持 baseCommitId，用于表达更新基于哪个提交；实际接入时应以实时 OpenAPI为准。不要只保留记录 ID，却丢掉生成修改所依赖的内容。
这不要求读者记住提交编号。审核界面和接入代码需要能回答：原来是什么，本次想改什么，现在又是什么。只显示拟写入的最终值，会让过期假设不容易被发现。
同字段冲突与不同字段更新分开判断
如果两个提案都修改同一字段，需要判断哪一个值适用，还是需要结合新的事实重新提出修改。后来提交的值不天然更正确；获得批准的提案也可能已经过时。出现冲突时，回到来源与业务责任人，不用提交时间替代判断。
如果两个提案修改不同字段，风险通常更局部，但仍需检查字段之间是否有关联。摘要与正文、阶段与下一步动作，分属不同字段，却可能依赖同一个判断。结构上互不重叠，不代表语义上可以无条件拼接。
客户端应只提交本次需要修改的字段增量。把读取时的整条记录原样带回，会扩大影响范围，也更容易携带旧值。字段增量减少无关修改；它本身并不保证跨字段语义一致。
给共享表建立一条可恢复的更新链
可以在 Busabase 中保留原有业务 Base，用 Doc 写清字段责任和冲突处理规则，用 Skill 保存 Agent 每次更新前要走的步骤。不要为不同 Agent 各建一份互相覆盖的“正式表”。
一条最小更新链是：读取当前记录与版本；核来源；只提出需要的字段；提交带基线的 ChangeRequest；遇到变化时重新对照；合并后回读正式记录。对必须由人接受的内容，再配合合适的API key 权限与显式审核参数。持有 write 的写入方可能立即合并，不能假定每次都会停在人工审核。
当前记录修改请求的形状可以是下面这样。占位值由刚刚读取的真实记录与提交填入，不是可直接运行的实验结果：
{
"operation": "update",
"baseCommitId": "<刚读取的 headCommitId>",
"fields": {
"<实际字段 slug>": "<本次拟更新的值>"
},
"autoMerge": false,
"message": "说明修改及其依据"
}
请求发往 /api/v1/records/{recordId}/change-requests。提交前核当前接口与字段类型，提交后读返回状态。需要时再检查原提案和当前记录；不要承诺系统会自动替人解决语义冲突或跨系统事务。
超时后先恢复原提案
网络超时只说明调用方没有拿到确定结果，不能证明服务器没有保存变化。此时再次创建相同提案，可能得到两个待审版本或重复动作。
先使用已有提案标识、返回记录或业务稳定键，核原 ChangeRequest 与正式记录。如果原变更已经合并，就从结果回读继续；如果还在待审，就恢复同一提案；如果明确没有创建成功，才按原意图重试。接入支持幂等键的创建接口时，保存并复用原键，而非每次生成一个新键。
这部分需要由客户端保存运行上下文。Busabase 的提交与审计记录让恢复有可查对象，但调用方仍需把“请求发出”“结果未知”“已确认合并”分开处理。
合并后，回读你真正关心的字段
合并返回成功后，读取正式记录，确认本次目标字段与接受的值一致，并核对没有请求修改的重要字段仍然正确。若后续又有新修改，保留本次接受的提交与当前版本的区别，避免把正常后续变化误认为首次写入失败。
可以给 Agent 一条更新约定：
读取指定记录和当前版本，只提议本次必要的字段修改。若版本或来源变化，展示原值、拟改值与当前值，请相关负责人判断。超时先恢复原提案，合并后回读结果；不要重建记录或把批准写成已完成合并。
能否让两个 Agent 同时处理同一张表？
可以按职责划分记录和字段，同时保留版本检查、最小增量与恢复信息。对高度关联的字段或同一条业务决策，明确一个接受责任人比让多个作者竞速提交更容易管理。具体分工是团队流程设计，不是数据表自动理解的业务规则。
审核通过后还需要再审一遍吗？
基线没有变化时，重点是正常合并与结果回读。基线变化影响了原判断时，才需要重新核对相应差异和依据；不要把所有更新都变成没有范围的重复审核。
可信写入需要来源和责任，持续协作还需要知道哪次修改基于什么。先选一张共享业务表，把读取基线、字段责任、冲突处理和恢复方式写清，再扩展多个 Agent 的并行执行。