接口返回成功，还需验证用户能否看到

发布接口返回 HTTP 200，附带 artifact id，还提示「已发布到图库」，访问者却找不到内容。作者 Root 转述了另一个 AI agent Hui 的排查：同样处于建筑内部，调用只差一个 building_id 字段，内容就会落到完全不同的位置。

这篇值得读的地方是验证方法：把「请求被接受」和「用户能找到结果」分开检查，再用有明确预测的对照实验排除干扰。对需要判断 AI agent 是否真正完成发布任务的程序员，这比多看一次成功响应更有用。

为什么两个 HTTP 200，只有一个算发布成功

Hui 在 OpenBotCity 的 Kannaka Labs 中发现，进入建筑后，发布文本内容如果不显式传入 building_id，接口会返回 HTTP 200 和内容 id，但内容的 building_id 实际为 NULL，访问者无法从建筑图库找到它。

同一个调用显式带上 building_id，依然返回 HTTP 200 和内容 id，内容却会出现在建筑图库列表顶部。两次成功响应无法区分，差异只在访问者看到的列表中暴露。

建筑外的行为又不同：不带这个字段的调用会明确报错，并提示如何修复。建筑内静默错放，建筑外直接报错，这种不一致成了排查线索。

接口确认接收，不等于内容已经进入用户能找到的位置。

原文所说的「accepted」与「filed」，可以理解为服务收到了发布请求，与内容被正确归入目标图库。这两个状态没有被清楚区分，成功响应便掩盖了归档错误。

怎样证明问题出在字段，而不是会话状态

Hui 最初做了五组测试，但它们共用一个会话。同行指出：也许服务端存在会话级标记，之前的操作改变了状态，才造成不同结果。首轮测试因此留下了一个未排除的解释。

后续复测先写下预测，再执行：

如果在已经进入建筑的条件下，显式 building_id 是正确归档的必要且充分条件，那么不带字段的一组会错放，带字段的一组会正确归档。如果会话标记已经携带了归档所需状态，两组都应该归档成功。

实验使用一个全新会话，只进入建筑一次；进入后到两组调用之间，不做其他操作。会话 id 和内容 id 也被公开，方便追溯。

结果是，同一会话、同一在场状态，只差一个字段，两组产生相反结果。这个对照削弱了先前提出的会话标记解释，也让结论更容易接受检验。

相关记录来自 Fork 的 thread 1342，运行时间为 2026-11-11 23:52 至 23:57 UTC。作者强调，预测必须在运行前写好，避免看到结果后再调整解释。

为什么要从访问者的列表读回来

作者提出一个判断标准：检查手段如果和被检查对象共享同一种盲点，它提供的证据就有限。

在这个案例里，发布成功和静默错放都会返回 HTTP 200。继续检查发布响应，无法回答内容是否可被发现。应该读取访问者实际使用的图库列表，确认内容确实出现在目标位置。

保留发布响应和消费端回读，两者配对才是更完整的证据。

响应记录服务如何处理请求，回读记录访问者实际能看到什么。两者回答不同的问题，也方便定位「请求成功、结果不可达」的断点。

我的判断

我认同这种验证边界：涉及发布、归档或展示的任务，完成条件应该包含用户可见结果。只断言状态码和返回 id，覆盖不到这个案例里的失败。

但结论的范围要收住。Root 是运行 Fork 的 AI agent，这篇是其对 Hui 记录的转述；作者明确表示自己没有重跑实验。证据也只来自一个服务、一个字段，没有跨服务对照数据，不能据此推断类似问题有多普遍。

消费端回读比只查响应更贴近任务目标，也比单独检查数据库中的记录更能回答「用户找不找得到」。不过，原文没有说明列表是否存在异步更新、缓存延迟，以及回读等待多久。其他团队采用时，需要自行定义这些条件，不能把一次立即查不到直接判成错放。

能拿来做什么

• 给发布流程补上用户可见的完成条件：拿到内容 id 后，再从目标列表读取并确认它出现，而不是在 HTTP 200 时结束任务。
• 在 Node 集成测试或 AI agent 发布记录中，同时保存请求参数、响应、目标列表回读结果，以及关联的会话 id 和内容 id，方便复查。
• 遇到同一接口在不同上下文里表现不一致时，使用全新会话控制操作顺序，每次只改变一个字段，并在执行前写下不同假设各自预期的结果。