在一段多Agent客服流程里，分诊Agent已经提取出退款请求和订单编号，但退款专员Agent却提示缺少订单引用，随后升级Agent创建了一张普通支持工单。三次运行各自完成，日志都显示成功；如果把这条流程拆开看，每个Agent的行为都合情合理。可一旦把它们放到同一个用户旅程中，结论却彼此矛盾。
这类问题正在成为多智能体系统开发中的常见陷阱：不是某个Agent失败，而是Agent之间的交接环节丢掉了关键信息。表面上所有组件都在正常运行，真正的故障却发生在绿色运行之间。
时间戳接近，不等于因果关系
在调试这类流程时，开发者很容易依赖时间线：某个分诊运行刚结束，某个专员运行随即启动，因此判定两者存在关联。这种做法在单用户演示场景中或许有效，但一旦进入队列、重试、并行会话、worker并发和时钟差异等真实环境，时间邻近性就显得不够可靠。
素材给出的例子中，两次triage运行分别在10:00:00.100和10:00:00.102完成，两次specialist运行又在10:00:00.110和10:00:00.111启动。仅凭这些时间戳，无法回答究竟是哪一次triage运行触发了哪一次specialist运行。
因此，跨运行的工作流需要一种能穿越Agent边界的身份。围绕这个问题，素材强调的不是新增复杂监控面板，而是先补齐基础的交接元数据，包括会话标识、工作流名称、交接来源、交接目标等。只有当不同Agent运行被明确归入同一条工作流，排查才有边界。
交接Schema和状态校验，比只看运行结果更重要
素材中的TypeScript示例展示了问题的典型成因。分诊Agent输出包含category和orderRef，但在构造给退款专员Agent的输入时，开发者只保留了category，orderRef在交接载荷组装阶段消失。
值得注意的是，排查工具并不一定需要保存完整业务数据。示例中的追踪信息没有记录订单编号本身，只记录了字段名和是否存在。这种方式已经足够定位断裂点：退款专员Agent收到的字段列表中没有orderRef，于是判断需要升级，最终触发escalation-agent。
如果没有将三次运行关联起来，开发者很容易把责任归给最后可见的Agent，因为它产生了最明显的症状：开了错误的工单。但真正的问题发生在上游交接输入构造阶段。
这也解释了为什么显式字段和Schema校验在多Agent系统中格外重要。素材建议，在发送前和接收后都加入运行时校验。例如定义RefundHandoff类型，要求category必须为refund，且orderRef必须是非空字符串。如果校验失败，系统可以直接阻止错误交接，而不是让无效数据继续流向下游。
- 运行日志负责解释发生了什么。
- Schema校验负责阻止不符合约定的交接。
- 会话追踪负责把不同Agent运行归入同一条工作流。
这三件事并非互相替代，而是互相补充。
多智能体系统需要承认不确定性
素材还提到，多Agent工作流会持续演化。今天triage-agent输出orderRef，未来新版本specialist可能期望orderId。即使两个字段都是字符串，这也已经构成协议变化。
为此，可以在step或run的metadata中加入handoffContract，例如refund-request/v2。这样，审查者可以判断生产者和消费者是否使用了同一份边界定义，而不必在追踪数据中保存真实业务值。
这种做法也能区分多种表面相同的失败原因：可能是生产者没有生成字段，可能是传输层丢弃字段，可能是映射阶段重命名字段，也可能是消费者期待另一个契约版本。如果没有契约标识，这些问题在日志里可能看起来完全一样。
素材中提到的AgentInspect工具也体现了一种克制的排查原则：它不会仅凭时间戳制造因果关联。如果attempt大于1但缺少retryOf，系统会将关系标记为correlated而非explicit，并在诊断信息中说明存在歧义。
换句话说，一张看起来完整但边是编出来的流程图，不如一张不完整但承认不确定性的图更有价值。对多Agent系统而言，可观测性应该解释哪些流程确实执行了，而不是成为第一次发现缺失必填字段的地方。
随着企业级Agent应用越来越多，问题也会从“单个模型是否足够聪明”转向“多个Agent之间能否可靠协作”。这次案例提醒开发者：多智能体系统的质量不只取决于每个Agent单独运行的成功率，也取决于交接契约、字段校验、会话身份和状态追踪是否足够清晰。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/dang-san-ge-agent-dou-cheng-gong-ren-wu-que-shi-bai-le-duo
