上下文工作方式应如 API每个开发过基于大语言模型LLM应用程序的开发者都碰到过类似难题。把上下文硬编码到提示里在设计场景中运行良好但执行稍有不同任务时就会出问题。添加更多上下文会引发更多冲突最终只能维护一堆手动调整的字符串团队中没人能完全理解它们。API 就像一次握手定义了能请求什么及会得到什么响应无需了解数据底层生成或存储方式。调用新闻文章端点能得到标题、描述和作者信息端点描述事物类型可检索该类型任何实例。而大多数团队构建的上下文与 API 相反仅适用于特定场景超出就会出错。真正的解决方案元数据层而非更多上下文真正可扩展的办法是把上下文视为接口即元数据层描述给定数据片段是什么、与其他数据的关联及代理应如何解释它无需将数据硬编码到每个提示中。API 契约同时完成记录端点用途语义和规定有效调用方式模式两项任务这种约束使契约可靠陌生人无需读源代码就能开发。元数据层也需这种双重性上下文图中的实体包含契约两部分语义说明实体及关系模式说明结构有效性。查询实体的代理能获定义和边界限制忽略约束部分只是编写文档只有语义层而无模式层无法阻止新用例歪曲含义等。硬编码上下文在单次运行有效但新用例会带来维护问题而描述可用信息类型等的层能准确提取任务所需上下文。这会带来更小的上下文窗口、更低的令牌成本和更好的模型输出三个效果。没有元数据层会怎样与一位销售副总裁交谈得知他自建的 AI 仪表盘虽能工作但有问题。其他团队想要类似仪表盘但区分数据字段的逻辑只在他脑海中无实体定义重建需从头推导契约两部分。且他不想再解决基础设施问题。这是多数无上下文层使用智能代理团队会遇到的问题构建代理不难难在后续增加新用例时需手动重新理解数据无模式验证无法保证下一人做对。编写一次契约处处可用这里的转变是从一次性上下文到持久上下文硬编码上下文适用范围窄而有明确描述等的上下文能经受未来用例考验。随着智能代理使用广泛多个代理使用相同底层数据时需共享契约。为下一个提示添加上下文前要思考是解决当前问题还是定义长期有效契约一次性任务硬编码更快构建多人或多代理交互系统需投资构建上下文层当他人可基于此开发时投资会有回报这才是团队管理上下文方式的真正转变与更大模型或更长上下文窗口无关而是赋予数据及其描述不同关系让第二个用例实现成本低于第一个。