前面写过一篇 LangChain Agent Runtime 的生产可靠性，主要聊的是 Runtime 自身怎样把 Agent 从 demo 带到生产环境：状态、会话、工具调用、中断、恢复、Human-in-the-loop。

这篇想继续往后走一步。

当 Agent Runtime 已经能跑起来之后，真正决定它能不能长期在线的，不是「模型有多聪明」，而是三个更朴素的问题：

  • 出问题时，我能不能看见？
  • 风险变大时，我能不能降级？
  • 任务失败后，我能不能恢复？

这三个问题，对应 Agent Runtime 上线后的三条生命线：观测、降级、恢复。



一、观测：不要只记录最终答案

很多 Agent 系统刚上线时，日志只记录两类东西：

  • 用户输入了什么
  • 模型最后回答了什么

这对普通 Chatbot 也许够用，但对 Agent Runtime 远远不够。

因为 Agent 的关键行为发生在中间：

  • 它为什么选择这个工具？
  • 它给工具传了什么参数？
  • 工具返回后，它怎样理解结果？
  • 它是否重复尝试了同一个失败路径？
  • 它有没有在不确定时继续冒险执行？

如果这些中间过程不可见，线上问题就会变成玄学。你只知道用户说「它乱操作了」，却不知道乱在规划、工具、状态、权限，还是模型判断。


Agent Trace 应该记录什么

一个可调试的 Agent Trace 至少要包含这些层次：

层次 要记录的内容 作用
Request 用户输入、用户身份、环境信息 判断任务入口是否正常
Plan 模型的任务拆解、下一步意图 判断规划是否跑偏
Tool Call 工具名、参数、权限、耗时 判断执行是否可靠
Tool Result 返回值摘要、错误码、异常栈 判断外部依赖是否异常
State 会话状态、memory 命中、checkpoint 判断上下文是否污染
Decision 是否重试、是否中断、是否交给人 判断控制策略是否合理

这里最重要的不是把所有 token 都存下来，而是保留足够重放一次事故的证据链。

Agent 线上事故最怕「看起来像模型问题」。因为一旦归因到模型，大家就容易放弃工程分析。但实际情况常常是：

  • 工具 schema 太宽，模型传了合法但危险的参数
  • memory 命中了过期信息
  • 上一步工具失败，但 Runtime 没有把失败状态显式传给下一步
  • retry 把一次可控错误放大成了多次副作用
  • 人工接管入口太晚，等发现时任务已经执行过头

这些问题都需要 trace 来定位。



二、降级：别让 Agent 只有「全自动」一种形态

很多人设计 Agent 时有一个误区：要么全自动，要么不可用。

这在生产环境里很危险。

真正稳定的 Agent Runtime，应该允许系统在不同风险水平下切换模式：

  • 自动执行
  • 半自动确认
  • 只读建议
  • 人工接管
  • 暂停任务

也就是说，Agent 不应该只有一个油门，还要有刹车、限速和手动挡。


降级不是失败，而是控制风险

举个例子，一个代码 Agent 正在修改项目。

低风险时，它可以自动读文件、搜索、生成 patch。

中风险时，比如要改核心认证逻辑，Runtime 可以要求它先产出计划，再等待确认。

高风险时，比如要执行数据库迁移、删除文件、推送生产分支，就必须进入人工接管。

这不是让 Agent 变笨，而是让它在不同风险区间里使用不同的自主权。


可以落地的降级策略

我会把降级策略拆成四类：

策略 触发条件 Runtime 行为
权限降级 命中高危工具或敏感资源 从自动调用变成确认后调用
置信度降级 模型多次自我修正或输出不稳定 从执行变成只给建议
成本降级 token、时间、工具调用次数超预算 停止继续探索，要求用户补充信息
依赖降级 外部 API、数据库、搜索服务异常 切换备用路径或暂停任务

这里的关键点是：降级条件不能只藏在 prompt 里。

