Agent Cell
Agent Cell 是 AIDC 平台的最小自治部署单元——相当于为每个部门配备一支有独立办公室、明确岗位说明书和完整工作台账的数字团队。权限边界与组织边界重合，故障互不传染，每一步操作都有据可查。
把一个 Agent Cell 想象成一间带门禁的部门办公室：里面有真正动手干活的执行核心、部门自己的文件柜、内部资料目录、门禁系统、收发室和工作台账。给一个部门部署 AI 能力，就是给它配一间这样的办公室——而不是把全公司的钥匙交给一个万能机器人。
Agent Cell = 一个部门级自治执行单元。它不是一个聊天机器人，而是「运行时 + 文件系统 + 上下文索引 + 权限适配 + 事件通道 + 审计缓冲」的完整组合。部署一个部门的 AI 能力，就是部署一个 Cell。
为什么以 Cell 为部署单元
很多企业引入 AI 的第一反应，是建一个「什么都能干」的中央超级 Agent。AIDC 的选择恰恰相反：在 六层架构 中，Cell 位于 L4，是执行真正发生的地方——以部门为单位部署，而不是以「一个全能大脑」为单位。这个选择直接换来三项管理者最关心的收益：
- 授权可成立 — 部门文件系统默认隔离，权限边界与组织边界重合。授权一个 Cell，就像在公司里授权一个岗位：交出去的是一段明确的职责，而不是把全企业的资料交给单点。
- 故障可隔离 — 单个部门 Cell 不可用，只影响该部门，不拖垮全局系统，正如一个部门停摆不应让全公司停摆；同一 Cell 内单个 worker 崩溃，其他 worker 接管队列任务。
- 责任可审计 — 每个 Cell 有独立审计日志，相当于每个部门有自己的工作台账。任何动作都能回答「哪个部门的哪个 Agent，基于哪个版本的上下文，做了什么」。
这与 Company Harness 的目录原则一脉相承：目录天然承担权限边界，Cell 把这条原则物理化为隔离的运行环境——制度上的「部门边界」，在基础设施层变成了真实的墙。
六个组成部分
一个 Agent Cell 由六个组成部分构成，缺一不可。可以把它们对应到一间部门办公室的六件「标配」：干活的人、文件柜、资料目录、门禁、收发室和台账：
Agent Runtime执行核心Cell 里真正「动手干活」的部分：执行任务、调用工具、维护本地状态。Runtime 是 Cell 中唯一会思考的组件——接收任务、向 Context Gateway（资料分发的统一受控入口）请求上下文、按上下文包执行、通过受控 Action Type 提交变更。长驻任务跑在 ECS/Fargate 或 EKS 上，短任务用 Lambda 起短生命周期 worker。
Local File System工作记忆部门私有文件系统，相当于部门自己的文件柜，是该 Cell 的主要工作记忆。任务输入落地、过程产物、交付结果都以文件形式存在，文件系统启用版本化与备份。它对应 Harness 中「文件优先」的原则：不能落入文件系统的信息，就不是组织资产。
Department Context Index本地索引部门内部的资料目录：只索引本部门允许访问的文档、对象和历史。索引范围被权限边界裁剪，因此 Cell 的本地检索天然不会越权；跨部门的上下文不走本地索引，必须经 Context Gateway 按 Ontology（企业的数字台账＋组织说明书）与策略生成。
Permission Adapter权限适配门禁系统的本地执行者：把中央策略转换成本地文件、API、工具权限。Policy & Identity Plane 只定义能力边界，Adapter 负责把这些边界落到 Cell 内部——哪些目录可写、哪些 API 可调、哪些工具可用。策略更新时由 Adapter 同步，而不是改 Cell 的代码，正如调整门禁权限不需要重新装修办公室。详见 权限模型。
Event Consumer / Producer事件通道部门的收发室：订阅企业事件，发布执行结果。这是 Cell 与外部世界的异步接口——任务到达、跨部门通知、执行完成都走事件总线（EventBridge / SQS / SNS），支持重试、死信队列和幂等消费，确保「公文」不丢、不重、不乱。
Local Audit Buffer审计缓冲部门的本地台账：即使中央日志短暂不可用，也能保留本地审计链。所有动作先写本地缓冲，再异步汇入中央 Action Log（全企业统一的操作总账）；中央恢复后补发，避免审计缺口。这是可靠性设计的一部分，见 可靠性与降级。
Cell 之间如何协作
Cell 默认互相隔离——部门文件系统不互通，本地索引不越权。协作不靠「打开权限」，而是走三条受控通道，就像部门之间不互相翻文件柜，而是走正式的公文流转与审批流：
| 通道 | 机制 | 典型用途 |
|---|---|---|
| 企业事件 | Cell 通过事件总线发布执行结果、订阅其他部门的事件，异步解耦，支持重试与幂等消费 | 任务交接、状态通知、跨部门流程编排 |
| Ontology link | 跨部门读取必须通过 Link Type 定义的关系路径，由 Context Gateway 按权限组装进上下文包 | 读取其他部门对象的受控摘要，如「项目—客户—合同」链路 |
| 显式共享对象 | 通过 ShareContext 这类受控 Action Type 显式共享某个对象的指定视图，共享行为本身写入 Action Log | 把一个 lead 摘要、一份决策共享给特定部门 |
跨部门读取必须通过 Ontology link 或显式共享对象；Agent 写入企业关键状态必须走 Action Type，不允许绕过审计直接改底层表。所有 Action 提交都写入 Action Log，并绑定发起者、Agent 版本、上下文包版本和工具调用摘要。
示例场景：Marketing Cell 发现一个 lead 并发布事件；Strategy Cell 订阅到事件后，经 Context Gateway 读取允许共享的 lead 摘要，生成 go/no-go 决策；整个过程由 Action Log 记录决策链路。两个 Cell 全程没有读过对方的文件系统——协作发生了，边界没有破。
AWS 资源映射
Cell 的每个能力都有推荐的 AWS 落点。隔离边界用账号、VPC 与 IAM 物理化——相当于把「部门之间不得越权」写进机房硬件，而不是仅靠制度自觉：
| Capability | AWS Candidate |
|---|---|
| Agent Runtime | ECS/Fargate、EKS，短任务用 Lambda |
| Department File System | 每部门独立 EFS，或每部门独立 S3 prefix |
| Secrets | AWS Secrets Manager、KMS |
| Network Isolation | VPC、subnet、security group、private endpoint |
| Eventing | EventBridge、SQS、SNS |
| Logs & Metrics | CloudWatch、OpenTelemetry collector |
| Identity | IAM Identity Center、IAM roles、session policies |
完整的网络拓扑、账号划分与部署步骤见 AWS 部署映射。
水平扩展与隔离性
Cell 的稳定性来自「复制」与「隔离」两个正交设计：复制保证业务高峰时忙得过来，隔离保证出了问题不传染：
- Cell 内水平复制 — Agent Cell 可水平复制，同一个部门可运行多个 runtime worker，共享同一个部门文件系统与上下文索引；单个 worker 崩溃，其他 worker 从队列接管任务，业务不中断。
- Cell 间故障隔离 — 部门之间不共享运行时与存储，单个 Cell 不可用只影响该部门；中央 Context Gateway 短暂不可用时，Cell 仍可处理低风险本地任务，高风险动作暂停等待恢复。
- 按需扩缩容 — 部门 Cell 按负载扩缩容，低频任务走短生命周期 worker（Lambda），避免为偶发任务长期占用计算资源，把成本控制在与业务量匹配的水平。
- 事件与审计的降级路径 — Event Bus 延迟时，本地 action buffer 保留状态，恢复后补发；中央日志故障不会造成审计缺口。完整降级策略表见 可靠性与降级。
Cell 的目录结构示例
以下是一个部门 Cell 的文件系统布局（示例场景，以 Marketing 部门为例）。六个组成部分各自对应清晰的目录落点，AGENT.md 相当于这间办公室门口的岗位说明书——声明 Cell 的所有者、职责范围与读写边界：
marketing-cell/
├── AGENT.md # Cell 所有者、职责范围、可读写边界
├── runtime/
│ ├── agent.config.yaml # 模型、工具、worker 并发配置
│ └── tools/ # 本 Cell 注册的工具与脚本
├── workspace/ # Local File System：部门私有工作记忆
│ ├── inbox/ # 外部输入落地区
│ ├── tasks/ # WorkItem 工作目录（每任务一个子目录）
│ └── deliverables/ # 交付产物（启用版本化与备份）
├── context/
│ ├── index/ # Department Context Index：本部门可访问范围的索引
│ └── packages/ # Context Gateway 返回的上下文包缓存（带版本号）
├── permissions/
│ └── policy.cache.json # Permission Adapter 同步的本地策略快照
├── events/
│ ├── subscriptions.yaml # Event Consumer：订阅的企业事件清单
│ └── outbox/ # Event Producer：待发布的执行结果
└── audit/
└── buffer/ # Local Audit Buffer：中央日志不可用时的本地审计链这个布局与 C-suite 文件系统 的治理原则一致：每个目录有唯一所有者，权限按目录授予，所有变更可追踪。把一个组织部署为多个 Cell，就是把这套目录结构按部门实例化到隔离的运行环境中。
上线一个 Cell 前的检查清单
把一个部门 Cell 投入运行之前，建议逐项确认以下事项。六项分别对应 Cell 的六个组成部分——任何一项缺失，都意味着职责、权限或审计存在缺口（示例清单，可按企业实际裁剪）：
- 职责声明 —
AGENT.md是否写明 Cell 的唯一所有者、职责范围与可读写边界？没有岗位说明书，就不该有这个岗位。 - 权限落地 — Permission Adapter 是否已同步中央策略？可写目录、可调 API、可用工具是否与该部门的职责一一对应？
- 索引范围 — 本地上下文索引是否只覆盖本部门允许访问的内容？所有跨部门读取是否都经 Context Gateway，而非本地越权检索？
- 事件接线 — 订阅与发布的事件清单是否已声明？重试与死信队列是否配置，确保任务交接不丢、不重？
- 审计链路 — 本地审计缓冲是否启用？每个动作是否汇入中央 Action Log，并绑定发起者、Agent 版本与上下文包版本？
- 降级预案 — 中央服务不可用时，哪些低风险本地任务可以继续、哪些高风险动作必须暂停，是否有明确清单？参见 可靠性与降级。
相关阅读
- 六层架构总览 — Cell 在整体架构中的位置（L4）
- Context Gateway — Cell 获取上下文的唯一受控入口
- 权限模型 — Infrastructure / Data / Tool 三层权限如何落到 Cell
- Action Types — Cell 改变企业状态的受控通道
- 部署 MVP — 从两个部门 Cell 开始的最小闭环