为什么 Skills 需要一条上下文流水线：Tessl 谈智能体的上下文工程

本文仅代表我个人经验和观点，不代表 Cisco 官方立场。

当我谈论把技能放到各处时，我并不是说要在每个仓库里散落更多 markdown 文件，然后指望智能体神奇地变好。那样只会导致上下文漂移、重复劳动，以及一个没人信任的共享文件夹。更难的问题是如何一次性打包上下文、对其进行评估、保持同步，并将其分发给需要它的人和智能体。

这就是我演讲“Skills Everywhere”的框架。我想谈谈智能体采用过程中在大型组织内部开始带来痛点的部分：不是一个人能否写出有用的技能，而是当许多团队开始依赖技能作为共享基础设施时会发生什么。

过去一年我的观点发生了变化。我花了很多时间在不同的 harness 之间跳来跳去，追逐最新的模型，并假设出问题时模型可能就是原因。最近，技能改变了这一点。一旦我能够在 Claude Code、Devin、GitHub Copilot CLI 和其他 harness 之间携带有用的上下文，瓶颈就变得清晰多了：模型往往已经足够有能力，但上下文没有得到足够好的工程化处理。

所以论点很简单。你并不总是需要更聪明的模型来获得业务价值。很多时候，你需要的是更聪明的上下文工程。技能就是让上下文可复用、可测试、可迁移的方法之一。

把这次演讲用作智能体上下文

Tessl 把我 AI Native DevCon 的演讲变成了你的智能体可以用作上下文的技能。你也可以观看完整录像。

为什么技能改变了我的模型策略？

对我来说，第一个转变是意识到技能可以让更便宜、更快的模型在更多工作中变得可行。如果工作流是重复性的，并且技能携带了正确的上下文，我就不总是需要技术栈中最昂贵的模型。

这在企业环境中很重要，因为智能体的扇出会非常迅速地改变成本。一个提示词可以生成许多子智能体。一个 harness 可以把一个请求变成大量的模型使用量。如果每个工作流都默认使用最高端的模型，成本就会成为一个严重的约束。

过去几个月，我在很多日常工作中使用了中等推理模型。当我需要复杂规划或非常大的上下文时，我仍然会使用更高端的模型，但我鼓励工程师从中间层级开始，只在任务确实需要时才向上移动。

这之所以有效，不是因为模型魔法，而是因为上下文。如果技能告诉智能体我们如何组织项目、偏好哪些工具、允许哪些模式，以及成功是什么样子，工作流就会变得更加确定。如果我可以用更便宜、更快的模型得到相同结果，我就不应该仅仅因为感觉更安全而为更慢的模型付费。

这就是为什么评估从一开始就是故事的一部分。没有评估，你就是在猜测技能是否改善了结果。有了评估，你就可以问，对于重要的工作流，更便宜的模型是否仍然产生正确的行为。

什么算作技能？

技能可以很简单。至少，它从一个SKILL.md开始，给智能体提供指令。但它也可以包括规则、辅助 markdown、脚本、脚手架、示例和评估。

我为团队构建的一个简单技能定义了仓库标准。我们有技术债，有人创建新项目，也有基于并不总是最新的模式训练的模型。如果我让一个 agent 创建一个新的 Python 项目，而它给我的是 requirements.txt 和一堆 pip install 假设，那不是我要的。我希望我们的项目使用 uv。我可以把它放进一个技能里，这样工程师就不必手动记住每一条设置规则。

重要的不是这是一个巧妙的提示词。重要的是它成为共享上下文。一个新项目不应取决于开发者是否记得把正确的指令粘贴到聊天窗口中。agent 应该每次都能加载相同的标准。

这也是技能需要评估的原因。定义应该始终有效的最低行为。当你改进技能时，旧行为不应悄悄失效。如果一个技能承载着标准、操作流程或知识模式，它就必须像团队所依赖的东西一样被测试。

如何将现有知识转化为技能？