Prompt 可以提醒模型谨慎，但真正可靠的限制要放在 Runtime 层。因为 Runtime 才能稳定读取工具权限、调用次数、执行耗时、错误类型和资源边界。



三、恢复：失败后要能从中间继续

Agent Runtime 和普通函数调用最大的区别之一，是任务往往不是单步完成的。

一次完整任务可能包含：

  • 读上下文
  • 搜索资料
  • 制定计划
  • 调用工具
  • 修改状态
  • 等待用户确认
  • 继续执行
  • 生成最终结果

如果系统在第六步崩了，最差的设计是让用户从头再来。

更好的设计是：Runtime 能从最近一次可信 checkpoint 恢复。


Checkpoint 不只是保存聊天记录

很多系统以为保存 messages 就等于保存状态。其实不够。

对 Agent Runtime 来说，checkpoint 至少要包含：

  • 当前任务目标
  • 已完成步骤
  • 待执行步骤
  • 工具调用结果
  • 外部副作用记录
  • 用户确认状态
  • memory 读写记录
  • 当前权限上下文

尤其是外部副作用记录非常关键。

如果 Agent 已经发过邮件、改过文件、提交过订单，恢复时就不能简单重试同一步。否则「恢复」会变成「重复执行」。


恢复机制要区分三种失败

并不是所有失败都应该自动恢复。

失败类型 例子 推荐处理
暂时性失败 网络超时、限流、依赖短暂不可用 自动重试或延迟恢复
可修正失败 参数格式错误、工具返回可读错误 让 Agent 修正后继续
语义性失败 目标冲突、权限不足、用户意图不清 暂停并请求人工输入

这也是为什么 Runtime 需要把错误结构化，而不是只把异常文本塞回模型。

模型看到 Error: failed 只能猜。Runtime 如果告诉它「这是限流」「这是权限不足」「这是参数缺字段」，Agent 才能做出更稳定的下一步。



四、把三条生命线串成一个闭环

观测、降级、恢复不是三个孤立模块。

它们应该形成一个闭环：

  1. 观测发现异常信号
  2. Runtime 根据规则触发降级
  3. 降级后保留状态和证据
  4. 人或 Agent 修正问题
  5. 系统从 checkpoint 恢复执行
  6. 事故 trace 进入评测集，反过来改进 Runtime

这也是我越来越喜欢把 Agent Runtime 看成「执行操作系统」的原因。

模型负责推理，工具负责能力，Runtime 负责让这一切在真实世界里有边界、有状态、有恢复路径。

如果没有 Runtime，Agent 只是一个会调用工具的模型。

有了 Runtime，Agent 才开始像一个能长期运行的系统。



五、一个简单的生产检查清单

如果你正在把 Agent 做到生产环境，可以用下面这份清单快速自查：

  • 是否能查看每一次工具调用的输入、输出、耗时和错误？
  • 是否能知道 Agent 每一步为什么这样做？
  • 是否有任务级 checkpoint，而不只是 message 历史？
  • 是否区分了可重试错误、可修正错误和必须人工介入的错误？
  • 是否限制了高危工具的自动调用权限？
  • 是否有 token、时间、工具次数、外部成本预算？
  • 是否能从中断处继续，而不是要求用户重新开始？
  • 是否能把线上失败样本沉淀成回归评测？

如果这些问题大部分答案是否定的，那系统还不算真正生产就绪。

它可能能演示，但还不能托付。



结语

Agent Runtime 的价值，不是让模型显得更像人，而是让模型的行动变得更像工程系统。

一个可靠的 Agent 不只是会完成任务，还应该能解释过程、控制风险、从失败中恢复。

所以，当我们讨论 LangChain、LangGraph、Agents SDK 或任何 Agent Runtime 时，真正要问的不是「它能不能跑一个漂亮 demo」，而是：

它能不能在出错时留下证据，在风险升高时主动降级，在失败之后继续向前。

这才是 Agent 从玩具走向生产的分界线。