设想一项包含一百个步骤的浏览器任务。假定每一步都以 99% 的概率成功，且彼此独立。所有步骤都成功的概率是 0.99^100，约为 36.6%。
百分之九十九听起来很出色，百分之三十六却不是。
关于浏览器事务性工作的源讨论 用这项计算说明一个限定的观点：客户只在任务完成时获得价值，而每一步都会累积成本和失败风险。这是基于假设的算术，不是任何浏览器代理或 Tajo 同步的已公布成功率。真实错误也可能相互关联。一次登录过期就可能让后续几个操作一起失败。
因此，真正的问题不是“模型最后一次点击有多准”，而是“用户要求的状态出现了吗”。
应以整个事务为单位
设想代理打开保险门户，查找并下载一份文件，再确认它属于正确的账户。即使前 99 个页面都操作正确，只要在第 100 个页面下载了错误文件，任务仍然失败。记录着成功点击的日志无法修复结果。
集成工作也有同样的区别。代理可以发现 API、提出字段映射、保存草稿，但这些都不意味着目标系统中的联系人已有预期的同意状态。只有获批操作已经执行，而且相关后置条件得到检查，工作才算完成。
这就是活动与完成的区别。活动容易计数；完成需要定义。
对文件下载而言，完成的证据可能是一份账户号码与请求一致的文件。对联系人同步而言，可能是目标记录拥有正确标识符、字段和获准的消息发送状态。检查必须直接查看用户关心的对象。上一步调用返回绿色状态，只能证明调用返回了，不一定能证明目标系统按预期改变。
Tajo 的业务工具连接指南先确定工作流和每种数据对象的权威来源。这样的选择赋予最终检查具体含义。如果两个系统都声称拥有某个字段，即便一次写入完全正确，长期状态也可能出错。
多一次判断的成本
沿用假设的 99% 成功率，10 次独立判断让整条链的成功率约为 90.4%，50 次约为 60.5%，100 次约为 36.6%。
整链成功概率（%）
独立步骤数
- 假定每步成功率为 99%
查看计算结果
| 步骤 | 整链成功率（%） |
|---|---|
| 0 | 100.0 |
| 10 | 90.4 |
| 25 | 77.8 |
| 50 | 60.5 |
| 75 | 47.1 |
| 100 | 36.6 |
曲线陡峭，因为相乘不会照顾一个看似优秀的平均值。每增加一次判断，都应证明它有必要。
这并不意味着要把所有 API 调用合并成一个巨型操作。有些调用是确定性的：用已知游标获取页面、比较标识符，或按照获批映射写入字段。模型无需对每条记录重新判断。另一些调用则确实有歧义，例如供应商新增字段、错误消息改变，或者请求的负责人不明确。这些情况可能需要判断。
实用的分工是让判断来设计或修复规则，再让普通代码应用稳定规则。反向 ETL 是重复数据移动的例子：每行的常规操作应由流水线执行，而不是由一次次对话执行。代理仍可以帮助决定流水线应做什么。
这是一条边界，不是一句口号。如果供应商改变字段的含义，确定性规则也可能完美地重复错误。系统需要发现前提已变，并把个案送回审核。
为什么一个大工具不是答案
合理的反对意见是：“长链会失败，就把整个任务放进一次工具调用。”如果工具是一项定义清楚、结果可检查的事务，这确实有帮助；如果它只是藏起漫长且不确定的过程，就没有帮助。
假设 syncCustomer() 发送更新后返回 success: true。如果目标系统稍后才处理更新，此时调用无法证明联系人最终的状态。可见步骤减少了，不确定性却没有减少。
更好的接口会暴露真正重要的状态：已接受、已应用、已检查或失败。每个词都应对应证据。对低影响的预览，写入已接受可能足够；对营销受众或同意状态的变更，应在称其完成之前检查目标系统。
在这个拟议的 Tajo 视图中，请求已接受、更新已应用，与目标状态已验证分属不同阶段。最后一步检查仍待进行。下一步很明确：查看目标系统实际存储了什么。再数一次成功的工具调用，仍无法回答最初的问题。
写入完成仍需证据
客户同步完成了吗？
写入已应用，验证待进行。
尚未检查目标系统的状态。
同步活动
- 请求已接受
- 更新已应用
- 目标系统检查待进行
示例运行 · 14:32 UTC
已知信息
- 服务商响应
- 已接受
- 写入结果
- 已应用
- 从目标系统回读
- 待进行
调用成功不能证明最终状态。
此拟议布局参考 Tajo 的活动记录。图中增加了验证状态，并不表示目标系统回读功能已经实现。
测量方法也要随之改变。尝试次数若能帮助分析成本，就记录它；中途错误若能指向故障步骤，也记录它。但评判工作流要看经过验证的已完成事务，并在数字旁写明验证方法。“99% 的调用成功”并没有回答客户的事情是否办成。
MCP 服务器说明解释工具如何让助手调用其他系统。获得工具访问权只是起点；契约关注的是最后留下的状态。
一百次正确点击，仍可能什么都没留下。要数的是结果。
常见问题
为什么每一步通常正确，长工作流仍会失败？
若每一步独立地以概率 p 成功，n 步链全部成功的概率是 p 的 n 次方。假定每步为 99%，一百步的完成率约为 36.6%。真实失败可能相关，因此这只是示例，不是代理实测成功率。
减少工具调用就一定更可靠吗？
不一定。只有合并后的操作仍保留恰当的检查和恢复点时，减少调用才有帮助。一次不透明调用也可能像长链一样掩盖失败的写入。
团队该衡量代理工作流的什么？
衡量用户事务是否经过验证并完成，而非仅看模型调用是否成功。定义能证明任务完成的产物或目标状态，再记录它在整个工作流结束后出现的频率。