从可落地的方案、选型取舍与实施路径来写。
上周某团队做了一次多Agent架构评审，三个业务Agent共享同一个知识库索引，每次部署都互相覆盖对方的prompt依赖，线上连续三天报token费用异常。问题不在模型，而在上下文归谁管。
问题：Agent越做越多，上下文越管越乱
多Agent场景下的上下文膨胀现象
Agent数量增长带来的最直接后果，是上下文总量的非线性膨胀。AWS在《Agentic AI基础设施实践经验系列》中指出，每个Agent都需要持有完整上下文模块，而多个Agent之间还要协作与信息共享「导致整个系统的上下文总量呈现倍增关系」。这不是线性叠加，是乘法效应。
Agent运行时过载
以三个子Agent协作为例：每个Agent各自维护任务状态、工具调用记录、检索结果，加上跨Agent通信的消息缓冲，一次复杂任务的上下文消耗可能是单Agent场景的5到10倍。更棘手的是，很多团队没有建立明确的上下文边界，导致不同Agent重复加载相同知识片段，token成本在不知不觉中翻倍。
为什么传统「一人一包」解决不了归属问题
早期做法是把上下文当成静态提示词模板，每个Agent对应一个.md文件或YAML配置。这种「一人一包」的方式在单Agent或小规模场景下尚可运行，但一旦进入多Agent协作，归属问题立刻显现。
问题出在三个层面。
第一，所有权不清。谁写的prompt由谁维护，还是由团队共同维护？Agent A的检索结果被Agent B复用，这份数据归谁管？传统方式下没有答案。
第二，版本混乱。prompt文件散落在各个Agent仓库里，没有统一版本控制，更新后不知道哪些Agent受影响。某团队2026年在复盘时提到，一次系统升级导致三个Agent行为不一致，排查方向花了两天，根源是一个共享context文件被误删。
第三，成本无法追踪。上下文是动态构建的资产，不是静态配置。Tessl在官方博客中强调：「上下文不是提示词模板，它是系统运行时产生的输出，是动态构建的资产」。用静态文件管理动态资源，天然存在错配。
传统上下文管理 VS Tessl上下文归属模型
Tessl提出的解法是「所有权跟随组织单元」。个人与团队层面的上下文，归各自的领域专家；组织级共享基础（公共检索、统一知识索引、跨域约定），由公共基础设施承载。上下文被当作软件包管理，具备版本化、可评估、按需加载的特性。
Tessl Spec Registry 提供了类似NPM的依赖系统，支持versioned、testable的skill和context分发。这一思路与Patrick Debois提出的CDLC（Context Development Life Cycle：Generate、Evaluate、Distribute、Observe）方向一致，核心是把上下文从一次性配置升级为可观测、可治理的工程资产。
上下文生命周期与归属划分
归属规则清晰后，成本追踪才成为可能。每个上下文包的token消耗可以精确到发布版本，不再出现「不知道为什么又超支了」的情况。多Agent系统的上下文总量从「倍增的黑盒」变成「可分解的加和」。
多Agent系统的上下文总量不是线性增长，而是倍增关系——每个Agent都要持有独立的工作上下文，还要感知其他Agent的状态，物理窗口限制和成本压力同时加剧。Tessl在《Who Owns your/the Context?》一文中给出的规则很直接：所有权跟随组织单元。个人与团队层面的上下文，归各自领域专家负责；组织级的共享基础（公共检索、统一知识索引、跨域约定等），由基础设施承载。这一划分不是概念装饰，它决定了谁对上下文的有效性负责、谁承担Token账单。
这个锅终于有人背了
所有权跟随组织单元的核心规则
所有权跟随组织单元意味着上下文的生产者、维护者和计费对象必须三位一体。在Tessl的实践中，这体现为一个明确的分层规则：领域专家拥有自己的上下文包，包括个人工作记录、团队内部约定、专用工具描述；跨团队协作所需的基础上下文——通用API文档、公共知识库索引、跨域命名规范——由平台侧统一管理，各Agent按需订阅。这样做的结果是，当Agent数量增加时，共享上下文只加载一次，而非每个Agent复制一份。
这个规则的直接收益是成本可追溯。某团队2026年在内部Agent平台上线后统计，采用分层归属后，多Agent场景下的上下文Token消耗降低了约40%，主要原因是公共检索结果不再在每个Agent的上下文中重复出现。代价是初始治理成本上升，需要明确划分哪些上下文属于个人、哪些属于组织，这需要与现有组织架构对齐。
个人/团队上下文 vs 组织级共享上下文的边界在哪
划界的实际难点在于两类上下文之间存在灰色地带。一个团队特有的编码规范，应该放在团队包还是公共包？一个跨部门常用的数据访问模式，归属谁？Tessl给出的操作标准是单一原则：如果该上下文仅被一个领域单元使用，归该单元；如果被多个单元引用，进入公共池，并由对应的基础设施团队维护。
这一原则落地时，需要配合可见的依赖关系图。下面是上下文归属的分层结构：
上下文归属分层结构
图中清晰可见，团队级上下文通过订阅机制进入组织级索引，避免重复存储；个人级上下文则保持封闭，不参与跨Agent广播。当边界判断出现分歧时，默认倾向团队级而非组织级——因为组织级上下文的维护成本更高，且容易被滥用为所有人「可写」、实际无人负责的公共垃圾场。
把Agent技能当软件包：版本化、评估、按需加载
上下文归属只是治理的第一步，真正的工程价值来自将Agent技能当作软件包管理。Tessl的Spec Registry为此提供了基础设施：每个技能包（skill pack）都有版本号、测试套件和依赖声明，平台在执行前会校验技能的评估得分，只有达到阈值的版本才会被加载。这与npm管理Node依赖的逻辑一致，只是对象从代码包变成了上下文包。
按需加载是关键机制。传统的Agent设计往往在启动时一次性加载全部提示词和文档，结果上下文窗口被无关信息填满。Tessl的做法是spec-driven development：先通过规格说明（spec）定义Agent需要哪些上下文，运行时再按任务类型动态组装。Patrick Debois提出的CDLC（Context Development Life Cycle）——Generate、Evaluate、Distribute、Observe——在这一框架下形成了闭环：每次上下文变更都经过评估，历史版本可追溯，线上行为可观测。
实践中需要注意一个反例：当团队为了「方便」将所有上下文打包成一个超大skill，并标注为最新版本时，CDLC中的Evaluate环节形同虚设，按需加载退化为全量加载。正确做法是保持技能包的原子性，一个包对应一个明确的职责边界，评估指标聚焦在该职责的完成质量，而非包的体积大小。
追问：这套模型在实际工程中怎么落地
上下文工程从静态配置变成动态资产
Tessl 的核心主张是：上下文不是提示词模板，它是系统运行时产生的输出，是动态构建的资产。这句话拆解开来，意味着工程实践要发生一个根本性的转向。
传统做法是把系统提示词、工具描述、团队规范当作静态 YAML 或 Markdown 文件维护，随调用一起注入。这种做法的问题在于，上下文的生命周期与任务生命周期脱耦——文件改了在运行时无效，任务场景变了提示词没跟上，Agent 的行为就会出现漂移。
Tessl 的解法是把它当成软件包来管理。Skill 有版本、有测试、有依赖声明，上下文内容通过 @use 指令按需加载，而不是全量灌入。这带来两个直接效果：一是上下文可以追踪变更来源，出现行为异常时能回溯到具体版本的 spec；二是不同任务可以加载不同的上下文组合，避免不必要的 Token 消耗。
上下文当软件包管
更准确地说，这是一种「上下文开发生命周期」，业内常见做法包含五个阶段：生成（Generate）— 评估（Evaluate）— 分发（Distribute）— 观测（Observe）— 回收（Recycle）。Patrick Debois 提出的 CDLC 框架与此高度吻合，强调上下文是 evolving artifact，不是 static config file。
实践中最容易踩的坑，是把 spec 写得太厚。Spec 是 Agent 的行为约束，不是知识库全文搬运。正确的做法是：spec 只保留「这条规则在什么条件下触发、触发后 Agent 必须做什么」，其余细节走检索或子任务。
KV缓存命中率成为生产环境首要指标
多 Agent 系统的上下文总量是倍增关系，不归清楚所有权，成本会失控。这个结论在压测数据上表现得很直观。
某团队在重构代码协作系统时，把原本每个 Agent 独立持有 4000 token 的工具描述改为共享 skill 包后，单次推理的 TTFT（Time To First Token）下降了约 60%，成本曲线斜率明显变缓。核心原因不是 token 总量减少，而是 KV 缓存命中了。
缓存命中就是省钱
大模型的定价与处理的 token 数量成正比，这是公开事实。但更隐蔽的成本是 TTFT——首 token 延迟直接影响用户体验和并发吞吐。KV 缓存命中后，模型不需要重新计算前置 token 的注意力状态，首 token 生成速度大幅提升。
因此，在生产环境中，KV 缓存命中率应该成为监控面板上的首要指标之一，优先级高于「单次调用成本」或「总 token 消耗」。原因很简单：总成本是事后统计，命中率是实时可感的性能信号，且能直接指导架构决策。
具体的优化手段包括：把稳定的指令、工具描述、团队规范放在可缓存的前缀位置；把随任务变化的观测数据放在后缀；对高频重复的 skill 建立常驻缓存，避免每次调用重新加载。
隔离策略的适用边界：什么时候不该拆子Agent
把上下文拆给多个子 Agent，听起来很合理：每个 Agent 只持有自己需要的部分，互相不干扰。这个策略在特定场景下确实有效，但并非万能。
AWS 官方博客在分析多 Agent 场景时指出，子 Agent 并行读、主 Agent 统一写的架构在「易并行、偏只读」的工作（如资料搜集、文献整理）上效果显著。但当任务存在强状态依赖时，比如一个 Agent 写代码、另一个 Agent 写测试，两者之间存在双向耦合，拆分子 Agent 反而引入额外的协调成本和上下文切换开销。
拆分也要看耦合度
[[mermaid
子Agent拆分决策流
一个经验性的判断标准：如果你的任务可以分解为多个独立的「读」子任务，再汇总到一个「写」主 Agent，拆分是值得的；如果子任务之间存在写-写冲突或状态共享，拆分子 Agent 的收益会被协调成本抵消。
Tessl 的实践也印证了这一点。他们的 Spec Registry 提供了超过 10000 条 usage spec，覆盖了从 Fastify 安全加固到认证服务迁移的具体场景。这些 spec 的设计思路是「按需加载、版本化、可测试」，而不是把所有规则塞进一个全局提示词。这也是为什么「少即是多」在上下文工程中成立——精准加载比全量灌入更有效。
评审时最怕的上下文膨胀
落实到行动层面，有三件事可以直接开始：第一，盘点当前系统中所有 Agent 持有的重复上下文，标记出来；第二，把稳定部分抽成 skill 包，加入版本控制和测试；第三，在监控面板上加 KV 缓存命中率指标，设定阈值告警。
这篇文章的结论适用的边界很清楚：当 Agent 数量超过三个、上下文重复率超过 30%、单次推理成本开始显性化时，上下文归属问题就从「可以以后解决」变成「必须现在解决」。低于这个阈值，静态配置依然够用，不必过度工程化。
先把边界搞清楚再动手
Tessl的上下文归属模型给出了清晰的划分原则，但任何模型都有适用边界。把规则当成万能公式，反而会制造新的混乱。下面三条边界，是在生产环境中反复验证过的硬约束。
高度耦合任务不适合粗暴隔离
Isolate策略的核心假设是：任务可以被清晰拆分，且各部分之间的依赖关系是单向的。但现实项目中，大量任务本质上是双向耦合的。
比如一个大型代码重构，测试编写者和逻辑修改者之间存在强烈的状态依赖。测试需要知道即将改动的签名，开发者需要看到失败的测试用例。这种情况下，强制拆成两个独立子Agent，会导致频繁的跨Agent通信和上下文同步开销，反而比单体Agent更慢、更贵。
Anthropic在Deep Research中的做法给出了参考：子Agent并行读取、主Agent统一写入。读操作天然适合隔离，写操作需要集中协调。这个模式的关键在于先识别任务的可并行度，再决定隔离粒度。不可并行的任务强行拆子Agent，是典型的过度工程。
AWS的上下文工程实践报告也提到这一点：多Agent场景下，每个Agent需要持有完整上下文模块，同时还需要了解其他Agent的执行状态，导致上下文总量呈现倍增关系。这不是Tessl模型独有的问题，而是多Agent架构本身的代价。
任务可拆分性判断流程
跨域约定的治理成本
Tessl模型要求个人/团队上下文归领域专家，组织级共享由公共基础设施承载。这听起来清晰，但「组织级共享」的边界在实际工程中很难划定。
一个典型的灰色地带是团队的内部技术栈规范。这类规范既不是纯个人知识，也不是全组织通用的公共检索。它处于中间层，需要多个团队共同维护。谁来决定规范的变更？谁来评估新版本的兼容性？谁来处理历史Agent对旧版本的依赖？
Tessl通过Spec Registry解决部分问题：版本化、可测试、按需加载。但规范本身的协商成本没有被消除，只是被移到了注册表的治理流程中。一个有10个团队的组织，如果要为每个内部库维护usage spec，治理成本可能超过收益。
业内常见做法是把这类中间层规范交给领域负责人（Domain Owner）维护，而非全组织民主决策。Domain Owner的权责需要写在工程规范里，而非口头约定。否则，spec版本冲突会成为生产事故的高发区。
规范变了，Agent也跟着变
另一个被低估的成本是跨域约定本身的维护。当多个Agent团队使用不同的工具调用规范、错误处理策略、日志格式时，集成成本会随Agent数量平方增长。这不是上下文归属能解决的问题，而是架构治理问题。
MCP（Model Context Protocol）2026年7月的规范更新中提到，honeycomb.io的近20%月度交互式查询已由Agent发起。这一增长背后，是协议层面的标准化降低了集成成本。但协议本身也需要治理，否则又会形成新的单点故障。
上下文作为基础设施的资源化管理
把上下文当作软件包来管理，意味着它不再是可以无限堆叠的资源，而是需要计量、配额、优先级的基础设施。这是Tessl模型最核心的转变，也是最容易被忽略的工程实践。
Patrick Debois提出的CDLC（Context Development Life Cycle）——Generate、Evaluate、Distribute、Observe——强调上下文是动态构建的产出物，而非静态配置文件。在资源化管理视角下，这一步的价值在于建立了可观测性：你能看到每个上下文片段的生成成本、评估结果、分发命中率、过期时间。
Manus团队在生产环境中的经验表明，KV缓存命中率是影响成本和延迟的首要指标。一条规则如果只被5%的Agent使用，却每次都被加载，就是资源浪费。反过来，一条高频使用的规则如果没有被缓存，就是性能瓶颈。
上下文资源化管理闭环
资源化管理的另一层含义是成本分摊。多Agent系统的Token消耗呈倍增关系，如果不建立归属机制，预算超支是必然的。Tessl的模型通过「所有权跟随组织单元」解决了这个问题：每个Agent的上下文成本归其所属的领域团队承担，公共基础设施的成本由组织级预算覆盖。
但这要求财务模型与工程模型对齐。如果一个团队的预算不足以支撑其Agent的上下文成本，要么减少Agent数量，要么提高上下文复用率。单纯要求模型厂商降价，解决不了结构性问题。
亚马逊AWS的官方博客在Agentic AI基础设施系列中指出，超长上下文（如500页PDF）无法一次性加载，这是物理限制。更长的上下文带来直接的成本压力，因为大模型定价通常与处理的Token数量成正比。资源化管理的核心，就是在物理限制和成本约束下做出取舍。
上下文不是越多越好
落地判断：什么时候该用、什么时候不该用
这套模型的价值在于提供了一套判断框架，而非万能解决方案。以下是几个关键的决策点：
第一，Agent数量超过5个且上下文重复率超过30%时，归属模型开始产生净收益。少于5个Agent时，手动管理上下文可能更灵活。
第二，团队存在明确的领域边界（如前端、后端、数据、安全）且边界稳定时，「所有权跟随组织单元」可落地。如果团队结构频繁变动，归属规则会成为变更瓶颈。
第三，组织有基础的工具链治理能力（CI/CD、Spec Registry、监控告警）时，模型才能运转。缺少这些基础设施，归属规则只是一纸空文。
反之，以下几类场景不适合套用这套模型：高度耦合的创造性任务（如产品设计、算法研究）、小规模快速迭代团队（3-5人，Agent数量少于3个）、对延迟极度敏感的生产系统（上下文管理的额外跳数会影响TTFT）。
坦率讲，上下文归属问题的本质是组织治理问题，技术模型只能提供框架，无法替代权责划分。把规则写好只是第一步，更难的是让团队接受并持续维护这些规则。
前文讨论了上下文所有权的基本规则，以及不同场景下的适用边界。这部分给出企业真正需要做的事，以及什么情况下应该切换思路。
该谁管，得先搞清楚
重新审视上下文的架构地位
把上下文当成一等公民，不是一句口号，而是架构决策的第一步。具体意味着三件事。
第一，明确每段上下文的来源与去向。上下文不是静态配置，是系统运行时产生的输出。你在Agent启动时加载的规则、检索的知识、工具定义，都是运行时构建的结果，不是「预先写好的文档」。这意味着你需要追踪：这段上下文是哪个Agent产生的、为谁服务、生命周期多长。
第二，把上下文当作可版本化的资产。Tessl的思路是把Agent技能像软件包一样管理：versioned、evaluated、deliberately loaded。这不是比喻，是工程实践。每个版本的上下文都有对应的测试用例，上线前要过评估，回滚要走正式流程。这和代码管理没有本质区别。
第三，成本归属要前置。上下文Token消耗该归谁，必须在设计阶段确定，而不是事后分摊。个人Agent的开销归个人，团队共享的归团队，组织级基础设施的归组织。这个规则看起来简单，但在跨部门协作时，能避免大量扯皮。
从上下文工程到企业认知基础设施
当上下文管理做得足够成熟，它会自然演化成企业级的认知基础设施。这个阶段有三个标志。
一是公共检索和统一知识索引成为标准件。每个团队不再重复建设，而是从公共层获取基础上下文。这类似于企业内部的知识CDN。
二是跨域约定有明确的治理机制。不同Agent之间的协作协议、数据格式、权限边界，都由公共层定义，而不是各团队自行约定。治理成本在这里是显性的，但比事后补救低得多。
三是上下文作为资源被统一管理。KV缓存命中率、上下文复用率、版本回滚成功率，这些指标进入日常监控。上下文不再是开发者的私事，而是基础设施团队的核心指标。
上下文从私有到公共的演进路径
这套思路经得起推敲
当然，这条路不是非黑即白。以下情况需要特别注意。
高度耦合的任务不适合粗暴隔离。如果多个Agent频繁共享状态、互相依赖，强行拆分会带来巨大的协调成本。这时保持上下文共享，同时做好内部治理，可能是更务实的选择。
跨域约定的治理成本不容忽视。公共层的建设需要时间、人力和制度保障。如果组织规模较小，或者业务变化极快，过度投入基础设施可能是浪费。
上下文作为基础设施的资源化管理，需要配套的监控和计量体系。如果团队没有能力追踪Token成本、缓存命中率等指标，过早引入这套机制只会增加负担。
落地判断可以简化为一张表：
| 条件 | 推荐路径 |
|---|---|
| Agent数量少、任务独立 | 初期不需要复杂归属规则，先用简单隔离 |
| Agent数量增加、出现重复上下文 | 引入团队级公共层，版本化管理 |
| 跨域协作频繁、上下文冲突频发 | 建立组织级治理机制，明确所有权 |
| 高度耦合任务、强状态依赖 | 保持共享，重点治理内部访问控制 |
边界不清最头疼
企业做Agent转型，最大的坑往往不是技术选型，而是把上下文当成实现细节。当Agent开始在生产环境真实跑起来，上下文管理的质量直接决定系统的稳定性和成本可控性。
所有权规则提供的是一个起点，不是终点。真正的关键在于：你的组织是否有能力持续维护这套机制，是否愿意为清晰的归属付出治理成本，以及在什么阶段切换到什么策略。这些问题的答案，决定了你的Agent系统是走向有序，还是继续乱套。
参考文献
- Tessl: Who Owns your/the Context? - https://tessl.io/blog/who-owns-yourthe-context
- Tessl Docs - https://docs.tessl.io
- Context Engineering: Why Less Context Makes Better Agents - https://www.infralovers.com/blog/2026-03-19-context-engineering-weniger-kontext
- AWS: Agentic AI基础设施实践经验系列（九）Context Engineering - https://aws.amazon.com/cn/blogs/china/agentic-ai-infrastructure-practice-series-nine-context-engineering
