截止期遇见图灵：Agent 编排的实时系统思维

传统 Agent 文章常从“模型能不能规划”讲起，生产系统更关心另一组问题：一次任务最多允许几步？每一步多久超时？写操作失败后能否安全重试？工具返回的网页内容是否可能被当成指令？出了问题，谁能在几分钟内停止并回滚？

这些问题听起来像实时系统和分布式系统，而不像语言模型。把它们引入 Agent 设计，并不会削弱模型的创造性；相反，确定性边界让模型的能力可以被安全地释放。

Agent 是一条带状态的控制链

一次工具调用链可以抽象成状态机：

observe -> plan -> authorize -> execute -> verify -> persist
   ^                                                |
   +---------------- retry / compensate ------------+

每一跳都可能失败：模型给出不合法参数、工具超时、结果格式变化、网络中断、权限过期，或者副作用已经发生但响应丢失。若只把这些失败交给模型“自己再想想”，系统就缺少可验证的恢复语义。

设单步成功率为 $p$，独立执行 $n$ 步的链路成功率约为：

$$P_{\text{chain}} \approx p^n$$

$p=0.95$、$n=8$ 时，整条链只有约 66% 的机会一次完成。重试可以改善单步成功率，却会放大重复副作用和尾延迟。因此，Agent 的超时、重试和幂等必须一起设计，不能当成三个独立开关。

截止期不是超时时间的总和

在实时系统里，截止期来自业务语义：控制回路必须在下一次采样前完成，交易必须在结算窗口内确认，代码修复必须在构建队列释放前提交。Agent 也应先声明总截止期，再由编排器分配每一步的预算。

一个实用的预算结构包括：

• 总截止期：从用户请求到可接受结果的最长时间；
• 单步超时：一次工具调用或模型推理的上限；
• 重试预算：最多重试几次，重试是否消耗额外截止期；
• 检查点：长任务在何处保存可恢复状态；
• 降级路径：预算耗尽时返回部分结果、请求人工确认或安全终止。

这与推理时计算扩展有直接关系。增加采样数或思考 token 可能提升答案质量，但也会消耗延迟预算。对在线系统，最优策略往往不是“想得越久越好”，而是在截止期前选择收益最高的一次额外推理。

本地 工具循环预算 把步数、单步成功率、重试和幂等覆盖率放在一起。它给出的不是攻击概率，而是一个工程提醒：链路越长，越需要观测和检查点。

MCP 解决互通，不替宿主承担信任

Model Context Protocol 为模型客户端与工具服务器之间提供了标准化的能力协商、资源与调用接口。它降低了“每个工具一套适配器”的成本，也让权限边界更容易被显式表达。

但协议本身不等于安全策略。宿主仍需回答：

1. 这个服务器来自哪里，谁维护，更新是否可审计？
2. 某个工具需要什么权限，能否只读、只写单资源或必须全库访问？
3. 工具返回的文本是否可能包含恶意指令或敏感数据？
4. 调用失败时，副作用是否可查询、可撤销或可补偿？

间接提示注入说明，模型看到的“内容”和“指令”边界并不可靠。网页、Issue、邮件甚至代码注释都可能携带攻击者控制的文本。把工具结果直接拼进高权限上下文，相当于允许外部数据影响控制流。更稳妥的设计是内容隔离、来源标注、权限最小化和高风险动作人工确认。

幂等、事务与补偿

写操作必须携带稳定的幂等键，执行层先查询该键是否已有结果，再决定是否真正执行。对于无法做到原子事务的外部系统，需要显式补偿：取消订单、删除临时文件、关闭会话、恢复旧配置。

一个副作用记录至少应包含：

字段	作用
idempotency key	跨重试识别同一次业务意图
actor / request id	追溯谁在何时发起
tool / resource	记录影响对象
before / after	支持核对与补偿
status	区分已提交、未知、已回滚
deadline	判断是否仍有恢复价值

这比只记录“工具调用成功/失败”更接近真实系统。因为最危险的状态往往不是失败，而是“执行了但响应丢失”。

把不确定性放进确定性外壳

一个可靠的 Agent 架构可以分成四层：

• 推理层：允许模型探索、候选生成和自检；
• 策略层：决定哪些动作需要授权，哪些输出可以接受；
• 执行层：负责超时、幂等、重试、隔离和补偿；
• 审计层：记录输入来源、决策依据、副作用和最终状态。

