Agent Cell

Agent Cell 是平台的最小自治部署单元。每个部门拥有一个或多个 Cell，各自带着独立文件系统、权限边界和审计日志运行在隔离的 AWS 环境中，在企业语义层下自治执行本部门的文件、任务与自动化。

// 定义

Agent Cell = 一个部门级自治执行单元。它不是一个聊天机器人，而是"运行时 + 文件系统 + 上下文索引 + 权限适配 + 事件通道 + 审计缓冲"的完整组合。部署一个部门的 AI 能力，就是部署一个 Cell。

为什么以 Cell 为部署单元

在六层架构中，Cell 位于 L4，是执行真正发生的地方。选择 Cell 而不是中央超级 Agent 作为部署单元，带来三个直接收益：

授权可成立 — 部门文件系统默认隔离，权限边界与组织边界重合。授权一个 Cell，就是授权一段明确的职责，而不是把全企业上下文交给单点。
故障可隔离 — 单个部门 Cell 不可用，只影响该部门，不拖垮全局系统；同一 Cell 内单个 worker 崩溃，其他 worker 接管队列任务。
责任可审计 — 每个 Cell 有独立审计日志。任何动作都能回答"哪个部门的哪个 Agent，基于哪个版本的上下文，做了什么"。

这与 Company Harness 的目录原则一脉相承：目录天然承担权限边界，Cell 把这条原则物理化为隔离的运行环境。

六个组成部分

一个 Agent Cell 由六个组成部分构成，缺一不可：

Agent Runtime执行核心

执行任务、调用工具、维护本地状态。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，就是把这套目录结构按部门实例化到隔离的运行环境中。