Runtime 架构
Runtime 是 Agent 的生命基础设施。它不替 Agent 思考，而是提供生命周期、时间、状态、资源、通信、安全和恢复边界，使 Agent 的行为可以持续、审计和复现。
架构分层
┌──────────────────────────────────────────────────────────┐
│ External Environment │
│ Users · APIs · Data · Services · Files · Other Agents │
└────────────────────────────┬─────────────────────────────┘
│ controlled adapters
┌────────────────────────────v─────────────────────────────┐
│ Environment Gateway │
│ Sensors · Tool Gateway · Policy Enforcement · Validation│
└────────────────────────────┬─────────────────────────────┘
│ observations / actions
┌────────────────────────────v─────────────────────────────┐
│ Agent Execution Plane │
│ Goal · World Model · Planner · Memory · Reflection │
└────────────────────────────┬─────────────────────────────┘
│ commands / events
┌────────────────────────────v─────────────────────────────┐
│ Runtime Control Plane │
│ Lifecycle · Scheduler · Recovery · Resources · Security │
└────────────────────────────┬─────────────────────────────┘
│ durable records
┌────────────────────────────v─────────────────────────────┐
│ Persistence & Observability │
│ Event Log · Snapshots · Memory · Audit · Metrics · Trace│
└──────────────────────────────────────────────────────────┘
“控制面”和“执行面”应逻辑分离：控制面决定 Agent 是否有资格运行以及能使用什么资源；执行面在这些约束内执行 Agent 的领域行为。
核心模块
Lifecycle Manager
职责：
- 校验并提交生命周期状态转换；
- 管理实例租约和身份版本；
- 编排休眠、唤醒、迁移和终止；
- 在状态转换失败时进入恢复流程。
它不负责业务任务规划。
Scheduler
调度对象不只是任务，还包括事件、定时器、心跳、恢复动作和演化实验。调度决策至少考虑：
- 优先级、截止时间和公平性；
- Agent 生命周期状态和租约；
- CPU、内存、模型额度、工具并发和外部限流；
- 任务依赖、互斥资源和数据局部性；
- 重试预算和失败域隔离。
调度器必须区分“没有被调度”和“已经执行但尚未确认”，否则重启时容易产生重复副作用。
Event Bus
事件总线传递已发生的事实，例如 AgentWoke；命令表达期望，例如 WakeAgent。两者不能混用。
每条消息至少包含：
- 消息 ID、类型和模式版本；
- 发送者、目标和授权上下文；
- 发生时间、接收时间和因果关联 ID；
- 幂等键、过期时间和追踪 ID；
- 负载、签名或完整性校验信息。
默认投递语义可以是“至少一次”，但消费者必须通过幂等键获得业务上的恰好一次效果。
Persistence
持久化层至少区分：
- 事件日志：记录发生了什么，用于审计和状态重建；
- 快照：加速恢复的逻辑一致性视图；
- 记忆存储：保存可检索经验及其来源；
- 对象/制品存储：保存大型输入、输出、模型或实验制品；
- 配置与策略存储：保存版本化配置、权限和发布状态。
不要求所有数据进入同一数据库，但跨存储引用必须稳定、可验证且有保留策略。
Heartbeat & Health
健康管理聚合进程、依赖、进度和语义质量信号。心跳丢失只是恢复触发候选；在判定失联前应考虑网络分区、时钟偏差和暂停事件。
Resource Manager
资源管理器负责分配和强制执行：
- 计算、内存和并发配额；
- 模型 token、费用和速率预算；
- 工具调用次数和外部系统限流；
- 存储容量、记忆保留和日志配额；
- 单 Agent、组织、租户和全局层级的限制。
达到预算时必须产生显式结果：排队、降级、请求审批或停止，不能静默丢弃。
Security & Policy
安全策略围绕主体、资源、动作和条件表达：
Subject: Agent / User / Runtime Service
Action: read / write / invoke / delegate / evolve / terminate
Resource: memory / tool / agent / snapshot / external system
Condition: purpose / time / budget / tenant / approval / risk level
每次高风险动作必须绑定实际授权主体和策略版本。Agent 不能通过委托获得高于委托者的权限。
Recovery Coordinator
恢复协调器负责根据失败类型选择重试、补偿、回滚、重放、迁移、隔离或人工接管。它需要知道动作的副作用语义，不能把所有错误都当成可重试异常。
Observability
可观测性应回答：
- 哪个 Agent 因为什么目标执行了哪个动作？
- 动作使用了什么能力、权限、输入版本和记忆？
- 状态从哪里变到哪里，谁批准，为什么？
- 失败发生在哪个边界，是否已产生副作用？
- 一次演化改变了什么，指标是否改善，有无回归？
指标、日志和追踪必须共享 trace_id、agent_id、goal_id、task_id 和版本信息，才能形成因果链。
一次动作的完整路径
1. Event Bus 接收事件
2. Scheduler 判断 Agent 是否可运行
3. Runtime 加载一致快照和事件游标
4. Agent 更新世界模型并选择目标
5. Agent 生成动作意图
6. Policy 校验权限、预算和风险
7. Tool Gateway 以幂等键执行动作
8. 结果转成带来源的观测
9. Agent 评估结果并产生记忆候选
10. Runtime 提交事件、状态和检查点
11. Observability 关联全链路证据
第 7 步和第 10 步之间是最危险的故障窗口：外部动作可能成功，但本地提交失败。每个工具适配器必须提供查询结果、幂等执行或补偿机制中的至少一种。
一致性边界
不追求全系统强一致，但必须明确每个对象的一致性要求：
| 对象 | 建议一致性 | 原因 |
|---|---|---|
| 生命周期状态与写租约 | 强一致或线性化提交 | 防止双活 |
| 外部副作用记录 | 幂等键 + 状态机 | 防止重复执行 |
| 世界模型 | 最终一致并保留冲突 | 观测天然延迟 |
| 记忆索引 | 最终一致 | 检索允许短暂延迟 |
| 权限与撤销 | 撤销优先、短缓存 | 降低越权窗口 |
| 指标与日志 | 最终一致 | 不参与业务提交 |
失败域
模块边界也应是失败隔离边界：
- 单个工具故障不能阻塞全部 Agent；
- 单个 Agent 的死循环不能耗尽全局资源；
- 记忆索引故障不能破坏权威事件日志；
- 观测系统不可用不能让安全策略失效；
- 演化实验不能直接修改稳定执行面。
部署拓扑候选
设计允许从单机原型演进到分布式部署：
- 单进程原型：验证状态机、事件和接口语义。
- 单机多进程：验证租约、故障恢复和进程隔离。
- 分布式控制面：验证多节点调度、消息投递和存储一致性。
- 多租户运行时：增加强隔离、配额、审计和合规边界。
每个阶段都应保持相同的核心契约，而不是为了分布式部署重写 Agent 语义。
Runtime 不变量
- Runtime 不代表 Agent 做目标和价值判断。
- 没有有效租约的实例不能产生受保护副作用。
- 命令、事件和状态转换具有独立、可追踪的身份。
- 权限撤销优先于缓存可用性。
- 任何跨系统副作用都具有幂等、查询或补偿路径。
- 审计记录不能依赖 Agent 自己选择是否写入。
实现前必须决定的问题
- 生命周期和租约使用何种一致性存储？
- 事件投递保证、顺序范围和死信策略是什么？
- 快照与事件日志如何建立原子恢复点？
- 工具适配器如何声明副作用、幂等和补偿能力？
- 权限模型采用 RBAC、ABAC、能力令牌还是组合模型？
- 资源预算如何跨 Agent、租户和时间窗口结算？
- 哪些动作必须由人类审批，审批失效条件是什么？
这些问题的答案应形成架构决策记录，而不是隐藏在实现细节中。