把子智能体的交接当作分布式系统操作

微软首席软件工程师 Girish Konda 介绍自己的开源项目 MCP Pacemaker，并说明演讲表达个人观点。他认为子智能体会继承分布式系统中熟悉的故障模式。

编排器把工作分给并发执行的工作者，它们读取共享上下文、调用外部工具，随后由编排器汇总结果。这些要素使协调成为分布式系统问题。

Konda 指出几类问题：部分失败伪装成成功、未经核实的共享信息、无界扩散，以及重试时重复执行副作用。

工作者可能崩溃、不回复，或返回流畅但错误的答案。没有完成任务的智能体可能看似成功，因为其结果与完成任务的文本格式相同。

他描述三次告警调查都给出相同结论：一次检查了遥测数据，一次匹配标题，第三次编造答案。单看结论无法知道背后做了多少工作。

单靠超时无法区分工作者运行缓慢、已经失败还是回复丢失。Konda 说应把结果记录为未知，而不是当作失败的证明。

在 MCP Pacemaker 中，首次启动下载时可能超过普通超时。单独设置初始化超时解决了这一情况；另一项修复则保留崩溃原因，避免被超时覆盖。

他建议交接结果包含明确状态、已完成和未完成的工作、证据及副作用；部分完成应当是有效结果。

检查后得到否定结果，与无法执行检查是不同事实。混淆两者会影响重试、升级处理和后续审计。

谈到脏读时，他举例说一个工作者猜测错误率下降 80%，另两个重复这个说法，编排器看到的表面一致其实只来自一个缺乏依据的来源。

三个智能体读取同一说法并不构成独立确认。Konda 将其与法定人数系统作对比：后者的保证依赖读写集合的交集。

他介绍线性一致、顺序一致、因果一致、会话保证和最终一致等术语，并说共享上下文本身不会建立这些保证。

他提出 SAFE 交接模型：来源读取、至多一次副作用、扩散预算和明确结果。他将其作为自己处理真实系统的设计，而非通用标准。

在来源读取方面，事实记录应标明来源、版本、范围及相关时间，并在使用时检查是否仍然新鲜。

在他的例子中，五分钟新鲜度窗口允许早期决定使用数据，但会拒绝稍后的决定，后者必须重新读取来源。

回复丢失后重试可能重复真实写入，例如创建拉取请求。调用方只知道结果未知，不能假定什么都没有发生。

Konda 区分至多一次交付与至少一次交付：前者可能丢失工作，后者可能重复工作。去重需要身份键等机制。

他的桥接程序重启后可以重放初始化握手，但不会重放结果不确定的工具调用；调用方应检查实际结果。

对于副作用，他建议为操作设置身份、把批准绑定到该操作，并在之后回读；只有观察到效果，才能确认操作已完成。

工作者暂停时租约可能过期。每次授予时递增的栅栏令牌能让存储拒绝旧工作者稍后的写入；Konda 把类似原则用于在执行关口检查批准。

无界扩散是流量控制问题。他回忆多个包管理器同时冷启动破坏共享缓存，即使每个请求单独看都合理。

他的桥接程序限制部分冷启动的并发并设置等待上限，超时后有意允许启动。他说这是在缓存损坏风险与可用性之间作出的选择，应当记录。

另一个会话上限会短暂等待，随后拒绝新工作；拒绝会计入健康状态失败。容量必须在启动前预留，以避免先检查后执行的竞争。

明确结果要求代码验证结果结构、证据、新鲜度和计算。检查失败时应返回带原因的拒绝，而不是在接受的文本下附上一句警告。

他举例比较 1,000 个请求中的 10 个错误与 600 个请求中的 6 个错误：数量下降了，但两者的错误率都是 1%。重新计算后，应拒绝缺乏依据的改善说法。

SAFE 不能证明来源正确、保证恰好一次交付、回滚部分工作，或为所有工作者建立全局顺序。回复丢失后仍需要回读或其他处理。

这些检查会增加延迟并可能降低可用性。Konda 说，对只起草文本且由人审阅的智能体而言，这可能是不必要的开销；他的设计也假定只有一个编排器。

最后，他建议构建者把交接视为网络调用，返回明确状态，并用代码执行适当检查。