摘要
Agent Runtime 是大模型应用从“会回答”走向“能执行”的中间层。它不直接等同于模型、提示词或工作流编排，而是负责管理一次任务的状态、上下文、工具调用、权限、人工确认、失败恢复和运行轨迹。
如果把模型看作一个会生成下一步动作的策略函数，那么 Runtime 就是执行环境。它决定哪些动作可以被执行，哪些证据可以进入上下文，哪些副作用必须等待确认，以及一次运行结束后是否能被复盘。
为什么聊天上下文不是 Runtime
许多 Agent 原型把所有信息都放进 messages：用户输入、模型推理、工具结果、历史摘要。这种方式适合演示，但不适合长期任务。聊天上下文有三个问题：
- 它是顺序文本，不是可查询的业务状态。
- 它会混合过期事实和当前事实。
- 它无法自然表达权限、重试、确认和补偿动作。
生产系统通常需要把“对话历史”和“任务状态”分开。对话历史记录交互过程；任务状态记录系统认为当前已知、已执行、待确认和不可执行的事实。
type AgentRunState = {
runId: string;
taskId: string;
actor: {
userId: string;
role: string;
tenantId: string;
scopes: string[];
};
objective: string;
collectedFields: Record<string, string>;
evidenceRefs: Array<{ source: string; version: string; chunkId: string }>;
toolEvents: ToolEvent[];
pendingApprovals: ApprovalRequest[];
stopReason?: "completed" | "blocked" | "handoff" | "failed";
};这类状态结构让 Agent 可以暂停、恢复、转人工，也可以在模型升级后重放同一个任务。
Runtime 的最小状态机
一个任务型 Agent 不一定需要复杂框架，但通常需要明确的状态机。最小形态可以分成六个阶段：
created
-> planning
-> retrieving
-> acting
-> awaiting_approval
-> finalizing
-> completed / handoff / failed状态机的价值不在于形式漂亮，而在于约束动作。处于 retrieving 阶段时，系统只允许只读检索；处于 awaiting_approval 阶段时，高风险写操作不能继续执行；处于 failed 阶段时，只能执行补偿、重试或转人工。
这种设计也能避免一种常见错误：模型在上下文不足时继续编造下一步。Runtime 应该允许模型说“需要更多字段”，但不允许它跳过权限、证据和确认直接写入业务系统。
工具调用是候选动作，不是事实
Tool calling 的返回值经常被误解为“模型已经执行了工具”。更准确地说，模型只是提出了一个候选动作：
model proposes action
-> schema validation
-> identity and scope check
-> risk classification
-> idempotency key generation
-> execution or approval request
-> result normalization
-> event logging这一层保护很关键。模型可能把自然语言里的“差不多下周”填成具体日期，也可能把用户提到的客户名匹配到错误 ID。Runtime 必须在执行前检查参数来源、字段类型、对象归属和动作风险。
对于写操作，还要加入幂等键。否则模型或网络层的一次重试，可能变成重复创建工单、重复发送通知或重复扣费。
权限要进入上下文之前
企业 Agent 的安全边界不能只放在最终回答阶段。只要无权数据进入模型上下文，就已经发生了泄露。更稳妥的做法是：先把用户身份、租户、项目、客户、业务对象转换为检索约束，再召回知识和工具结果。
retrieval_context = {
tenant_id,
user_role,
project_scope,
customer_scope,
document_policy,
task_object_id
}这意味着 Runtime 不是被动接收上下文，而是主动构造上下文。模型看到的材料应该是经过权限过滤、版本过滤和字段最小化之后的结果。
审计轨迹是 Runtime 的输出
一个 Agent 的最终答案正确，不代表运行过程可靠。两个系统都能生成同一段回复，但其中一个可能只读取了必要证据，另一个可能越权读取了无关客户资料。没有运行轨迹，团队无法区分。
建议至少记录以下事件：
| 事件 | 记录内容 |
|---|---|
| model_turn | 模型、输入摘要、输出动作、token 和耗时 |
| retrieval | 查询条件、召回来源、过滤原因、证据版本 |
| authorization | 用户身份、权限范围、允许或拒绝原因 |
| tool_call | 工具名、脱敏参数、结果摘要、重试次数 |
| approval | 确认人、确认动作、风险等级、确认时间 |
| side_effect | 写入对象、字段变化、幂等键、补偿方式 |
这些轨迹会变成评估和回归测试材料。模型换代、工具 schema 变更、权限策略调整后，都可以用历史运行回放检查是否引入新风险。
与工作流引擎的区别
Agent Runtime 和传统工作流引擎有重叠，但边界不同。
| 维度 | 工作流引擎 | Agent Runtime |
|---|---|---|
| 控制逻辑 | 预定义流程图 | 模型提出下一步，Runtime 约束执行 |
| 输入形态 | 结构化表单和事件 | 自然语言、文件、业务对象混合输入 |
| 工具选择 | 节点固定 | 可在候选工具中选择 |
| 风险控制 | 流程权限和审批 | 权限、证据、工具、输出同时约束 |
| 评估方式 | 节点是否完成 | 轨迹、证据、副作用和最终结果一起评估 |
实际系统通常会把两者结合：确定性流程交给工作流引擎，开放式判断交给模型，Runtime 负责连接和审计。
局限与工程权衡
Runtime 会增加系统复杂度。最常见的成本包括：状态模型设计、工具事件规范、权限映射、日志脱敏、回放环境、人工确认 UI。对于只读问答场景，这些成本可能过高。
因此建议从最小 Runtime 开始：一个任务状态表、一个只读检索工具、一个低风险写工具、一个确认机制、一条审计日志。等任务稳定后，再扩展多工具、多角色和多模型策略。
参考材料
- ReAct 提出了把推理和行动交替组织的 Agent 模式：Yao et al., 2022。
- OpenAI、Anthropic 等工具调用接口把模型输出结构化为可执行候选动作。
- MCP 等协议正在标准化工具连接层，但状态、权限和审计仍需要应用 Runtime 设计。
