上下文版GitHub尚不存在

# 上下文的GitHub尚不存在 来源：https://contextandchaos.substack.com/p/the-github-for-context-doesnt-exist [](https://substackcdn.com/image/fetch/$s_!T0ad!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb1d9eed8-53f6-4172-88bf-d596095792a7_1672x941.png)上下文层到底是什么，AI Engineer World's Fair 2026，上下文工程分论坛 | 来源：作者与 AI Engineer Worldfair 去年年中，我们大约五分钟就能构建一个智能体。但要给它注入足够的业务上下文，使其准确，却需要花费无穷无尽的时间。在随后的十二个月里，我所在的公司经历了五种智能体栈的配置变更。每一次改变都留下了一些重要的东西：不是智能体（重新创建它很容易），而是让它变得有用的上下文。 一度，我们拥有大约300项技能来驱动40个活跃的智能体。从这个过程中得到的教训令人不安：**智能体从来都不是难点。** 在AI Engineer World's Fair上，我公开了得出这一结论的构建日志。我讲述了我们公司内部构建智能体的两个时代：首先是每个岗位一个智能体；然后是一个共享的公司大脑服务于众多智能体。两种方式都奏效了。但最终都撞上了墙。而第二堵墙暴露了一个基础设施缺口，我认为这个社区将在未来几年内去填补它。 > *观看二十分钟完整演讲："上下文层到底是什么？" (https://atlan.com/know/the-missing-infrastructure-for-production-agents/)** **智能体层正变得可抛弃。而你公司的上下文却不可抛弃。**然而，我们使用的大多数工具仍然将两者捆绑在一起。 背景，用一段话概括，因为之前我已经详细论证过。模型正以指数级变得更智能，但并未以指数级变得更有用：根据Gartner的数据，大约只有五分之一的组织报告从AI中获得显著价值，而56%的CEO告诉普华永道 (https://www.pwc.com/gx/en/news-room/press-releases/2026/pwc-2026-global-ceo-survey.html)，他们在过去一年中既未从AI中获得更高的收入，也未降低成本。绩效等于智能乘以上下文，而且这种关系是乘数级的。我在知识图谱会议演讲 (https://atlan.com/context-and-chaos/issue/the-context-layer-knowledge-graphs-second-act/) 和护城河文章 (https://atlan.com/context-and-chaos/issue/if-intelligence-is-abundant-what-is-the-moat/) 中详细阐述了整个诊断。本文则探讨你相信这一点之后会发生什么。 [](https://substackcdn.com/image/fetch/$s_!h-Vm!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F17ecb537-cb70-4797-81db-7d2c851c8b01_1200x630.jpeg)**模型正以指数级变得更智能，但并未以指数级变得更有用 |** 来源：作者 为了将上下文具体化，我请回了Maya，一个我之前用过的人物。在知识图谱会议上，她是一名客服代表。对于这次演讲，她被提拔为McContext汉堡的数据分析师——我选这个名字是因为当时觉得要有点创意，显然并没有。 [](https://substackcdn.com/image/fetch/$s_!TRC-!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd1e0a29d-68b7-4b8a-abdd-0a4a1520682d_2048x1147.png)**认识Maya，每个运营人员都会联系的分析师 |** 来源：作者 Marcus是一个拥有十四家门店的特许经营商，一大早给她发来一个问题：“为什么这周我的得来速（Drive-thru）时间变长了？” 这个请求听起来很简单，直到你细数Maya必须知道多少东西才能回答它。 “得来速时间”是什么意思，用的是哪个定义——财务部门的还是运营部门的？“这周”是指周一至周日还是过去七天，在哪个时区？这是知识：业务的脉络图。 一个优秀的分析师还知道Q3的峰值是季节性的，而且公司上个季度推出了一款新产品，所以她首先排除了这些解释。这是专长：没人费心记录下来的诊断顺序。 还有规范。提问者是谁？Marcus需要的是一个指标、一个解释，还是一个决策？谁有权查看底层数据？当财务和运营部门意见不一致时，哪个定义主导这个答案？ Maya并非在入职培训中学会了所有这些。她通过跟随一位优秀分析师学习、犯错、接收反馈、遭遇边缘案例，并且不再重蹈覆辙。这就是人们如何在公司内部变得有用的过程。工程问题在于：**你如何构建智能体Maya？** 十八个月前，我们和很多公司一样开始。我们选取一个团队，梳理其待完成的工作，并假设哪些工作可以由AI执行。文档撰写和会议准备：可以。关系管理：暂时不行。然后，为我们认为可行的每个工作都构建了一个智能体。 [](https://substackcdn.com/image/fetch/$s_!Vd-u!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fe9e79d53-d466-4a5b-83e8-3ef25ab68d1d_2048x1152.png)**人类与AI之间的工作 |** 来源：作者 这个方法在一段时间内奏效了。然后我们遇到了四面墙。 **第一面是准确性。** 启动智能体非常容易。为其注入足够的业务上下文使其正确才是真正的工作。它的质量几乎完全取决于其上下文的质量，每一个缺口都会造成利益相关者学会不信任它的时刻。信任流失的速度远快于它回归的速度。 **第二面是依赖管理与孤岛。** 当市场部门改变了我们的定位，人类在全体会议上听到这个消息。我们的网站智能体却继续宣传旧的定位长达数周。公司花了一个世纪来建立保持人类团队协调一致的方式：会议、文档、入职培训、管理者。我们的智能体却没有任何这些机制。我们甚至无法看到我们已部署的智能体之间如何相互关联。 **第三面是根本原因分析与可追溯性。** 当智能体产生了一个糟糕的答案，我们常常无法判断问题来自于模型、智能体设计，还是其接收到的上下文。如果你无法定位失败，就无法可靠地修复它。 **第四面是扩散与漂移。** 每个智能体都有自己的记忆，所以每个智能体都在独立学习。向两个智能体提出一个只有一个业务答案的问题，你可能会得到三个不同的答案。 在这四面墙之下，是引发了会场工程师们会心一笑的墙：栈更替。在十二个月内，我们经历了五种智能体栈的配置变更，从无代码构建器到超大规模云和企业搜索框架，再到通用编码智能体，最后到我们在Slack中自己的“爪子”系统。 智能体栈的这种异构性放大了我们在人类栈中构建的组织孤岛。我们的客户成功团队在某个智能体框架上构建，积累了关于客户的上下文。销售团队使用了不同的智能体框架。在销售和售后之间移动上下文很困难，这种分裂导致了智能体重复并重叠彼此的工作。 **框架正变得可抛弃。而上下文则不然。** 而上下文正是我们不断失去的东西。 [](https://substackcdn.com/image/fetch/$s_!8U-P!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F99e35ae4-87e9-4531-90c2-46a7a6c4e895_2048x1151.png)**第一时代的四面墙：上下文工程、生命周期、扩散与漂移 |** 来源：作者 今年，像Claude Code这样的通用智能体改变了根本上的可能性，因此我们反转了架构。 我们没有将上下文分别输入每个智能体，而是让领域专家将他们所知道的内容编码为共享技能。这些技能存在于一个公司大脑中。检索和组装将这些技能连接到正在执行工作的任何通用智能体。 [](https://substackcdn.com/image/fetch/$s_!FDBJ!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F94d1d44c-4b6f-4333-97ee-2fc83c08a9d3_2048x979.png)**一个公司大脑，众多智能体 |** 来源：作者 这个想法来自于人类世界。Maya并非孤星；她属于一个团队。强大的团队共享一种语言、一幅关于当前真实情况的图景、应对重复出现问题的行动手册、关于由谁决策的规范，以及关于失败的记忆。团队作为一个整体来学习。 我们的市场团队进行了第一个实验。一边是我们的业务系统。另一边是刻意异构的智能体：终端里的编码智能体、我们聊天频道里的一个智能体，以及外部产品。共享上下文位于它们之间。我们选择了混合的智能体表面，因为第一时代教会了我们，这一层会不断变化。 [](https://substackcdn.com/image/fetch/$s_!I21_!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc237d1e6-3df3-4090-a99d-fc00c1ffaca6_2048x1150.png)营销OS架构 | 来源：作者 我们最好的SEO专家编写了SEO技能。我们最好的竞品情报专家编写了竞品情报技能。每个人都贡献到一个共享系统中；每个智能体都可以从中汲取。 这个大脑要求的不仅仅是技能。一个自主广告智能体需要知道要查询哪些表，所以我们需要一个数据图。然后它需要语义：这里ARR是什么意思？当市场和财务使用不同定义时，什么才算是合格线索？ 在六个月内，该团队创建了大约300项技能和40个智能体——这是一个活跃的时点快照，而非累计计数。我所说的技能，是指一种编码过的程序或流程，其他人可以拿来在通用智能体中使用。我所说的智能体，是指一个无需人工干预就能主动执行工作的系统。 这种架构让一次编写的专业知识可以被一个异构的智能体舰队使用。然后它暴露了另一类失败。 想想当我们的市场团队改变了我们的核心品类叙事时发生了什么。这种定位为销售和客户成功团队使用的邮件工作流提供内容。但该叙事已作为早期快照硬编码到了那些工作流中。没有任何东西声明这种依赖关系，所以上游变更从未到达下游智能体。它们继续发送旧的故事。 [](https://substackcdn.com/image/fetch/$s_!BZ6D!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F58c2f438-1e57-4d7b-85a2-1f2138876c98_2048x1081.png)**上下文需要像代码一样管理：依赖、所有权、安全、可移植性 |** 来源：作者 这并非一个孤立的设计缺陷，原则上也不令人意外：我曾之前论证过 (https://atlan.com/context-and-chaos/issue/how-to-make-satya-nadellas-vision-a-reality/)，上下文必须像代码一样管理——版本化、测试、归属所有权。落实这一处方与写下它截然不同。技能会学习、演化、漂移；我们并不总能说清楚谁拥有其质量，或者一个变更会影响什么。 安全与治理变成了我在台上所说的“噩梦”。我们在环境文件中发现了硬编码的密钥，同时人们还在将公开的技能库下载到公司工作流中。一旦我们看到了风险，我们就停止了受影响的工作并进行了全面审计。我们并非声称发生了入侵。关键在于，上下文层在拥有可执行基础设施所需的控制之前，就已经变成了可执行基础设施。 显而易见的答案，尤其是在一个满是工程师的房间里，就是：这就是git的用途。把技能放进一个仓库。审查拉取请求。搞定了。 我们确实这么做了。第二时代从第一天起就运行在git上，而git正是它能持续这么长时间的重要原因之一。 **但git记录的是文本，而非含义。** Git可以显示某个定义发生了变化。但它无法自行告诉你，合格线索的新定义会改变两个依赖下游的作战卡片。它不知道某个竞品情报更新与另一个团队拥有的定位相矛盾，或者这种矛盾需要该团队的批准。一个仓库可以存储生产轨迹；但它无法将40个智能体本周学到的东西转化为安全、可审查的改进共享上下文的提案。 这不是反对git的论点。这是软件工程已经围绕git提出的同样论点。差异和历史是基础性的，但还不够。工业级软件需要版本控制加上代码审查、所有权、持续集成、依赖管理、安全扫描、包注册表和运行时可观测性。 **上下文已经拥有了差异。但它还没有拥有其余部分的协调版本。** “上下文的GitHub”是一个不完美的简称。缺失的东西不是一个更好的仓库。也不一定是一个单一产品。它是一个运营层，让公司能够将上下文视为持久的基础设施，而不是智能体特定的配置。 [](https://substackcdn.com/image/fetch/$s_!nNCk!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F0934c8c0-005e-4953-a79e-cb6c76a5f045_2048x1079.png)**企业上下文的GitHub仓库可能是什么样子 |** 来源：作者 我们的构建日志暗示了至少五个要求。 **第一，每个上下文单元都需要一个类似GitHub的资料：** 所有者、审批者、维护者、作用域、来源和声明的依赖。我相信随着时间的推移，技能、语义模型、工具都将作为公司中的“上下文单元”来管理。 **第二，本地上下文和公司级上下文必须保持分开。** 企业没有一个无摩擦的单一真理源。市场和财务可能出于合理原因使用不同的定义。系统需要一个受管控的路径来保留这些差异，并在本地知识应该成为共享标准时进行推广。 **第三，变更需要语义审查。** 文本差异很有用；但审查者还需要知道变更可能会影响哪些决策、评估和下游智能体。声明的依赖永远无法捕获所有涌现行为，但它们可以让影响足够可见以便测试。 **第四，学习必须形成一个受控循环。** 每一次AI交互都会创造更多上下文，利用好它就像淘金。我们试验了一种专门的工具，它读取生产轨迹，反向构建候选改进，并将其作为“批准或拒绝”的提案返回给维护者。生产轨迹也可能包含错误、敏感信息和上下文特定的行为，因此输出不能变成自主的真理。它需要来源检查、评估、有边界的推广和人工批准。 **第五，质量与安全必须是该层的原生属性。** 密钥扫描、权限边界、评估、回滚、保留和删除不能在智能体已经执行了上下文之后才到来。 所有这些必须在智能体使用的接口之间保持可移植性：MCP、SQL、向量检索或混合组装。将上下文层押注在单一接口上只会重演导致问题的锁定。我在六月实地指南 (https://atlan.com/context-and-chaos/issue/what-an-enterprise-context-layer-actually-is/) 中绘制了这种架构的完整剖析图；本文则是其背后的创伤痕迹。 并非每个公司第一天就需要这种机制。一个拥有少量智能体的小团队可能用显式文件、所有者和评估就能服务得很好。当上下文跨越团队、独立变更、为自主工作提供信息，或者必须经受住智能体层的变化时，这种基础设施就变得必要了。这正是我们自己的系统所跨越的边界。 一年前，我和我的联合创始人站在一个舞台上，