智能体还是技能？答案是两者并存

在模型上下文协议热度还未消退之前，Anthropic再次推出了另一个重磅产品：智能体技能。

智能体是完整的决策实体，具备系统提示、工具访问、支撑模型（如Claude、ChatGPT等）以及让它们能够协调工作流程和管理状态的智能体循环。

新的智能体技能是模块化、声明式的专业知识包——将程序化知识组织成可重用的单元，智能体可根据需要逐步加载。

这引发了一个有趣且根本性的架构问题：什么应该是智能体，什么应该是技能？这一选择对范围管理、上下文窗口可靠性、可扩展性和可评估性都有实际影响。

答案不是二选一，而是让智能体具备技能。

早期智能体系统的局限性

早期的智能体系统遇到了可预见的瓶颈。团队为每个用例构建专门的智能体：客户服务智能体、编程智能体、研究智能体。当这些智能体需要新功能时，开发人员会更新系统提示或创建全新的智能体。这种方法可行，但很快就会变得难以管理。

这种模式在各个组织中重复出现：新的边缘案例需要修改提示，有时能解决问题，但往往在其他地方造成回归。智能体缺乏从执行中学习或跨上下文转移知识的机制。上下文窗口因越来越复杂的指令或矛盾而变得臃肿，导致智能体分心、困惑或无法推理冲突信息。

我们曾经认为智能体在不同领域会根据提示和工具表现得截然不同。但底层的模型-智能体关系实际上比我们想象的更通用。这一认识提出了不同的模型：配备专业能力库的通用智能体。

技能的优势

技能让我们能够在不改变架构的情况下迭代领域专业知识。

它们主要是声明性的，意味着领域专家可以在不修改智能体逻辑的情况下贡献能力。安全团队可以将其合规工作流程打包成技能。数据工程团队可以编码其ETL最佳实践。这些贡献无需修改智能体的核心系统提示或决策循环。

当智能体遇到新场景时，技能提供了清晰的责任边界。团队可以更新一个领域的技能，而不会影响另一个领域的回归。技能可以版本化、独立测试，并基于遥测数据改进，所有这些都不会有系统提示工程的脆弱性。

技能支持渐进式加载，逐步引入资源以帮助解决上下文臃肿问题。任何使用智能体的人可能都经历过上下文窗口臃肿时会发生什么，2025年的研究表明，过载上下文窗口会导致令人意外的失败模式。

渐进式加载解决了这个问题：在运行时，智能体只看到技能元数据（名称和描述）。只有当智能体确定技能与当前任务相关时，完整内容才会加载。这意味着打包到技能中的上下文量实际上可以是无界的，而不会影响智能体的推理能力。

实际应用案例

我们在构建clickhouse.build时面临了这个架构决策问题，这是一个智能体编程助手，帮助开发人员将分析工作负载从Postgres迁移到ClickHouse。我们的命令行界面最初提供四个专门的智能体：扫描器识别代码库中的分析查询、数据迁移器设置ClickPipes、代码迁移器添加ClickHouse接口同时保持向后兼容性，以及QA智能体验证更改。

范围刻意狭窄：Postgres查询和TypeScript代码库。这种特异性使智能体性能良好，但限制了其适用性。当Anthropic在2025年10月发布智能体技能时，我们看到了在不牺牲质量的情况下扩展这一狭窄范围的机会。

通过引入技能，我们现在可以支持其他在线事务处理源（如MySQL和MongoDB）、Python和Java代码库，以及更灵活的QA工作流程，而无需重写我们的核心智能体。语言客户端维护者可以为其领域（Golang、Java、Python）开发技能，而无需触及智能体编排逻辑。我们可以围绕特定技能构建评估并独立改进它们。

我们的智能体通过评估维持范围和质量，而技能使组织内的领域专家能够贡献，并通过渐进式加载保护上下文窗口。

选择指导原则

那么，什么时候应该构建智能体或技能？

构建智能体的情况：

- 需要具有多步决策树的完整工作流程编排

- 跨复杂操作的状态管理

- 通过系统评估进行质量控制

- 防止滥用的范围边界

构建技能的情况：

- 跨上下文适用的可重用程序化知识

- 非开发人员的领域专业知识贡献

- 通过选择性加载保护上下文窗口

- 可以独立发展的能力

许多现有的智能体——实际上是带有工具访问的结构化提示——可能只需最少的更改就能成为技能。但某些用例确实需要完整智能体提供的控制、范围管理和可评估性。

未来展望

智能体AI的未来不是在智能体和技能之间做选择，而是在正确的时间为智能体配备正确的技能。智能体进行编排、维持范围并通过评估确保质量。技能打包专业知识、保护上下文窗口并使领域专家能够贡献。

这种架构已经在重塑像clickhouse.build这样的生产系统，随着技能与MCP一起成为开放标准，它有望成为默认的发展方向。

Q&A

Q1：智能体技能是什么？它与智能体有什么区别？

A：智能体技能是模块化、声明式的专业知识包，将程序化知识组织成可重用的单元。与智能体不同，技能主要是声明性的，可以被智能体根据需要逐步加载，而智能体是具备完整决策能力的实体。

Q2：为什么说智能体和技能应该并存而不是二选一？

A：因为它们解决不同的问题。智能体负责工作流程编排、状态管理和质量控制，而技能提供可重用的专业知识、保护上下文窗口并支持领域专家贡献。两者结合可以实现更好的系统架构。

Q3：clickhouse.build是如何应用智能体技能架构的？

A：clickhouse.build最初有四个专门的智能体处理Postgres到ClickHouse的迁移。引入技能后，他们可以支持MySQL、MongoDB等更多数据源和Python、Java等语言，无需重写核心智能体逻辑。