自动化显示执行成功，接收方却说没有看到结果。面对这类反馈，团队很容易各拿一张成功截图：记录已经保存，规则已经运行，请求也已经发出。每一张都是真的，最终要完成的事情却仍然没有落地。
一条事件从产生到成为业务结果，中间会经过不同系统和判断。前一步完成，只能解释这一步发生了什么；接收方是否接受、后续动作是否完成，需要另外的依据。测试时选中的样本，也不能替代真实事件的运行过程。
把这些环节分开看，才能知道问题应该从哪里查起。对Busabase事件与自动化而言，实用的起点是先认清触发条件，再把发送记录与接收结果接起来，让“成功”对应到具体的一步。
先检查规则是否覆盖这次变化
从空间左上角菜单打开 Webhooks。创建规则时选择事件，可以限定到一个 Base，也可以使用空间范围。当前事件文档列出四类触发条件。
| 事件 | 触发条件 |
|---|---|
| New Record | 新记录创建并合并进入 Base |
| @AI mention | 评论中有人提及 Agent |
| Changes requested | 审阅者退回修改请求 |
| Asset uploaded | 上传尚不能读取文本的文件，例如扫描件 |
New Record 的关键是“新建并合并”。不能把它当成所有记录更新的通用监听器。如果需求是既有记录某个字段变化后通知其他系统，应先核实可用机制，而不是通过反复更新旧记录等待这个事件。
用一份事件覆盖清单记录业务动作、所需事件、Base 范围和当前规则。覆盖缺口要明确留下，避免接收端排查半天，实际没有事件产生。
样例测试与真实事件分开验收
Test now 会用真实感样例立即调用规则，规则关闭时也可以使用。它适合检查地址、格式和函数逻辑；它没有证明生产记录满足触发条件，也没有证明真实事件已经走通。
先做样例检查，再用获准的真实业务操作核实触发。不要为测试随意制造正式业务记录或对外消息。需要测试数据时，先明确环境、对象和授权，并让接收端能识别这次检查。
展开规则的近期运行历史：Success 查看日志输出，Failed 查看错误。保存这次真实操作对应的记录、触发规则、时间和运行依据，再去接收端找相应请求与处理结果。文档中的运行日志是排查入口，不是无限期保存所有业务凭证的承诺。
三种动作，验收对象不同
Webhook 向指定 URL 发 HTTP POST；Notify agent 将同类请求发送到 Agent 端点；两者可配置签名 secret，由接收端验证来源。Run function 则在 Busabase 的隔离环境中执行一小段 JavaScript，读取事件并通过 fetch 调用外部服务。
选择动作时，先问谁负责后续工作。已有接收服务，就检查端点、签名校验和业务处理；让 Agent 接手，就检查 Agent 端点接收之后如何形成可追查结果；仅需短小转换或调用时，再考虑函数。不要因为规则名叫“通知”，就把业务完成标准缩成一次成功返回。
接收端需要有自己的失败处理与重复请求处理办法。不能仅凭启用规则推断恰好执行一次，也不能把 Base 合并和外部副作用视为一个不可分割的事务。
函数适合短任务，长处理交给下游
Run function 的超时设置为 100–5000ms，包含 fetch；最多允许 10 次 fetch。函数不能读取服务器文件或环境变量，向 localhost、私网和云基础设施地址的请求会被阻止。返回值只记录供参考，不会自动触发下一步。
因此，长时间处理应设计到能承接任务的服务中，函数只完成其限额内的部分。把超时、外部错误和重复投递的处理方式写进接收端约定，避免靠扩大一段小函数承担整个业务。
沿四段证据定位问题
第一段是 canonical 记录：确认新记录确实合并，且属于所选 Base。第二段是规则运行：找到对应真实事件，而不是 Test now 的样例。第三段是接收端：查看签名验证、接收请求与返回。最后一段是实际业务结果：通知是否形成、任务是否建立、目标记录是否改变。具体结果以所接服务的返回和可检查对象为准。
如果只有规则运行成功，接收端仍可能异步处理或业务失败；如果接收端没有对应请求，先核地址和投递依据。排查时只陈述已经确认的哪一段，不把“尚未找到”写成确定根因。
需要委托Agent时，可以这样描述任务
读取这条规则的事件、范围和近期日志，核对指定记录是否属于一次已合并的新建操作。把真实事件与 Test now 分开。整理已确认阶段、缺失的接收端依据和下一步检查，不重发请求、不新建记录、不修改规则。
这条指令用于有相应读取工具与权限的 Agent。没有接收端日志权限时，由负责该服务的人补齐依据，不能用口头推测替代。
什么时候该重试，什么时候该换一段排查
先核原业务变更能否产生指定事件。若只是修改已有记录，不能靠反复保存制造New Record；若规则尚未覆盖业务需要，就应明确机制缺口。Test now能检验动作配置，但不能代替真实记录新建并合并的触发依据。
如果请求已经到接收端，先查回执和业务对象再重发。接收成功与业务处理完成可能不同，超时也不能直接判定接收失败。保留源记录、规则运行和接收端对象之间的关联，下一位排查者才不会把上次已经发生的动作再做一遍。
把验收结果留在可查位置
可以复用现有运维 Base，每条记录保存源记录关系、事件类型、规则名称、检查时间、投递依据、接收回执、实际结果与未完成项；这是建议的记录设计，不是新建表就能自动采集日志。运行结果由有权限的工具或负责人写回，并保留 Busabase 的变更审计。
先选择一条现有规则，完成一次从源记录到下游结果的核对，再扩大覆盖。只有这条链路能逐段说明，团队才能判断该改规则、修接收端，还是继续等待已被接收的工作。