部署 MVP 路径

第一阶段不要直接做全企业平台。本手册给出一条最小闭环部署路径：两个部门、两个 Agent Cell、七个 Ontology 对象、五个 Action Type、一个 Context Gateway 原型、一条审计链——最后用一个跨部门任务串通全链路。

// 最小闭环原则

MVP 的目标不是覆盖面，而是闭环：让"Agent 请求上下文 → 受控执行 → Action 提交 → 审计留痕 → 跨部门协作"这条链路在最小规模上真实跑通一次。链路通了，扩展只是重复；链路不通，规模只会放大问题。

为什么从最小闭环开始

分布式 Agent Ontology 架构（见 架构总览）有六层、十种对象、多套协议。如果第一步就追求完整，会同时面对 Ontology 建模、权限设计、运行时部署和组织变更四类风险。最小闭环把这四类风险压缩到可控规模：

七步总览

#步骤核心产出
1选择两个部门试点部门与各自负责人
2每部门一个 Agent Cell两个隔离的运行单元与文件空间
3定义最小 Ontology七个 Object Type 及其关系
4定义五个 Action Type全部状态变更的受控入口
5建立 Context Gateway 原型按身份与权限返回最小上下文
6建立审计链每次执行可复盘的五字段记录
7跑通一个跨部门任务全链路验证与复盘报告

逐步详述

第一步：选择两个部门

选两个有真实协作关系、且数据敏感度可控的部门。框架建议的组合是 Strategy 和 Marketing：Marketing 持续产生线索（Lead），Strategy 需要基于线索做判断（Decision），两者之间存在天然的"共享一部分、隔离一部分"的边界——这正是 MVP 要验证的核心场景。每个部门指定一位人类负责人，作为后续 Action 审批与异常接管的责任人。

// 验收标准

两个部门各有一位明确的人类负责人；两部门之间存在至少一个真实的协作场景，且能说清哪些信息可共享、哪些必须隔离。

第二步：每个部门一个 Agent Cell

为每个部门建立一个 Agent Cell——最小自治部署单元，包含 Agent Runtime、部门私有文件系统、部门上下文索引和权限适配器。MVP 阶段的关键是隔离而不是规模：每个 Cell 一个独立文件目录，AWS 环境下对应每部门一个 EFS 实例或一个 S3 prefix，运行时可用 ECS/Fargate 或 Lambda 起步（完整映射见 AWS 部署）。两个 Cell 之间不允许直接读取对方文件。

// 验收标准

两个 Cell 各自能在自己的文件空间内完成读写任务；从任一 Cell 尝试直接访问另一部门的文件目录会被拒绝，且拒绝行为有日志。

第三步：定义最小 Ontology（七个对象）

不做大一统建模，只定义支撑试点任务所需的七个 Object Type（概念详见 Object Types）：

DepartmentObject Type

部门实体，是权限和文件空间的第一边界。MVP 中只有两个实例。

AgentObject Type

运行中的 Agent 实体，记录其所属部门、版本与职责范围。Agent 本身是 Ontology 中的对象，而不只是基础设施。

FileObject Type

部门文件系统中被纳入语义层的文件，带所属部门与访问级别属性。

WorkItemObject Type

可分配、可流转的工作单元，是跨部门协作的载体。

DecisionObject Type

结构化的决策记录：决策内容、依据、责任人。MVP 试点任务的最终产出就是一个 Decision 对象。

Customer / LeadObject Type

客户与线索实体，是 Marketing 与 Strategy 之间被受控共享的对象。

ActionLogObject Type

动作提交本身作为可分析对象沉淀，用于审计、复盘和后续决策（详见 Action Log）。

// 验收标准

七个对象类型都有 schema 定义和至少一个真实实例；对象之间的关系（如 Agent 属于 Department、Decision 引用 Lead）以 Link 显式表达，而不是埋在文件内容里。

第四步：定义五个 Action Type

MVP 中所有企业状态变更必须通过这五个受控动作提交，不允许绕过审计直接改底层数据（概念详见 Action Types）：

Action Type作用典型发起者
CreateWorkItem创建一个工作单元，进入待分配状态任一 Agent / 人类负责人
AssignAgent把 WorkItem 分配给某个 Agent 执行部门负责人 / 编排逻辑
UpdateDecision创建或更新一条决策记录Strategy Agent
ShareContext把某个对象的摘要受控共享给另一部门对象所属部门的 Agent
RequestApproval请求人类负责人批准一个高风险动作任一 Agent
// 验收标准

