Action Types
Action Type 让企业获得一项关键能力：任何改变企业状态的操作——创建工单、更新决策、触发审批、共享上下文——都必须走同一道受控通道提交，像规范的审批流一样有据可查。每次提交都绑定发起者、Agent 版本与上下文包版本，并写入 Action Log；权限有边界、操作可追溯，由机制保证，而不是靠自觉。
可以把 Action Type 理解为企业的“标准化审批单”：无论员工还是 AI，想改动公司的正式台账，都必须填一张结构化的单子——写清楚要做什么、凭什么有权做、做完留下什么记录。每一笔变更有名有据，复盘与问责不再依赖任何人的回忆。
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。
示例场景：一条线索如何走完闭环
以下为示例场景：市场部的一条销售线索（Lead）需要技术部评估可行性。五个 Action 串成一条协作链，每一步都有据可查：
- 创建任务 — 市场部 Agent 通过
CreateWorkItem基于该线索创建评估工单，source_object指向 Lead，溯源 Link 自动建立。 - 申请跨部门分配 — 评估须由技术部承接，属于跨部门分配；调度 Agent 先发起
RequestApproval，由技术部负责人批准。 - 绑定责任 — 批准后通过
AssignAgent把工单分配给技术部的评估 Agent，责任归属唯一且明确。 - 受控共享资料 — 评估需要线索详情，市场部通过
ShareContext以scope=fields共享必要字段，敏感报价字段不在白名单内。 - 沉淀判断 — 评估完成，技术部负责人通过
UpdateDecision提交 go 结论、理由与证据文件；decision.updated事件通知市场部继续推进。
整条链路结束后，Action Log 中留下五条相互关联的记录：谁发起、谁批准、Agent 当时看到了什么、为什么这么判断。三个月后复盘这条线索，不需要找任何当事人回忆。
Action 设计准则
定义新的 Action Type 时遵循三条准则。它们不是风格偏好，而是可靠性模型的直接要求——事件总线的重试、死信队列和故障恢复都依赖这些性质。
幂等Idempotent同一幂等键的重复提交只生效一次。事件总线支持重试与死信队列，意味着任何 Action 都可能被投递多次；不幂等的 Action 会在故障恢复时产生重复工单、重复分配和重复通知。
可回滚Reversible每个 Action 必须定义逆操作或补偿动作。无法回滚的动作（如生产环境破坏性操作）不允许以普通 Action 形式存在，必须经 RequestApproval 人工批准后执行，且全程留痕。
最小副作用Minimal Side Effects一个 Action 只做一件事。复合流程拆成多个 Action 串联，由事件驱动衔接——这保证审计粒度足够细，失败可以精确定位到某一步，回滚也不必牵连整条链路。
新增 Action Type 前的检查清单
当现有五个 Action 不够用时，新 Action Type 的提案应先过一遍下面的清单。它把三条设计准则落成可执行的检查项，帮助评审者在 Action 进入 Ontology 之前发现设计缺陷：
- 参数显式 — 所有输入是否都在 schema 中显式声明，没有“执行时再看情况”的隐式依赖？
- 前置可校验 — 权限与状态前置条件能否由策略平面自动校验，而不是依赖发起者自觉？
- 职责单一 — 该 Action 是否只做一件事？需要多步的流程是否已拆成多个 Action 由事件衔接？
- 幂等安全 — 同一幂等键重复提交是否只生效一次？故障重试不会产生重复工单或重复通知？
- 回滚就绪 — 逆操作或补偿动作是否已定义？无法回滚的部分是否强制经
RequestApproval人工批准？ - 审计完备 — log-schema 是否足以回答“是谁、基于什么上下文、为什么改的”，同时不记录不应留存的敏感内容？
此外，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 集合如何受治理地演化