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