智能体部署与运行时服务

（让智能体真正“活起来”的系统基础设施）

绝大多数关于智能体的讨论，都停留在“模型”和“推理”上。 但一个 Agent 真正的价值，不在于它能不能规划一个任务，而在于它能否 在真实世界中持续、稳定、长期地执行任务。

要做到这一点，模型不是主角。 系统才是主角。

部署（Deployment）和运行时（Runtime）决定了： 一个智能体是“实验室里的一段推理”， 还是“一个在生产环境里可靠工作的数字员工”。

白皮书在这一章传达的最重要思想是：

Agent 不是一个 prompt，它是一个服务（service）。 服务必须部署、必须观察、必须治理、必须持久化。

这一思想的成熟，会重新定义未来软件系统的底层结构。

从“可运行”到“可长期运行”

人们第一次实现一个 Agent 时，通常是在 Notebook 里跑一个循环： 模型想一下 → 调工具 → 再想一下 → 输出结果。

你会觉得它“可以工作”。 但这和一个能在真实生产环境里跑的 Agent 相差了几个数量级。

Notebook 中的 Agent 只是“一次性实验”。 生产环境中的 Agent 则必须满足：

  • 稳定性：挂了之后要能恢复
  • 持久性：长期任务要跨天、跨周运行
  • 并发性：同时为成百上千个用户服务
  • 隔离性：不同任务之间不互相污染
  • 可观测性：每一步能追踪、能调试
  • 治理能力：能识别滥用、风险、错误
  • 进程模型：有生命周期，有资源控管
  • 政策约束：操作受权限控制
  • 版本管理：模型版本升级不能搞崩系统
  • 一致性：外部输出必须可验证
  • 容错能力：失败时能回退、重试、修正

换句话说：

运行时不是可选项，而是真实 Agent 的基石。

Runtime 的核心职责：让智能体有“生命”

如果把一个 Agent 看作“数字生命体”， 那 Runtime 就是它的 神经系统、循环系统、免疫系统、内分泌系统。

它管理的不仅是执行，更是：

  • 状态
  • 记忆
  • 长期任务
  • 突发事件
  • 子任务调度
  • 多 Agent 协作
  • 工具调用权限
  • 资源管理

模型负责“想”。 Runtime 负责“活”。

Agent 的生命周期（Lifecycle）

白皮书提出一个至关重要的框架：

Agent 是一个 long-running process 而不是一次函数调用。

Agent 有生命周期：

  1. 初始化（Initialization） 载入 Persona、策略、工具、域知识、记忆。

  2. 唤醒（Wake） 接收任务事件、API 调用、用户输入、系统触发。

  3. 活动（Active Phase） Think → Act → Observe 循环持续推进。

  4. 暂停（Suspend） 等待新的 Observation 或外部事件。

  5. 持久化（Persist） 把状态写入数据库，确保系统重启不丢失。

  6. 恢复（Resume） 根据必要事件继续任务。

  7. 结束（Terminate） 主动完成、失败退出、或被策略终止。

这些阶段决定了 Agent 是否能处理：

  • 长生命周期任务（例如 72 小时的审计任务）
  • 异步事件（例如任务等待人类反馈）
  • 断点恢复（系统宕机后能继续）

你会发现：

这更像进程调度（process orchestration），而不是 prompt。

Session State：智能体的“短期记忆”存在哪里？

智能体的每一次行动、观察、错误、状态转移，都必须写入状态存储：

  • 对话历史
  • 工具调用记录
  • Plan Graph
  • 临时变量
  • 错误上下文
  • 中间结果
  • 当前目标
  • 用户偏好
  • Session metadata

这不是大模型的上下文，而是系统级状态。

LLM 上下文只是阅读窗口， 而 Runtime State 是智能体的“真实记忆”。

Execution Engine：智能体的“动作层”如何运作？

工具调用不是“LLM 想到就执行”的。 Runtime 需要负责：

  • 参数验证
  • 风险评估
  • 沙箱隔离
  • 重试策略
  • 超时终止
  • 响应超时兜底
  • 失败分类：可恢复/不可恢复
  • 逐步上传过程事件

举例： 当模型要求执行 SQL 时，Runtime 要检查：

  • 表名是否合法？
  • 字段是否存在？
  • 查询是否越权？
  • 参数是否经过清洗？
  • 查询是否过重？
  • 是否需要分页？
  • 是否需要审计？

白皮书强调，这一层就是未来 Agent 安全性的核心。

事件驱动：智能体不是同步的，它是异步的

在实验室里，一个 Agent 完成一个任务可能只需要几秒。 但在真实世界里，任务往往不是连续的：

  • 等 external API 响应
  • 等人类回复
  • 等长周期 process 完成
  • 等系统事件触发
  • 等外部 agent 提供信息

于是一个真正的 Agent 必须是事件驱动（Event-driven）的：

  • Action 触发事件
  • 事件触发下一步推理
  • 推理触发下一步行动
  • 行动触发新的事件

这与现代分布式系统非常类似。

Observability：智能体必须可被“看见”

这是白皮书强调得最多的 Runtime 职责之一：

没有可观测性，智能体系统无法调试、无法控制、无法信任。

Observability 不只是打印日志，而是：

  • 完整 trace（每一步的输入、输出、工具、延迟、成本）
  • 行为图谱（task graph）
  • 状态快照（state snapshot）
  • 工具调用序列
  • 错误分类与频率
  • 成功/失败率
  • Token 账单
  • 计划图与实际执行的差异

未来的智能体系统，必须有“时间旅行能力”： 你可以回到任意时刻，查看：

  • 它当时想了什么？
  • 为什么选择这个工具？
  • 工具返回了什么？
  • 它是如何理解这个观察的？

调试多智能体系统，没有可观测性是不可能成功的。

Policy Layer：智能体的“法律与宪法”

智能体有能力改变外部世界，因此必须有政策约束：

  • 权限边界
  • 工具使用限制
  • 敏感操作审计
  • 成本预算
  • 资源上限
  • 访问控制（ACL）

Policy 不是写在 prompt 里的，而是：

系统级的、可程序化的规则模块。

这是 Runtime 的一部分，而不是提示词。

模型与工具版本管理：智能体要经历“演化”但不能退化

当你升级模型或工具时，系统必须保证：

  • 不破坏现有任务
  • 不破坏多 Agent 协作
  • 不改变行为边界
  • 可以回滚
  • 可以灰度
  • 可以并行使用多个版本
  • 可以针对不同用户使用不同版本

否则每次升级都会变成灾难。

把智能体当成“服务”，而不是“思维实验”

这一章的核心思想可以总结为一句话：

在生产环境，Agent 不是“推理”，而是“服务”。

服务意味着：

  • 有 SLA
  • 有架构
  • 有依赖
  • 有监控
  • 有版本
  • 有生命周期
  • 有错误恢复
  • 有安全策略
  • 有资源控制

智能体只有成为服务，才能真正融入现代软件系统。

Part 8 总结：Agent Runtime 的真实地位

如果说大模型是智能体的“认知引擎”， 那 Deployment & Runtime 则是它的“生存机制”。

没有 Runtime，智能体只能在 notebook 里玩玩； 有了 Runtime，它才是一种真正可靠的数字存在。

未来的软件，不会只是“API + 数据库”。 它会演化成：

  • 一组长期运行的智能体
  • 由统一的 Runtime 调度
  • 在明确的安全策略下运行
  • 在清晰的状态模型中思考
  • 通过事件驱动机制响应世界

这是下一个时代的计算基础。