模式矩阵 /模式白皮书/Action

范围：本页说明行动子系统的整体设计。A1 至 A5 的问题、机制和验证标准仍以各模式规范为准。

行动从 Agent 准备改变外部环境时开始。发送消息、修改文件、提交工单、执行命令、调用支付接口和操作 GUI 都属于行动。它们与生成一段文字的差别，在于外部系统会留下状态变化，有些变化无法靠下一轮回答撤回。

生产级行动模块需要把“模型想做什么”翻译成外部系统能够检查的合同：当前步骤是什么，允许使用哪些工具，参数从哪里来，执行前谁批准，动作在哪个边界内运行，完成后用什么证据验收，失败后从哪里恢复。

一条动作的运行顺序

运行顺序可以压成一条线：推理决策（Reasoning Decision）先进入目标合同（Goal Contract）与计划（Plan），执行器（Executor）选出当前计划步骤（PlanStep），提示链（Prompt Chain）生成或校验该步骤的结构化产物（Artifact），工具调度（Tool Dispatcher）缩小候选并决定准入，护栏三明治（Guardrail Sandwich）再执行事前检查（PRE）、工具调用（TOOL）和事后检查（POST）。最后，业务账本、统一动作事件（ActionEvent）和检查点（Checkpoint）共同证明发生了什么。

模型可以参与计划、工具选择和参数填写。权限、幂等、状态新鲜度、事务结果和外部回执应由运行时与业务系统掌握。

Action Contract

一次可执行动作至少需要下面这些字段：

action_id: act_01K2...
goal_ref: goal://payroll/close-2026-08
plan:
  version: 7
  step_id: verify-approvals
  depends_on: [load-batch]
intent:
  operation: payroll.verify_approvals
tool:
  name: approval_service.read_batch
  registry_version: 12
inputs:
  batch_id:
    value: batch_8842
    source: state://payroll/current_batch
authority:
  risk: read_only
  approval: none
execution:
  sandbox: payroll-readonly-v3
  idempotency_key: act_01K2
verification:
  expected: all_required_approvals_present
  evidence: receipt://approval-service/check-901
recovery:
  checkpoint: checkpoint://run-8842/step-4

动作合同把自然语言意图、计划位置、工具版本、参数来源、授权、执行环境、验收证据和恢复位置放在同一条记录里。缺少其中任何一段，都可能出现“工具返回成功，但业务目标没有完成”的假成功。

ReAct 还是显式 Plan

行动模块不要求每个任务先写完整计划。选型取决于任务长度、动作后果、环境变化和恢复要求。

长任务的 Plan 应是版本化产物，不应只存在于对话历史。它至少带步骤标识、依赖、预期产物、验收条件、允许工具和恢复位置。领域 DSL 可以在这个稳定核心之上增加业务动词与约束，不必追求一套 DSL 覆盖所有行业。

行动接口的优先级

结构化接口通常优先于 GUI：

1. 领域 API、Skill 或经过认证的命令提供明确参数、权限和回执，适合稳定流程。
2. 受控 CLI适合开发、运维和批处理，但需要命令策略、工作目录、资源和网络边界。
3. GUI 操作覆盖没有开放接口的能力，必须保留界面状态、操作截图或可复核的操作证据。

GUI 不是低等级工具。它的主要问题是状态识别与结果确认更难，页面漂移也更频繁。具备稳定结构化接口时，优先使用接口；只能操作界面时，就把识别、点击、等待和验收写成明确合同。

五个正式模式的职责

A1 至 A4 是核心模式，A5 保持扩展模式。A2 属于编排，A3 属于链式；两者可以嵌套，但不应因为一条计划中有多个步骤就混为同一拓扑。

事件驱动与执行拓扑

行动研讨会专门讨论了 Event-Driven 是否应当成为第七种执行拓扑。本轮结论是先保持现有框架：

• 事件定义动作何时被触发、怎样传递、等待和重放。
• 执行拓扑定义任务启动后控制怎样展开。
• 编舞描述没有中央编排者时，多个参与者怎样依靠本地规则和事件协作。

一个系统可以由事件启动，内部使用路由选择工具，以编排推进计划，再在某个步骤中运行循环。事件总线不会替整个流程决定拓扑。

沙箱、门禁与证据

命令、文件写入、网络访问和外部 API 需要在受控边界中执行。沙箱回答“技术上能触及哪里”，审批回答“这次是否被授权”，工具策略回答“允许做哪类动作”，ActionEvent 则留下“实际发生了什么”。

执行前至少检查身份、权限、参数来源、目标状态、幂等键和风险等级；执行后检查返回 schema、业务不变量、实际副作用和外部回执。只看 exit_code == 0 或 HTTP 200，无法证明业务成功。

2026 年的主流 Agent 运行时已经把这些控制做成正式接口。OpenAI 的企业 Codex 安全实践将沙箱、审批策略、网络规则和 Agent 原生遥测组合使用；OpenAI Agents SDK提供工具 schema、tool guardrail、人工介入和 tracing；Claude Managed Agents 的工具配置允许按工具关闭能力或设置确认策略。这些接口说明行动控制正在从提示词约定进入运行时合同。

三类生产故障

选对工具，却使用了过期状态。 写操作前需要刷新关键状态，并把读取版本带入写入条件。否则 dispatch 正确也会写错对象。

步骤完成，目标没有完成。 工具回执只证明调用结束。阶段产物、业务账本和外部验收需要共同裁决任务状态。

恢复后重复副作用。 checkpoint 只记录“做到第几步”还不够。每个不可逆动作需要幂等键、外部回执和已提交标记，恢复逻辑先核对事实再决定是否重放。

仍需行业回答的问题

• PlanStep 的哪些字段可以跨领域稳定，哪些应留给行业 DSL。
• ReAct 升级为显式 Plan 的阈值怎样从任务回放中测量。
• GUI 行动的界面证据、授权和失败回执应采用什么通用格式。
• 一条 Action trace 怎样串起模型意图、工具准入、沙箱事件和业务账本。
• 事件驱动与 C6 编舞需要哪些跨行业失效证据，才能进一步稳定边界。

研讨会记录

本总纲同时依据 A1 至 A5 的公开规范和 2026-08-06 行动模块第一次研讨会。讨论主持人为茹炳晟；核心参与者包括李庆丰、张栋、罗军、唐洪山、王伟、Pylon Peng 和任磊达。

阅读完整研讨记录 · 查看全部研讨会 · 白皮书贡献者