我讲的第一个故事来自 Cisco TAC，即技术支持中心。我在那里工作了很多年，处理金融机构、医院、关键基础设施以及其他停机时间至关重要的企业环境中的高压客户问题。

TAC 有着浓厚的知识库文化。当工程师解决了一个困难案例时，他们会把经验写下来，这样下一位工程师和下一位客户就不必再经历同样为期三周的调查。这些知识之所以有价值，是因为它经过整理、维护，并扎根于真实事件。

显而易见的 AI 做法是让 agent 搜索知识库。我们尝试过一些版本。它带来了一些成果，但也产生了幻觉和毫无意义的答案，因为并非每篇文章都是最新的，也并非每份文档都应该被 agent 消费。

更好的模式不是盲目地把所有内容都喂给 agent。更好的模式是把精选的、高质量的文章流水线化地转化为技能。工程师可以挑选那些被积极维护且有价值的文章，将它们转化为 agent 可用的上下文，并围绕我们期望的结果构建评估。

想想一个支持案例。客户带着问题描述开了一个案例。三周后，经过日志、调查和诊断，团队解决了它。问题是：我们如何缩短从初始描述到可能解决方案的路径？一个好的技能可以承载相关的诊断上下文，让 agent 能更早提供帮助。

但技能不应偏离源文章。如果文章变了，技能也需要变。如果变化很小且评估通过，流水线可以自动发布更新后的技能。如果变化引入了新主题或实质性改变了行为，那就需要人工审查，并且很可能要添加新的评估。

这就是我关心的上下文流水线：源知识、生成的技能、评估、发布和同步。

别再手写每一个技能

我在演讲中强烈表达的一点是，技能不是为你准备的。技能是为你的 agent 准备的。

这并不意味着人不重要。它意味着最有价值的人类时间应该投入到源质量、预期结果和评估上。人类应该决定什么才算好。人类应该验证 agent 是否有帮助。但人类不需要手工雕琢每一个技能的每一个字。

如果你已经拥有强大的知识库，就用模型把这些知识转化为它所需的形式。让模型为自身使用而组织信息。然后通过评估和审查关卡来验证输出。

这一点很重要，因为手动编写技能无法规模化。大型组织已经拥有太多知识，无法让每个团队都手动将其改写为提示词。如果每个工作流都依赖某个人维护一份私有提示词，那你构建的就不是组织能力，而只是一种局部习惯。

流水线方法还能让人类文档保持活力。我认为在这个世界里，人类文档不会自动消亡。在文档文化浓厚的地方，情况可能恰恰相反。文档会变得更加重要，因为它们为智能体提供依据。但只有当面向智能体的上下文与面向人类的源文档保持一致时，这一点才成立。

我们如何使用技能来推广评估？

第二个故事聚焦于开发者。我们当时正在思科构建一个全新的 AI 原生平台：一个多智能体编排系统，包含语义路由器、专家智能体、嵌入式 AI 操作以及统一的客户界面。不同的团队负责不同的智能体，而且智能体数量还在不断增加。

这种架构只有在我们能够评估它时才可行。我们需要知道用户的问题是否被路由到了正确的智能体、答案是否足够好、是否调用了正确的工具、参数是否合理，以及延迟和 token 用量是否在预期范围内。

我被要求帮助判断这个系统是否好到可以发布。这意味着我们需要一个团队真正能用的评估框架。我们使用了 LangChain、LangGraph 和 LangSmith 风格的可观测性等工具，但常规的数据集和评估模式不足以满足我希望团队比较不同环境的方式。

一个具体的例子是数据集格式。许多评估数据集是 JSON 文件，而 JSON 往往会变成一大行。这对智能体来说很难编辑。我们转向了 JSONL，这样每个示例独占一行，编码智能体可以进行精确更新，而不必把巨大的文件拖入上下文。

