让 Agent 在公司的记录里移除一条商机，商机记录上的“公司”也空了。这个变化可能符合双向关联的设计，却超出了发起人对“只整理当前页面”的理解。
Busabase 的双向关联把同一组关系显示在两侧，关联本身只存一次。编辑反向列会修改另一张表中的前向字段；若前向字段只允许一个关联，把商机加到新公司还会把它从旧公司移走。
审核关联变更时，应沿着显示列找到实际写入对象。这样才能判断 Agent 到底改变了哪些业务记录，以及应由谁确认。
双向显示为什么不是两份数据？
在“商机”Base中，Company关联字段指向“公司”Base。打开关联字段设置，启用 Also show this link in {Base} 后，公司侧便能显示关联商机。两边展示同一事实，而不是各自维护一个独立列表。
Field Types说明：在公司侧添加商机会设置商机的Company，移除则清空它；单值关联会从旧公司移动。当商机归档时它会从显示中退出，恢复后再出现。仅凭列表长度变化，无法判断是关联被清除还是记录状态改变，需要回到实际记录核对。
先找到真正被修改的字段
从当前关联列进入字段设置，确认目标Base、前向字段及单值/多值设定。API或CLI使用者可检查反向字段的options.reverseOfFieldId：它指向目标Base中真正保存关联的前向字段。前向字段应指回当前Base。
审阅时把三件事写清：操作从哪条记录发起，哪些目标记录的前向关联将变化，哪些旧关联会因此消失。公司侧的一次列表编辑，不能仅用“更新公司”概括。多值字段也要区分新增、移除和完整替换，保留任务未授权改动的关系。
给 Agent 的任务要写明关系变化
可以复用公司的业务Base和商机Base，不必新建一套CRM。另用Doc记录关联规则：哪个字段存储关系、是否单值、谁负责确认归属、归档怎样处理。频繁执行时，再把已核实方法放进Skill，避免每轮靠猜列名。
指令可以是：“读取这条公司记录、当前反向关联及对应商机的Company字段。列出本次新增和移除的关系，标出会从旧公司移走的商机。先展示实际受影响的记录与字段，只针对确认范围提出ChangeRequest，保留其他关系。”
实际提交仍受连接权限与审核设置约束。聊天里说“先审核”并不能自行改变凭据能力；参阅Change Requests安排具体审阅步骤。
权限和创建限制会影响操作顺序
编辑反向列需要有权修改另一张Base；无法打开目标Base时，反向列为只读。能读取当前公司记录，并不自动证明能修改商机。遇到权限不足，应保留已读结果，请对应负责人处理，而不是另找路径绕开。
反向列目前不能在新建记录表单中填写，需要先保存记录再编辑；也不能用它过滤、排序或分组。这些限制会影响Agent的执行计划：不要把创建公司和填写反向商机列表写成必定能一步完成的指令。没有反向列的关联还可在记录详情的Linked from中查看。
合并后怎样确认没有改多？
回读受影响商机的前向字段，再看新旧两家公司的反向显示。确认新增关系存在、需要移走的旧关系已按预期变化、其他关系保持。若某条记录消失，再查是否归档或权限可见性改变，不直接重复添加。
在变更说明或业务跟踪记录里保存关联调整原因、实际涉及的记录、审核决定和回读结果。这个检查围绕真实写入范围，不意味着获得跨Base全局事务或自动回滚保证。已经改错的关系，应依据当前状态提出有依据的纠正，避免用旧列表覆盖后续有效调整。
常见问题
删掉反向列表的一项，只是隐藏吗？ 在双向关联编辑中，移除会清空对应的前向关系，不能当作个人界面整理。
把单值商机加到另一家公司，会复制吗？ 它会从旧公司移走，因为前向Company只有一个值。是否允许这样调整，应由业务归属规则决定。
为什么 Agent 能看却不能改？ 两侧Base权限和实际写入对象需要分别核对。先在Base中确认字段结构，再对一条授权范围内的关系走通提案和两侧回读，才适合扩大处理范围。