# 37 · 共享上下文架构:让人和 Agent 读同一份事实 > 一句话点题:**AI 原生组织的核心接口,不是会议,而是共享上下文。** 人和 Agent 如果读不到同一份目标、规格、决策、任务、代码、反馈和 trace,协作就会退回“互相转述”和“各自猜测”。 --- > **🧩 AI 原生组织篇第 3 章 · 本篇讲什么** > > [36 章](36-超级个体与超级团队.md) 讲了人才密度和超级团队。但强个体聚在一起,不自动等于强组织。真正让人和 AI 可以协作的底座,是共享上下文。 > > 本章回答:AI 原生组织里,哪些信息必须成为组织接口?它们应该怎么流动、怎么沉淀、怎么防止过期? --- ## 一、上下文不是资料库,而是组织接口 很多团队以为“共享上下文”就是建一个知识库。结果往往变成: - 文档很多,但没人知道哪份是准的。 - 决策写过,但后续变更没同步。 - AI 能搜到一堆资料,但不知道哪些过期。 - 任务系统、代码、客户反馈、复盘互相断开。 这不是共享上下文,只是“资料堆”。 真正的共享上下文要回答三个问题: 1. **事实源在哪里**:这件事当前以哪份文档、任务、ADR、代码为准? 2. **为什么这么做**:关键取舍、放弃选项、风险边界有没有留下? 3. **AI 能怎么用**:这些信息能否被 Agent 检索、引用、执行和回写? 所以共享上下文更像接口,不是仓库: ``` 人类判断 ──写入──▶ 规格 / ADR / 任务 / 规则 │ ▼ Agent 执行与检查 │ ▼ trace / 结果 / 反馈 / 复盘 │ └──回写──▶ 新上下文 ``` 接口的价值在于减少反复沟通。共享上下文也是一样:让人和 AI 不必每次从头对齐。 --- ## 二、共享上下文应该包含哪些层 AI 原生组织至少需要六层上下文。 | 层 | 典型载体 | 作用 | |---|---|---| | **目标层** | 业务目标、客户问题、成功指标 | 告诉人和 AI 为什么做 | | **规格层** | PRD、验收标准、ADR、AGENTS.md | 把判断写成约束 | | **任务层** | backlog、Owner、状态、依赖 | 明确谁负责什么 | | **资产层** | 代码、设计稿、数据集、模板、Skill | 承接执行产物 | | **运行层** | Agent trace、工具调用、CI、eval | 看见 AI 做了什么 | | **学习层** | 复盘、事故、失败案例、最佳实践 | 把经验变成组织资产 | 这六层里,最容易被忽略的是运行层和学习层。 如果没有 trace,你只知道“AI 产出了结果”,不知道它用了什么输入、调用了什么工具、在哪里可能出错。 如果没有学习层,每次踩坑都只是个人经验,不会变成下一次的规则。 --- ## 三、规格是上下文里最硬的一层 [23 章](23-规格即架构约束怎么写给AI.md) 说过:规格即架构。放在组织层面,这句话更重。 因为组织里 AI 协作的问题,很多不是模型不聪明,而是规格不清楚: ``` 模糊目标:帮我优化增长 AI 默认补全:多发内容、多做活动、多打扰用户 清晰规格: - 目标:提升新用户第 7 天留存 - 禁止:不能增加强提醒和强制弹窗 - 成功指标:7 日留存 +3%,投诉率不升 - 验收:实验报告必须包含分层数据和负面影响 ``` 规格越清楚,AI 越像团队成员;规格越含糊,AI 越像一个会高速补默认值的实习生。 组织级规格至少要覆盖: - 业务目标和不做什么。 - 质量属性和验收标准。 - 权限边界和外发边界。 - 关键架构决策的原因。 - AI 执行时必须读取的规则。 这些规格不是一次写完的。它们应该随着项目、团队和事故复盘不断演进。 --- ## 四、上下文要可检索,也要可治理 把所有资料喂给 AI 不是共享上下文,而是扩大泄露面和噪声。 共享上下文要同时满足两个方向: **可检索**:人和 Agent 能找到需要的信息。 **可治理**:不是所有 Agent 都能看所有数据,不是所有旧文档都能继续影响新决策。 ``` 组织知识 │ ┌───────────┼───────────┐ ▼ ▼ ▼ 公开资料 内部资料 敏感资料 │ │ │ 默认可检索 按团队授权 临时授权 + 审计 ``` 治理重点有四个: 1. **权限分级**:客户数据、员工信息、财务、代码、合同不能一把梭。 2. **来源标注**:AI 引用外部网页、客户邮件、历史文档时,必须知道来源。 3. **时效管理**:过期规则比没有规则更危险。 4. **回写规范**:Agent 不能随便改事实源;高影响回写要人审。 共享上下文不是越多越好,而是**正确的信息在正确权限下被正确使用**。 --- ## 五、一个最小可行的共享上下文架构 MVP 阶段不需要大中台。一个小队可以从很轻的结构开始: ``` 客户问题 / 业务目标 │ ▼ PRD / ADR / AGENTS.md / 验收标准 │ ├──▶ 任务系统:Owner、状态、依赖 │ ├──▶ 代码 / 设计 / 数据资产 │ └──▶ Agent / Skill 执行 │ ▼ trace / review / eval / 复盘 │ └──回写规则和知识库 ``` 这张图的关键不在工具,而在闭环: - 目标进入规格。 - 规格驱动任务和 Agent。 - Agent 产出进入审查和评测。 - 结果和失败案例回写规则。 只要这个闭环跑起来,哪怕工具很朴素,组织也开始拥有 AI 原生的上下文结构。 --- ## 🎯 随堂检验 --- ## 本章小结 - **共享上下文是组织接口**:它减少人和 AI 的重复对齐。 - **至少六层上下文**:目标、规格、任务、资产、运行、学习。 - **规格是最硬的一层**:模糊目标会让 AI 高速补默认值。 - **可检索必须配治理**:权限、来源、时效、回写都要有边界。 - **MVP 不需要大中台**:先让目标、规格、任务、Agent、trace、复盘形成闭环。 > **承上启下**:本章讲“人和 Agent 读什么”。下一章 [38 · AI 工作流架构](38-AI工作流架构.md),我们继续讲“人和 Agent 怎么一起做事”:如何把个人 prompt 升级为可复用 Skill、工作流和 Golden Path。 --- ## 相关链接 - 前置章节:[23 · 规格即架构](23-规格即架构约束怎么写给AI.md) · [24 · 审查清单](24-审查清单AI产出默认缺什么.md) - 技术模板:[AI Agent / 工作流平台](../templates/ai-agent-platform/README.md) · [系统提示词架构](../templates/system-prompt-architecture/README.md) - 参考实践:[那些跑通 AI 变革的团队做对了什么?](https://www.bestblogs.dev/article/202b38ee)