AI Agent竞争新逻辑：从对话能力转向技能沉淀能力

过去十二个月，AI Agent成为科技领域最受关注的方向。

众多产品纷纷标榜自己是Agent：能够联网检索、调用各类工具、操作浏览器环境、编写程序代码、处理文档资料、自动化执行多步骤任务。

但核心问题在于：

一个Agent究竟依靠什么来实现稳定输出、专业表现和重复利用？

不是更冗长的提示词。 不是把所有工具一股脑塞给模型。 更不是让模型每次都重新摸索。

Perplexity Research近期发表了一篇研究《Designing, Refining, and Maintaining Agent Skills at Perplexity》，系统阐述了他们在Agent Skills设计、优化和维护方面的实践经验。文章核心观点清晰：**未来高质量Agent的核心竞争力，不止于模型本身，更在于一套经过长期打磨的Skill体系。**Perplexity在文中指出，其核心Agent产品构建于模块化的Agent Skills架构之上，这些Skills涵盖通用工具、Perplexity Computer、金融、法律、健康等专业领域，同时覆盖大量细分用户需求。(Perplexity Research)

这篇文章对AI教育、企业级AI应用以及智能体产品开发者具有重要参考价值。

因为它回应了一个根本问题：

如何将专业经验转化为AI Agent能够稳定调用的能力？

许多人听到Agent Skill时的第一反应是：这不就是更长的Prompt吗？

并非如此。

在Perplexity的架构设计里，一个Skill并非单个文件，而是一个完整的目录结构。该目录可包含核心说明文档、脚本代码、参考素材、模板示例、配置文件等多种组件。SKILL.md只是入口，真正的Skill是一组经过系统组织的上下文信息、工具资源和执行组件。

这意味着，Skill不是在指导模型“如何表达”，而是为模型装备一套专业能力。

一个标准Skill可能包含：

其中：

这一设计的核心理念是：Agent不应该每次都从零起步。

如果某类任务会周期性出现，如果某个领域有成熟经验，如果某个流程需要专业判断，就应该将其固化为Skill。

这篇文章最值得关注的一点，是它明确指出：编写Skill与编写代码遵循不同的逻辑。

传统软件开发追求清晰、显式、低复杂度。但在Skill设计领域，很多传统经验可能不再适用。

Perplexity在文中用“Python之禅”与“Skill之禅”做了对照。比如传统代码强调“简单优于复杂”，但Perplexity认为Skill往往是一个文件夹而非单文件，复杂的组织结构本身就是合理的设计；传统代码强调“显式优于隐式”，但Skill的触发依赖模型对用户意图的隐性匹配。

这一点至关重要。

因为Agent Skill不是供人阅读的普通文档，而是供模型运行时调用的专业上下文。

为人撰写文档，可以详尽完整、步骤清晰。 为模型编写Skill，必须高信号、低噪音、精炼有效。

如果把Skill写成冗长的使用手册，模型未必更稳定，反而可能更无所适从。

真正优秀的Skill，不在于信息量堆砌，而在于每一句话都能影响模型行为。

在Perplexity的Skill架构中，description不是功能说明文档，而是路由触发条件。

也就是说，它不是写给人看的“这个Skill有什么用”，而是写给模型看的“何时应该加载这个Skill”。

Perplexity明确指出，description是常见的设计失败点，因为许多人将其写成内部文档说明，而非加载触发条件。优秀的description通常以“Load when…”开头，目标是描述用户意图，而非概括工作流程。(Perplexity Research)

这一点决定了一个Skill能否被正确调用。

一种较差的写法是：

一种更优的写法是：

差异在哪里？

前者描述功能特性。 后者匹配用户的真实表达。

Agent系统通常会将所有Skill的名称和description注入模型上下文，由模型判断是否需要加载。如果description编写不准确，Skill就会出现两类问题：

第一，该加载时未能加载。 第二，不该加载时错误加载。

这就是智能体系统中的隐性降级。

你新增了一个Skill，表面上看增强了系统能力，实际上可能模糊了其他Skill的边界。

这篇文章有一个非常务实的判断：

每个Skill都要支付上下文成本。

Perplexity将Skill的上下文开销分为三个层级：索引层、加载层、运行时文件层。索引层会在每个会话中注入Skill的名称和描述，每个Skill约消耗100个tokens；完整的SKILL.md理想情况下不宜超过约5000个tokens；其他脚本、参考资料、模板则应在运行时按需读取。

这意味着，Skill并非越多越好。

如果一个Skill缺乏明显价值，它不是中性的，它会分散模型的注意力。

Perplexity给出的判断标准非常直接：

如果没有这句话，Agent会不会出错？

如果不会，那这句话就不应该写入Skill。

这个标准适用于所有Agent产品团队。

许多人在编写Skill时，容易将其写成培训手册、操作指南、项目文档。问题是，模型本身已掌握大量通用知识。你不需要告诉模型如何执行常规Git命令、如何编写标准Markdown、如何生成普通摘要。

Skill应该补充的，是模型不了解、不稳定、容易误判、必须遵守的内容。

并非所有任务都需要Skill。