模型越强，越应该把这些边界写清楚，而不是依赖它自觉遵守。就像操作系统不会因为应用程序“很聪明”就放弃内存隔离。

结论

Agent 的工程问题不是“图灵测试是否通过”，而是“在截止期前，它能否以可审计、可恢复的方式完成一个有边界的任务”。实时系统给了我们一套成熟语言：优先级、预算、最坏执行时间、幂等、检查点、降级与回滚。

当这些约束进入设计，Agent 才从演示走向基础设施。模型的创造力负责打开可能性，系统的确定性负责让这种可能性可以交付。

一次多步任务的可调度性

把 Agent 的每一步工具调用视为一个任务，可以为它定义执行时间 $C_i$、相对截止期 $D_i$ 和最小到达间隔 $T_i$。与实时系统不同的是，$C_i$ 不仅取决于工具实现，还取决于模型生成参数和工具返回体大小。最坏执行时间必须用故障注入和压力测试估计，而不能用平均 token 数代替。

若工具链的每次调用都串行执行，总延迟是各步延迟之和；若存在独立子任务，可以由编排器并行化。并行会增加资源竞争，尤其是同一浏览器、数据库或文件系统上的写操作。一个合理的编排器应在开始时构建依赖图，而不是让模型临时决定下一步。

控制点	失败方式	设计响应
总截止期	任务无限重试	硬停止并返回可恢复状态
单步超时	工具卡住	取消请求，标记未知副作用
重试预算	重复写入	幂等键 + 结果查询
权限	过度授权	最小权限、按资源授权
上下文	注入内容	隔离数据，不执行其中指令
观测	日志缺失	request id、工具轨迹、快照

这套表比“让模型反思一下”更接近工程现实。反思可以提高生成质量，但不能替代资源上限。

推理预算与执行预算的互相挤压

推理时计算扩展关心答案质量：多采样、多思考、验证器排序。Agent 执行预算关心完成时间：工具调用、等待外部系统和重试。两者共享同一个延迟池。若模型在上一次工具失败后决定“再想久一点”，它可能已经花掉本应用于重试的时间。

一个可实现的策略是分层预算：

1. 先给规划和答案生成保留基础预算；
2. 为每个工具调用预留超时与一次安全重试；
3. 保留固定比例的人工确认/降级预算；
4. 接近截止期时禁止开启新的高风险写操作；
5. 预算耗尽后只允许读取检查点和返回结果。

这与嵌入式控制中的“安全状态”类似。系统不是简单地停止，而是进入一个可观测、可恢复、不会继续扩大副作用的状态。

测试 Agent 时应该观察什么

只在正常路径上验证工具链，会高估可靠性。应主动注入：

• 工具超时后响应迟到；
• 写操作成功但响应丢失；
• 工具返回结构变化；
• 权限在任务中途过期；
• 检索内容包含恶意指令；
• 模型生成重复或互相矛盾的步骤；
• 外部系统部分不可用。

每次测试都记录任务状态、幂等键、工具输入摘要、副作用、重试次数和最终截止期。对高风险工具，应该使用隔离沙箱和可撤销资源；对真实系统，必须有人工确认或补偿流程。

结论的适用范围

实时系统思维不能保证 Agent 在开放世界中正确。它能让失败变得可控、可测和可恢复。模型仍然可能误解任务，工具仍然可能有 bug，外部数据仍然不可信。工程目标不是消除所有这些不确定性，而是在不确定性发生时，系统不会失去停止、审计和回滚的能力。

当 Agent 被允许影响真实世界，截止期与权限边界就不是产品附加项，而是与模型能力同等重要的设计对象。

最小上线标准

一个 Agent 系统在进入真实业务前，至少应通过以下检查：总截止期可被强制终止；每个写工具支持幂等键；所有外部内容被标记来源；高风险动作可人工确认；失败副作用可查询和补偿；每一次工具调用都有 request id 与审计记录；压力测试覆盖超时、重复响应和权限过期。

这些检查不依赖模型是否“聪明”，也不保证模型一定给出正确答案。它们保证错误发生在可控范围内，并留下继续修复的证据。对研究型博客而言，这种工程视角比再增加一个装饰性交互更重要：读者能看到结论如何被验证，也能看到系统在失败时如何收手。