表格增加了一个状态选项，某个字段改了类型，或者原来一段自由文本变成关联。人看界面很容易理解，长期运行的Agent却可能仍按旧规则读写。
有的任务会直接报错，有的仍能提交，但把新选项解释成旧含义，或漏掉原先没有的必填内容。请求成功只能说明通过了对应校验，还需要确认任务的业务结果是否正确。
在Busabase里，先读取当前Base字段结构，再对照Agent的指令、映射与下游使用方，分开做只读核对、最小变更提案和业务验收。这样比遇错后不断重试旧任务更容易找到问题。
字段结构变化与记录值变化，检查点不同
修改一条记录的值，主要影响这条数据及其使用方；修改字段的类型、选项或关联目标，则可能改变一批任务怎样解释数据。Bases把字段、记录和视图组织在一起，字段类型决定验证、显示和差异呈现。
不要仅凭界面显示名判断接口变化。显示名、字段标识、类型、选项和关联目标是不同信息，应读取当前schema分别核对。把“名称改了，所以slug一定变了”当成前提，可能修错地方；反过来，只核名称也可能漏掉类型和语义变化。
先列出旧任务依赖了什么
从真实任务读取的Base和字段开始，记录字段标识、类型、必填要求、选项、单值或多值、关联目标，以及JSON中的结构。再查这些信息出现在哪里：Skill、任务指令、导入脚本、API映射、报表或AirApp。
可以用一个建议的“结构变更检查”Base保存变更摘要、受影响资源、负责人、依赖位置、只读核对结果、提案链接和业务验收结果。用Doc保存可复用字段解释。它们用于协调，不会自动扫描所有依赖或替你迁移代码；已有变更管理记录够用时，直接复用。
先让 Agent 解释当前数据，不立即写回
给连接到Busabase的Agent指令：“读取当前Base schema和这项任务的旧指令，列出不一致的字段、类型、选项和关联。只读现有记录，解释它们会怎样映射到目标结果；遇到未知状态或缺失字段单独报告，先不要写入。”
选择能够覆盖真实业务分支的记录进行核对，例如缺值、多个关联和新增选项。检查输出是否保留含义，而不只是能否取到值。发现旧规则把未知状态一律当默认值，就应修订映射和处理规则，避免静默写错。
能解析 JSON，不等于任务兼容
Field Types说明，JSON和YAML字段需要在提交或合并前通过解析校验。这个门槛能拦住语法错误，却不能证明键名符合下游约定、单位正确、数据来源可靠或关联目标恰当。
把检查拆成三层：格式能否解析，字段是否符合当前映射，结果是否符合业务规则。一个合法JSON仍可能缺少消费者必需的键；一个有效select值也可能被旧任务误解。需要的结构约束和业务判断应在对应脚本、Skill及验收中明确，而不是假设解析器已经替你判断。
用最小提案验证，再检查消费者
修订映射与可复用指令后，先针对明确授权的一小部分真实记录提出ChangeRequest。让审阅者看到当前值、建议值、变更原因与保留字段。只改受影响的内容，不把schema兼容性修复扩成整表重写。
合并后从正式记录回读，核对结果，再检查依赖它的报表、导出或应用。保存每个消费者的核对结果和待处理项。旧的待审提案也应按当前结构重新检查，不能因为创建时间更早就直接沿用。需要生产schema或代码变更时，按各自权限和授权流程处理。
什么时候可以恢复旧任务？
当当前schema、Agent映射、业务判断和主要消费者都已对齐，才逐步恢复对应任务。交接记录里应能看到采用的规则版本、变更范围、已验证结果和未覆盖分支。结构变化后，旧指令仍存在不等于已更新；安排后续任务读取新规则，并确认实际执行用到了它。
改字段名一定要重写所有任务吗？ 先查真实依赖，区分显示名和接口标识，再改受影响部分。一条记录通过就能恢复整批吗？ 还要覆盖真实分支和消费者。需要每次另建管理Base吗？ 不需要；关键是负责人能找到结构差异、提案与验收结果，而不是表的数量。