上下文已成平台能力：内部平台团队的新责任

观察一个开发者在真实的企業项目上启动 Agent 会话，你会看到一套固定流程。在写出第一个有用的 prompt 之前，他们会先收集材料：粘贴部署标准、链接运维手册、解释各严重性分级的含义。然后纠正 Agent 的第一个自信猜测——关于团队两年前就已废弃的某个命名规范。第二天他们会再来一遍，因为 Agent 不会记住。

我们悄无声息地达成了一个共识：这套收集工作就是开发者的活儿。每一部与 AI 共事的指南都在重复同一类建议：给模型好的上下文。于是开发者们一个会话接一个会话地四处搜寻，跨越那些从未被设计成能回答 Agent 问题的系统。

我认为这种框架把问题弄反了，而且解决它属于平台层面工作。

在《你的平台有了新用户：Agent》一文中，我提出内部平台现在服务两类角色：开发者，以及开发者的 Agent。文章末尾我写道，上下文正在成为平台的一部分。我称之为未来几年最重要的开发者体验问题之一。那个想法只占了四段话。它值得一篇完整的文章来展开，所以这里就是那个更长版本。

收集是一种隐性税

Agent 现在能记住的东西比以往更多了。它们无法可靠积累的是组织层面的真相。

一个新工程师付一次入职成本，然后在多年的上下文积累、走廊闲聊和踩坑经历中分摊它。Agent 可能保留指令、记忆或项目状态。这些都不能自动告诉它哪个标准是权威的、哪个例外仍然有效，或者哪个决策在半年前被推翻了。关于你的组织，Agent 需要知道的一切仍然需要从某个地方获取。

把这个数字乘以成百上千名工程师。人们日复一日地重新发现相同标准、分叉相同仓库、重复粘贴相同运维手册、重新输入相同纠正。你的最强工程师能拼凑出极佳上下文并获得极佳输出。其他人得到的是搜索索引返回的第一个结果——通常是一份三年前的 wiki 页面，仍然排在当前标准之前。

这里有个应该让平台负责人不爽的点：这种税随着采纳而增长。你的 AI 推广越成功，你的组织做的手工组装就越多。成功让问题变得更大了。

团队已经在用仓库投票表态。每一个 CLAUDE.md、每一个 AGENTS.md、每一套 AI 规则，都是开发者在逐个仓库地手工构建一个上下文层。当许多团队独立构建了相同的脚手架，一个平台能力就在那里等着被认领。我们之前见过这种剧本——构建脚本、部署工具、可观测性配置。上下文是下一个。

平台负责人之问

这里是我一直回归的问题：谁让组织的知识对 Agent 可用？在大多数公司，今天的诚实答案是每个开发者、在每个会话中，简称就是没有人。

想想一个 Agent 在企业内部做真实工作需要什么。它需要服务归属和依赖信息。它需要批准的架构模式，以及与每个应用层级配套的部署要求。它需要 API 定义、安全分类、可观测性约定、命名标准、环境详情、编码规范、运维手册，以及足够的运维历史来知道哪个集成测试一直是 flaky 的。

我在上一篇文章中列出了所有这些所在之处：Git、开发者门户、Confluence、工单、Slack 以及人们的脑袋。分散不是什么新消息。Agent 改变了分散的代价，因为 Agent 不能走到你桌前提问。

平台问题不是开发者如何更快地收集所有这些。平台问题是为什么要由他们来收集。

平台团队的存在是为了把每个交付团队本应吸收的工作转化为共享能力。上下文组装现在完全符合这个描述。读过那本书的读者会认出这个本能：这就是"上下文脊柱"（Context Spine）论点，在组织规模上运作。

Trusted（可信）是关键词

企业淹没在上下文之中。稀缺资源是可信的上下文。

诱人的做法是爬虫、向量数据库加聊天窗口。在周五演示一下，指向公司曾经写过的所有东西。我理解这种吸引力。它解决了发现问题，但发现不等于权威。

没有权威模型的检索只是排序。检索系统可以找到已废弃的标准、被放弃的实验和当前需求并列在一起。它甚至可以智能地给它们排序。但它自己无法知道组织选择了哪个答案来支撑。把矛盾的指导喂给 Agent，它会产生自信的矛矛盾，比任何人类都快。

所以平台的工作是策展，而"可信"必须意味着某种具体的东西。我会用一个上下文层要求六个属性。

