Agent 写的 JSON 格式不对，为什么变更进不了 Inbox？

是的，Busabase 会在变更进入审核队列之前先检查字段内容。 检查没通过，这次提交会被直接退回，队列里不会出现任何东西——所以你看到的「没进 Inbox」，其实是这次提交本身没成功。

为什么会这样

一条变更请求相当于一张待审工单。Busabase 的做法是：先确认这张工单上的内容可用，再把它放上桌。JSON / YAML 这类字段属于「内容必须能被解析」的类型，里面存的其实是一段文本，系统会尝试把这段文本解析成结构化数据；解析不了就不放行，也不会留下一张半成品工单。

这个判断在「提交的那一刻」就做完了，不是等到有人点批准才做。好处是坏数据不会躺在队列里等你审；代价就是 Inbox 里什么都看不到，只能从提交时返回的提示里找原因。

最常见的原因：给的是对象，不是文本

这是 JSON 字段最常翻车的地方——字段期待的是「一段 JSON 文本」：

• 直接给结构：{"config": {"a": 1}} → 会被退回
• 给一段文本：{"config": "{\"a\": 1}"} → 通过

YAML 字段同理，只是提示语不同。另外，如果你的「代码」字段语言选的也是 JSON 或 YAML，会按同一套规则检查。

怎么修、怎么重新提交

• 提交失败时会带一句说明，里面会点名是哪个字段有问题，按字段名找到它就行。
• 把那个字段的内容改成合法的 JSON／YAML 文本，重新提交同一次改动。只带改动的字段即可，不需要把整条记录重发一遍。
• 在界面里操作也一样：打开记录 → 编辑这个字段 → 保存。保存前会用同样的规则预检，中文界面会提示「请检查以下字段：xxx」。

还有一种「没进队列」，但不是出错

如果你这个账号对这张表有直接编辑权，按 Busabase 的默认设定，改动会当场生效，不会生成待审工单——这是设计如此，不是异常。判断方法很简单：看这次提交返回的是「更新后的记录」，还是「一条待评审的变更」。前者说明已经写进去了，不用再等队列。

如果变更已经在队列里、却一直合并不了

那是另一道关：合并生效时会按这张表当前的字段设置再检查一次（比如字段后来被改成了必填）。这种情况要调整的是字段设置或内容本身，重新提交同样的内容不会解决。

还有一个容易被忽略的点

检查是针对「这条记录合并之后的样子」整体做的，不只是你这次改的字段。所以如果这条记录里别的字段本来就存着一个解析不了的值，也会拦下你这次看起来毫不相关的更新——提示里点名的就是那一个字段。

如果按上面的步骤还是进不去，把提交时间、目标 Base，以及（脱敏后的）报错内容发出来，我们帮你一起定位。