Action Types
Action Type 是一组受控的变更提交：创建工单、更新决策、触发审批、共享上下文。在 AIDC 平台中，Agent 想改变企业状态，必须通过 Action Type 提交——这是唯一合法通道。每次提交都绑定发起者、Agent 版本与上下文包版本，并写入 Action Log。
Agent 写入企业关键状态必须走 Action Type，不允许绕过审计直接修改底层数据。读可以宽松分层，写必须收口到一个通道——这是整个平台审计与责任体系的支点。
什么是 Action Type
在传统系统里，"改数据"散落在无数入口：直接写库、改文件、调内部 API、人工后台操作。每个入口都是一条审计盲区。Action Type 把所有状态变更收口为一种结构：显式声明的参数 + 前置权限校验 + 受控副作用 + 强制审计。
一个 Action Type 的定义包含：
| 组成 | 说明 |
|---|---|
parameters | 显式参数 schema：每个参数的类型、是否必填、引用哪类对象 |
preconditions | 提交前必须满足的条件：发起者权限、对象状态、策略规则 |
effects | 受控副作用清单：创建 / 更新哪些对象与 Link，发布哪些事件 |
approval | 是否需要前置审批，以及审批人或策略规则 |
log-schema | 写入 Action Log 的字段：记录什么、不记录什么 |
reversal | 逆操作或补偿动作的定义，支撑回滚 |
Action Type 与 Object Types、Link Types 一起构成 Ontology 的"操作合约"：对象定义企业有什么，Link 定义它们如何关联，Action 定义状态如何被合法改变。
Action 的提交流水线
每次 Action 提交都经过同一条流水线，任何一步失败都会使整个提交被拒绝并留下记录：
- 提交 — 发起者（人或 Agent）携带参数与幂等键（idempotency key）提交 Action 草案。
- 校验 — 参数 schema 校验；Policy & Identity Plane 校验发起者身份与对象级权限；前置条件检查（对象状态、审批要求）。
- 执行 — 副作用在事务边界内执行：写对象、建 Link、改文件引用，要么全部生效，要么全部不生效。
- 审计 — 写入 Action Log，绑定发起者、Agent 版本、上下文包版本与工具调用摘要。审计写入失败视为执行失败。
- 广播 — 通过事件总线（EventBridge / SQS）通知订阅方，下游 Agent Cell 按事件触发后续工作。
"绑定上下文包版本"意味着：复盘任何一次变更时，都能还原 Agent 当时看到了什么。没有这一绑定，审计只能回答"改了什么"，回答不了"为什么这么改"。
MVP 五个 Action Type
第一阶段部署刻意只定义五个 Action，刚好覆盖一个跨部门任务闭环：创建任务、绑定责任、沉淀判断、受控共享、人工把关。先概览，再逐个展开。
| Action | 作用对象 | 典型发起者 | 前置审批 |
|---|---|---|---|
CreateWorkItem | WorkItem | 人 / Agent | 不需要 |
AssignAgent | WorkItem × Agent | 部门负责人 / 调度 Agent | 跨部门分配时需要 |
UpdateDecision | Decision | 被授权 Agent / 负责人 | 高影响决策需要 |
ShareContext | 任意对象 × Department | 对象所属部门 | 敏感对象类型需要 |
RequestApproval | 待批 Action 草案 | 人 / Agent | —（本身即审批入口） |
CreateWorkItemAction Type用途：在某个部门下创建一个 WorkItem，作为任务执行的受控入口。所有需要被追踪、分配和复盘的工作都从这里开始——没有对应工单的工作在系统中不存在。
| 参数 | 类型 | 必填 | 说明 |
|---|---|---|---|
title | string | 是 | 工单标题，一句话说清要完成什么 |
department_id | ref Department | 是 | 工单归属部门，决定可见性与可分配范围 |
description | string | 否 | 任务背景与完成标准 |
priority | enum low / normal / high | 否 | 默认 normal |
source_object | ref Lead / Decision | 否 | 触发本工单的来源对象，建立溯源 Link |
due_date | date | 否 | 期望完成时间 |
权限要求：发起者必须属于目标部门，或持有策略平面授予的跨部门创建权限。
副作用：创建 WorkItem 对象；建立 workitem-belongs-to-department Link；若提供 source_object，建立来源 Link；发布 workitem.created 事件。
写入 Action Log：action id、发起者身份、Agent 版本、上下文包版本、新对象 id、参数摘要。
AssignAgentAction Type用途：把一个 WorkItem 分配给某个 Agent 执行，建立明确的责任绑定。一个工单同一时刻只有一个负责 Agent——责任不清的工作不允许进入执行。
| 参数 | 类型 | 必填 | 说明 |
|---|---|---|---|
workitem_id | ref WorkItem | 是 | 待分配的工单 |
agent_id | ref Agent | 是 | 承接执行的 Agent |
reason | string | 否 | 分配理由，转移分配时建议填写 |
takeover | boolean | 否 | 是否接管已有分配，默认 false——已分配工单需显式声明转移 |
权限要求：发起者须对工单所属部门有写权限；目标 Agent 默认须属于同一部门，跨部门分配必须经 RequestApproval 获得策略平面批准。
副作用：建立或转移 workitem-assigned-to-agent Link；工单状态置为 in_progress；向目标 Agent Cell 的任务队列发布执行事件。
写入 Action Log：原分配与新分配的对比、发起者身份、分配理由、（跨部门时）批准记录 id。
UpdateDecisionAction Type用途：创建或更新一个 Decision 对象，把判断（go / no-go、优先级取舍、方案选择）沉淀为可审计的企业状态，而不是留在聊天记录或某个人的记忆里。
| 参数 | 类型 | 必填 | 说明 |
|---|---|---|---|
decision_id | ref Decision | 否 | 为空则新建决策，否则更新既有决策 |
workitem_id | ref WorkItem | 是 | 决策所回应的工单 |
outcome | enum go / no-go / hold | 是 | 决策结论 |
rationale | string | 是 | 决策理由——没有理由的结论不允许提交 |
evidence_files | ref File[] | 否 | 支撑决策的证据文件列表 |
权限要求：仅工单所属部门的负责人或被授权 Agent 可提交；标记为高影响的决策须先通过 RequestApproval 取得人工批准。
副作用：创建或更新 Decision 对象；建立 decision-resolves-workitem 与 decision-references-file Link；outcome 变化时广播 decision.updated 事件。
写入 Action Log：决策前后状态 diff、rationale 摘要、引用的证据文件列表、发起者与 Agent 版本。
ShareContextAction Type用途：把一个对象（或其摘要、字段子集）显式共享给另一个部门。部门文件系统默认隔离，ShareContext 与 Ontology Link 是仅有的两条跨部门读取通道——它让"共享"从默认状态变成显式动作。
| 参数 | 类型 | 必填 | 说明 |
|---|---|---|---|
object_id | ref 任意对象 | 是 | 被共享的对象 |
target_department_id | ref Department | 是 | 共享目标部门 |
scope | enum summary / fields / full | 是 | 共享范围：摘要 / 指定字段 / 全量属性 |
fields | string[] | scope=fields 时 | 允许读取的字段白名单 |
expires_at | datetime | 否 | 共享有效期，到期自动失效 |
权限要求：发起者必须属于对象所属部门；敏感对象类型的共享须策略平面规则显式允许。跨部门敏感数据共享规则属于禁止 Agent 自动演化的范围，调整必须人工审批。
副作用：创建带范围与有效期的共享 Link；目标部门的 Context Index 可检索到该对象的授权视图；不复制底层文件，原始数据始终留在所属部门。
写入 Action Log：共享对象 id、目标部门、范围与字段列表、有效期、发起者身份。
RequestApprovalAction Type用途：为高风险动作发起人工或策略审批。被审批的目标 Action 在批准前处于挂起状态，不产生任何副作用。它是"中央定义能力边界、人类保留最终把关"在 Action 层的落点。
| 参数 | 类型 | 必填 | 说明 |
|---|---|---|---|
subject_action | Action 草案 | 是 | 待批准的目标 Action 及其完整参数 |
approver | ref 人类负责人 / 策略规则 | 是 | 审批人或自动审批策略 |
risk_level | enum low / medium / high | 是 | 风险分级，决定审批时限与升级路径 |
justification | string | 是 | 申请理由：为什么需要执行该动作 |
权限要求：任何持有 Action 提交权限的身份均可发起；审批人必须已在策略平面注册，且不得与发起者为同一身份——Agent 不能批准自己的申请。
副作用：创建挂起的审批记录并通知审批人；批准后目标 Action 进入正常提交流水线执行；否决则丢弃草案，仅留审计记录。
写入 Action Log：完整审批链（发起 → 批准 / 否决）、审批人身份、justification、最终结果与目标 Action 的 action id。
Action 设计准则
定义新的 Action Type 时遵循三条准则。它们不是风格偏好，而是可靠性模型的直接要求——事件总线的重试、死信队列和故障恢复都依赖这些性质。
幂等Idempotent同一幂等键的重复提交只生效一次。事件总线支持重试与死信队列，意味着任何 Action 都可能被投递多次；不幂等的 Action 会在故障恢复时产生重复工单、重复分配和重复通知。
可回滚Reversible每个 Action 必须定义逆操作或补偿动作。无法回滚的动作（如生产环境破坏性操作）不允许以普通 Action 形式存在，必须经 RequestApproval 人工批准后执行，且全程留痕。
最小副作用Minimal Side Effects一个 Action 只做一件事。复合流程拆成多个 Action 串联，由事件驱动衔接——这保证审计粒度足够细，失败可以精确定位到某一步，回滚也不必牵连整条链路。
此外，Action 集合本身也在 Evolution Loop 的治理范围内：当观测发现重复的人工接管点或流程缺口时，可以提案新增 Action Type，经审批、灰度、度量后进入 Ontology。但高权限 IAM 策略、密钥管理与跨部门敏感共享规则永远排除在自动演化之外。
为什么禁止绕过 Action 直接改数据
技术上，给 Agent 一个数据库连接或文件系统写权限"更快"。但每一次绕过都在拆掉平台的地基：
绕过 Action Type 直接修改底层数据是平台的一级禁令。一次"图方便"的直接写入，会同时破坏审计链、权限模型与回滚能力——而且事后无法补救：没有进入 Action Log 的变更，永远无法回答"是谁、基于什么上下文、为什么改的"。
- 审计链断裂 — Action Log 的价值在于完备性：只要有一条变更不在账上，"账"就失去了证明力。复盘、合规与责任认定全部失效。
- 权限校验被架空 — 三层权限模型中的数据层校验发生在 Action 流水线里。直接写库等于把策略平面整个旁路掉，部门隔离名存实亡。
- 上下文版本无法绑定 — 直接变更不携带上下文包版本，事后无法还原决策依据，评估器也无法回放和改进上下文路由质量。
- 回滚不可能 — 没有 Action 记录就没有逆操作定义。混入直接写入的状态，连"回滚到哪个一致状态"都无法确定。
- 演化闭环失去输入 — Evolution Loop 依赖 Action Log 观测失败模式与流程缺口。绕过的变更对观测层不可见，组织失去从这部分工作中学习的机会。
正确的做法是：当现有 Action 不够用时，走演化流程新增或扩展 Action Type——而不是绕过它。流水线慢一点，是为换取整个系统可信。
相关阅读
- Action Log — Action 提交沉淀为可分析对象的完整机制
- Link Types — Action 创建与删除的关系定义
- Object Types — Action 所操作的对象类型
- 权限模型 — Action 校验所依据的三层权限
- Evolution Loop — Action 集合如何受治理地演化