**Canonical（权威）**意味着组织有意识地为每个问题选定了一个答案。如果线上存在五种部署模式，这个层知道哪三种是受支持的，哪两种是考古遗迹。**Versioned（版本化）**意味着标准携带历史，这样 Agent 知道服务发布时哪条规则适用。**Fresh（新鲜）**意味着陈旧度像可用性一样被测量，而不是在事故中被发现。

**Attributable（可溯源）**意味着每个答案都能追溯到来源和负责人，所以一个错误答案变成了一张有收件人的缺陷报告。**Accessible（可访问）**意味着机器可读且可通过真实接口查询，这样 Agent 去问而不是去抓取 prose 并祈祷。**Safe（安全）**意味着上下文继承它所描述的系统的访问控制。安全分类不会因为检索变得方便就停止适用。

再读一遍这个列表，注意它的形状。这些是我们已经对任何生产 API 都要求具备的属性，这就是重点。上下文值得与我们对所描述系统相同的工程纪律。

上下文有了负责人和接口

把上下文作为平台能力来对待，会改变三件事。

第一，上下文有了接口。Agent 查询服务目录、标准端点或策略引擎，而不是抓取文档。Model Context Protocol 服务器是一种管道选项，纯版本化 API 同样可用。管道会变化。背后的权威模型才是只有你的组织能提供的部分，也是持久存在的部分。

第二，上下文有了负责人。每个权威答案都附有一个名字，漂移成为那个负责人的缺陷，废弃成为一次真实的操作。这份工作的一半是降级和删除。旧模式被标记为已替代，并指向其替代者，而不是在搜索结果顶部再徘徊三年。

这也让上下文能够在最初了解它的人们离开后继续存在，这是任何好的平台的隐性工作之一。架构师换岗、主题专家离职、团队重组。最好的平台把那些人所知的东西转化为继承的能力。正确的路径不再依赖恰好记得为什么做出某个决定的人。

第三，上下文有了执行力。我在上一篇文章中写过，标准活在系统中比活在文档中更有价值。这里同样如此。部署时要求的归属元数据是有牙齿的上下文，拒绝不合规清单并给出修复方案的策略引擎也是有牙齿的上下文。Wiki 页面只是一条建议。

云平台标准化了基础设施。下一个平台层标准化了上下文。

常见的反对意见

这就是文档工作加了几个步骤而已。我会反过来：文档是一个没有任何步骤的上下文层。文档描述，上下文层回答并执行。没有人会因为 wiki 页面变旧而被叫醒，也没有人会因为 README 与自动化矛盾而导致流水线失败。关于服务归属的页面和要求归属元数据的部署门之间，隔的是建议与基础设施之间的距离。

上下文窗口在不断增长。很快 Agent 就能读完一切。更长的窗口改变了你喂给模型的信息量。它解决不了你喂的东西是否真实、是否最新、或者请求者是否有权查看。把一百万 token 的矛盾指导灌进一个更大的窗口，你得到的是同样矛盾但篇幅更长。丰盛让策展更有价值，正如丰盛生成让约束更有价值。

供应商会解决这个问题。供应商会交付更好的协议和更好的检索，我都会欣然使用。没有供应商会打包发来你的组织恰好支持三种部署模式的知识，或者你们公司的 F 级意味着什么。权威不在盒子里。

从令人尴尬的小处开始。写下你的 Agent 和新工程师最常问的十个问题。这两个列表的重叠会让你不太舒服，这本身就是一课：Agent 就绪和开发者体验原来是同一件事。

对于每个问题，指定一个负责人并选择一个单一的权威来源。让那个来源通过你的 Agent 已经使用的接口可查询，然后把副本降级。用你衡量可用性的方式衡量新鲜度。当一个 Agent 从你自己的上下文里拉出一个错误答案时，把它归档为平台缺陷，因为它本来就是。

一个具体的第一步：从平台本身生成团队 Agent 指令文件的共享部分。团队越来越倾向于把组织上下文手写进 CLAUDE.md、AGENTS.md 和类似文件，然后依赖某人来保持最新。归属、层级、批准的模式和部署路径通常都是平台已经知道的事实。让平台来写文件的那部分，让团队保留本地知识，这样新鲜度就不再依赖任何人的记忆。

我们花了上一个十年构建平台，让开发者不再手工组装基础设施。这篇文章开头的收集仪式是同样的问题，只是往上一层。

把可信上下文作为平台能力来对待的组织，将通过平台让他们的 Agent 只需入职一次。其他所有人将继续手工做入职，一个会话接一个会话。

最初发表于 vinny.dev，我在那里每周写一篇关于工程领导力和 Agentic SDLC 的文章。本文是《你的平台有了新用户：Agent》的姊妹篇。