每个 Action Type 有明确的输入、权限要求与副作用定义；每次提交都生成一条 ActionLog 记录，绑定发起者、Agent 版本与上下文包版本；尝试绕过 Action 直接修改对象状态的路径已被技术性封死。

第五步：建立 Context Gateway 原型

实现一个最简版本的 Context Gateway：输入是任务意图与发起者身份，输出是该身份被允许访问的对象、文件和可执行 action 列表。原型不需要复杂的检索与压缩策略，但必须严格执行权限过滤——Agent 通过 Gateway 拿到的是最小可用上下文包，而不是"全库搜索"的结果。这一步同时验证 权限模型 的数据层：跨部门读取必须通过 Ontology link 或显式共享对象。

// 验收标准

同一个任务请求，以不同部门身份发起，返回的上下文包不同；任何返回的对象、文件、action 都能追溯到一条明确的权限依据；每个上下文包有版本号，可被审计链引用。

第六步：建立审计链

每次 Agent 执行都记录五个字段，构成可复盘的最小审计单元：

字段记录内容
task id本次执行对应的任务标识
context package idAgent 拿到的上下文包版本，回答"它当时看到了什么"
action id提交的 Action 标识，回答"它改变了什么"
file diff文件层面的实际变更摘要
tool summary工具调用摘要，回答"它是怎么做到的"

审计链的设计原则是可复盘而非全量留存：ActionLog 只记录可复盘摘要，不保存全部敏感上下文。每个 Cell 保留本地审计缓冲，即使中央日志短暂不可用也不产生审计缺口（见 可靠性模型）。

// 验收标准

任选一次历史执行，仅凭审计记录就能回答四个问题：谁发起的、它看到了什么、它做了什么、结果改变了什么。回答不了任何一问，审计链就不算建成。

第七步：跑通一个跨部门任务

用一个真实的跨部门任务串通全链路。框架给出的标准剧本（示例场景）：

  1. Marketing Agent 发现 lead

    Marketing Agent 在自己的 Cell 内识别出一条新线索，通过 CreateWorkItem 创建评估任务，并以 ShareContext 把允许共享的 lead 摘要开放给 Strategy 部门——原始资料仍留在 Marketing 的文件空间内。

  2. Strategy Agent 读取共享摘要

    Strategy Agent 通过 Context Gateway 请求上下文，拿到的包里只有被显式共享的 lead 摘要与相关历史决策，看不到 Marketing 的其他文件。

  3. 生成 go / no-go 决策

    Strategy Agent 基于摘要与战略上下文生成判断，通过 UpdateDecision 提交决策记录；若判定为高风险，先经 RequestApproval 由人类负责人批准。

  4. ActionLog 记录全过程

    从线索创建到决策落地，每一步的 task id、context package id、action id、file diff 与 tool summary 都已入链，整个决策过程可以被完整回放。

// 验收标准

任务端到端跑通且全程无人工搬运数据；Strategy 侧拿到的上下文不多于被共享的范围；事后仅凭 ActionLog 即可向第三方完整复述这次决策是如何做出的。这三条同时满足，MVP 闭环宣告完成。

风险与缓解

MVP 阶段的六个关键风险及对应缓解措施：

风险缓解
Ontology 设计过重从 6–8 个对象类型开始，不做大一统建模
权限过细导致不可用先按部门和对象级权限，逐步扩展字段级权限
Agent 自演化失控所有策略变更必须有 proposal、approval、rollback
上下文路由质量差记录每次 context package，用评估器回放
成本失控部门 Cell 按需扩缩容，低频任务走短生命周期 worker
审计不可读ActionLog 只记录可复盘摘要，不保存全部敏感上下文

下一步扩展

MVP 闭环验证通过后，沿四个方向有序扩展，每个方向都以"复制已验证的模式"为原则，而不是重新设计：

  1. 横向扩部门——按同样的 Cell 模板把更多部门接入，目标形态是与 C-suite 文件系统 对齐的十个职能 Cell；每接入一个部门，复用第七步的跨部门任务作为验收。
  2. 纵向扩 Ontology——按真实任务需要新增 Object Type、Link Type 与 Action Type，并引入 Interfaces 让同类对象共享能力形状；坚持"任务驱动建模"，不预先建大模型。
  3. 权限精细化——从部门级、对象级权限逐步扩展到字段级权限与工具级权限，完整形态见 权限模型。
  4. 接入演化闭环——把 Observation → Diagnosis → Proposal → Approval → Deployment → Measurement → Ontology Update 的受治理演化流程接入日常运行，让 prompt、检索策略、Ontology schema 和 SOP 随使用持续改进，详见 Evolution Loop。

相关阅读