Perplexity的判断非常实用：只有当模型缺少特殊上下文就会出错，或者你需要它在某类任务中保持高度一致性时，才需要Skill。例如企业内部流程、专业领域判断、特殊审美偏好、垂直行业规则等。

换句话说，Skill适合解决三类问题。

第一类是模型不具备的知识。例如企业内部流程、私有系统规则、团队协作习惯。

第二类是模型容易出错的判断。例如法律、财务、医疗、教育场景中的专业边界。

第三类是模型输出不稳定的问题。例如每次生成页面风格不一致，每次撰写报告结构不同，每次处理用户需求时边界漂移。

反过来，如果模型本身就能完成，而且做得足够好，就不需要写成Skill。

Skill的价值，不在于重复常识，而在于沉淀专家判断。

Perplexity在文中举了一个非常典型的案例。

许多工程师会将一系列Git命令写入Skill，比如先执行git log，再切换分支，再进行cherry-pick。

但这类内容对模型帮助有限，因为模型本身已掌握Git命令。更优的写法不是罗列命令，而是告诉模型目标和处理原则：将某个commit cherry-pick到干净分支上；如果存在冲突，要保留原始意图；如果无法干净合入，要说明原因。

这个案例非常重要。

它说明Skill的核心不是“步骤清单”，而是“处理原则”。

模型已掌握许多步骤。 它真正缺乏的是：何时运用、边界在哪里、失败时如何处理、什么结果才算达标。

因此，编写Skill时应少写“你要先做A，再做B，再做C”。

应该多写：

这才是Agent真正需要的上下文。

这篇文章另一个反直觉的观点是：不要先写Skill，先构建eval。

Perplexity建议在编写Skill之前，先设计评测样例，尤其要包含真实用户查询、已知失败案例、相邻领域的混淆案例。至少要验证两件事：该加载时能否加载，不该加载时是否避免误加载。负例往往和正例同等重要，甚至更有价值。

这反映了一个成熟工程团队的思维方式：

Skill不是编写完成就结束。 Skill必须可验证。

否则，你无法确认它是否真正改善了Agent。

对Agent产品而言，最危险的不是缺乏Skill，而是Skill看起来完善，实际却造成系统行为漂移。

因此，建设Skill库不能仅凭感觉。

必须建立评测集：

这也是Agent从Demo走向产品的分水岭。

Skill上线后，不是结束，而是开始。

Perplexity提出了一个重要的维护机制：Gotchas Flywheel。

大意是：

Agent每失败一次，就将这个失败沉淀为一个gotcha。 如果Skill错误加载，就收紧description，并添加负例评测。 如果Skill在该加载时未能加载，就添加关键词和正例评测。 如果系统提示词发生变化，就检查Skill是否存在冲突或重复。

这说明，Skill最有价值的内容，往往不是初始编写的流程，而是后续不断积累的失败案例。

真正的专业经验，经常体现在“不要这样做”之中。

以教育AI场景为例，一个备课Skill真正有价值的gotchas可能是：

这些内容不是通用模型天然稳定掌握的。

它们来自真实课堂、真实教研、真实失败。

这就是Skill的复利效应。

这篇文章对教育AI产品尤其具有启发意义。

因为教育场景不是简单的问答交互。

教师备课、评课、命题、作业讲评、学生诊断、家校沟通、公开课打磨，每个环节都有大量隐性经验。

这些经验难以通过一个通用对话界面解决。

未来学校级AI助理的核心资产，应该是一套持续维护的教育Skill库。

例如：

这里最重要的不是编写大量提示词。

而是将教师的真实工作经验、常见错误、输出标准、评价尺度、学校流程沉淀进去。

这才是教育AI从概念走向实用的关键。

过去我们开发软件，核心是功能模块。

未来构建Agent，核心是能力体系。

功能是按钮、页面、流程。 能力是判断、经验、边界、审美、行业知识和失败处理机制。

Perplexity这篇文章的真正价值，不在于告诉我们如何编写一个文件，而在于揭示了Agent工程的新范式：

将专家经验模块化，将任务能力可调用化，将失败案例资产化，将模型行为评测化。

这件事一旦做成，Agent才不只是一个会对话的界面，而会变成一个稳定工作的智能系统。

今天许多AI产品看起来相似，都是输入框、文件上传、工具调用、联网搜索。

但真正的差距会逐渐体现在底层：

谁有更优的Skill设计？ 谁有更完善的评测体系？ 谁积累了更多gotchas？ 谁能将组织经验持续沉淀为可复用能力？

这才是下一阶段Agent产品的护城河。

一个真正有用的Agent，不应该每次都像新员工一样从零开始。

它应该了解这个组织的运作方式。 了解这个行业有哪些禁忌。 了解专家为何如此判断。 了解过去哪里出过问题。 了解何时该调用何种能力。 也了解何时不该滥用能力。

这就是Skill的意义。

它不是提示词工程的简单升级，而是Agent产品走向生产环境的基础设施。

从这个角度看，未来企业和学校真正需要建设的，不只是AI助理，而是一套自己的Skill库。

谁能将日常工作中的隐性经验沉淀下来，谁就能让AI真正成为组织能力的一部分。