更大的问题是推广。我不得不在时间非常有限的情况下，向多个分布在全球的团队解释这种方法。开个会解决不了问题。一场关于测试的一小时演示，也无法让每个团队都产出一致的数据集、CI 集成、环境感知调用和共享指标。

于是我把评估框架变成了一项技能。

这项技能包含了我已经与一个团队一起打磨过的说明、示例、脚本、示例评估、数据集模式和模式。我让一个智能体帮忙把可行的方法提炼成一项可复用的技能，供其他编码智能体使用。然后我逐步推广：一个团队、收集反馈、再一个团队，如此推进。

结果比让每个团队各自发明自己的评估框架要一致得多。每个人都可以从相同的模式出发。他们的编码智能体可以完成大部分搭建工作。团队仍然拥有自己的智能体和数据，但这个框架给了他们一种共同语言。

这正是技能所擅长的：分发一种工作方式。

人类如何保持同步？

评估框架带来了第二个问题。管理者和利益相关者想知道发生了什么变化，但并非所有人都生活在 GitHub 里。有些人生活在 Confluence、Jira、Webex 或管理流程中。

错误的做法是手工编写一个单独的 Confluence 页面。它会逐渐偏离。我会忘记更新它。仓库里说的是一回事，wiki 里说的是另一回事，最终没人会信任任何一方。

更好的做法是把源头放在一个地方。技能存放在一个仓库里。面向人类的 README 也存放在这个仓库里。面向智能体的上下文和面向人类的说明可以一起更新。然后一个确定性的脚本就能把 README 同步到 Confluence。

这不需要让 LLM 直接编辑 Confluence。Markdown 可以变成 HTML。标题可以变成标题。关键在于，管理者读到的是与智能体所用的同一个事实来源，只是被转换成了他们实际打开的平台。

这个小小的工作流解决了一个真实的组织问题。它让仓库保持权威，同时让信息在 Git 之外也能被访问。

文化转变在于问：这是一个技能吗？

我试图建立的文化转变，是一种条件反射式的提问：这是一个技能吗？

当一位新工程师问 DevOps 信息在哪里时，答案不应该只是一个 wiki 页面的链接。更好的问题是，我们是否有一个技能来解释它，以便这位工程师的智能体可以使用它。如果没有，也许我们应该一起创建一个。

这并不意味着每个想法都要变成一个技能。它意味着重复的解释、标准、工作流、入职知识、评估模式和操作流程，都应该成为可复用上下文的候选。

这也意味着要避免技能爆炸。我不希望 15 位工程师为同一个工作流创建 15 个略有不同的技能。那会浪费 token、造成混乱，并让质量难以评判。共享技能需要归属、版本管理、评估，以及清晰的贡献路径。

在问答环节中，我把它比作一个共享库。人们可以提交 pull request，但他们不应该能够破坏其他人所依赖的行为。评估回答了这个问题。如果技能声称支持某种行为，就为它写一个评估。当技能发生变化时，运行评估。

从一个重复的解释开始

你不需要从构建一个大型内部平台开始。我们走到那一步，是经过多年工作和大量摩擦才实现的。起点可以小得多。

选一个你反复解释的概念或工作流。把它变成一个技能。确定受众是谁。确定事实来源在哪里。确定它需要分发到哪里。添加一个基本的评估，定义这个技能必须帮助智能体做什么。

然后诚实地进行版本管理。一个 0.0.x 技能是实验性的。自己先用。与几个人分享。获取反馈。当它变得更可靠时，再把它向前推进。当它达到 1.0 时，人们应该能够信任它说到做到，且几乎没有摩擦。

持久的投资不是你碰巧这个月使用的那个 harness。智能体架构会不断变化。模型会不断变化。你的组织所知道、测试和维护的上下文，才是值得复利积累的部分。

这就是我带到 AI Native DevCon London 的论点：只有当技能成为上下文流水线的一部分时，技能无处不在才行得通。现在就构建这条流水线，因为它周围的一切都会不断变化。