Agent Skill 方法论对比

当 AI Agent 变得通用，什么才是真正的壁垒？不是模型，而是"把经验编码为 Agent 能用的知识"的方法论。

2025 年 10 月，Anthropic 发布 Agent Skills。同一个月，阿里通义灵码的 Agent 模式正式上线。再往前几个月，顺丰科技的 UAP（统一智能体平台）已在物流场景跑了数千个智能体。
三家做的事情看似不同——一家推开放标准，一家做 IDE 插件，一家建企业 AI 中台。但它们都在回答同一个问题：
当 Agent 越来越强，如何让 Agent 不只是"聪明"，而是"懂行"？
这个问题比想象中更尖锐。Anthropic 在博客里举过一个例子：

答案很明显。今天的大模型就是那个数学天才——能推理任何问题，但缺乏"做过一万次"的积累。
Skills 就是那个"一万次"的编码。

Anthropic 对 Skill 的定义很简洁但很深刻：

关键区分：

Skill 是一个元工具（Meta-tool）——它不直接做事，而是告诉 Agent 怎么做。Skill 工具的描述字段里包含所有可用 Skill 的名字和描述，Agent 通过 LLM 推理选择匹配的 Skill，而不是通过算法路由。

这是 Skills 系统最精妙的设计：

1Level 1: 元数据（name + description）→ 始终在系统提示中，~50 tokens

2  ↓ Agent 判断相关

3Level 2: SKILL.md 完整内容 → 被触发时加载，~500+ tokens  

4  ↓ Agent 按需引用

5Level 3: references/*.md, scripts/*.py → 仅当需要时读取，无上限

这意味着你可以给 Agent 安装数百个 Skill，但上下文窗口几乎不受影响——因为只有 Level 1 始终驻留，Level 2 和 Level 3 按需加载。
实际效果：一个 PDF Skill 可能包含 5 个参考文件、3 个脚本、数千行文档，但初始只占用 ~50 tokens 的元数据。Agent 只有在真正处理 PDF 时才会加载完整指令。

Anthropic 一个重要的设计判断：

PDF Skill 的 analyze_form.py、fill_form.py、validate.py 就是例子。Agent 直接执行这些脚本，脚本的输出进入上下文，但脚本本身不占 token。
这个设计的深层逻辑：代码是确定性的，LLM 生成是概率性的。关键流程（表单填写、数据库迁移、格式转换）用脚本保证一致性，LLM 负责决策和编排。

Anthropic 的 Skill 开发方法很有意思：

1Claude A（设计者）→ 设计 Skill

2Claude B（使用者）→ 使用 Skill 完成真实任务

3观察 Claude B 的行为 → 回到 Claude A 改进 Skill

不是写好文档等人用，而是在使用中观察、迭代。这也解释了为什么 Anthropic 强调"先评估再构建"——先让 Agent 裸跑任务，找到具体失败点，再针对性地写 Skill，而不是空想"Agent 可能需要什么"。

2025 年 12 月，Anthropic 将 Agent Skills 发布为开放标准 agentskills.io。这意味着：

• 同一个 Skill 可以在 Claude Code、Claude Agent SDK、Claude.ai 之间通用
• 第三方可以构建跨平台的 Skill 生态

目前三类 Skill 正在涌现：

1. 基础能力 Skill：PDF、Excel、PPT 等日常文档处理
2. 合作伙伴 Skill：Notion、Browserbase、K-Dense 等工具集成
3. 企业专有 Skill：金融机构的 DCF 模型、医疗机构的临床试验协议生成

通义灵码有两个操作模式：

• Ask 模式：单次问答 + 代码补全。类 Copilot 的即时辅助。
• Agent 模式：Plan-Execute 循环。接收目标 → 拆解 TODO → 执行工具 → 更新计划。

由 Qwen 模型驱动，运行在 VS Code 和 JetBrains 中，底层通过 IDE 的文件系统和进程 API 实现工具调用。

根据阿里云官方文档，Agent 模式有四个核心能力：

1. 工程级变更：自主任务拆解 + 多文件编辑 + 快照回滚。不是"改一行"，是"改一个功能"。
2. 工程自动感知：自动识别框架、技术栈、依赖关系，不需要用户手动添加上下文。
3. 工具使用：10+ 内置工具（文件查找/读取/目录浏览/语义符号检索/文件编辑/错误获取）+ MCP 扩展。
4. 终端命令执行：自主决策命令，但默认需要人工确认——与 Anthropic 的 YOLO 模式形成对比。

一个值得关注的交互设计：Agent 模式会生成显式的 TODO 列表并实时更新进度：

1○ 任务尚未开始

2◌ 任务进行中

3✓ 任务已完成

这与 Anthropic Skills 的"隐含工作流"形成对比——阿里更强调用户的可见性和掌控感。

阿里在 FSE 2025（软件工程顶级会议）发表了一篇工业论文，提出了 LingmaAgent——一个针对代码仓库的自主 Issue 解决系统。核心创新在于：

• 自顶向下的仓库知识图谱：层次化结构树 → 参考图扩展
• 全面仓库探索：在修改代码之前，先对整个仓库进行深度理解
• Agentic RAG：不是简单的检索，而是 Agent 主动探索和关联

这说明阿里不仅在工程上推进 Agent，也在学术上验证其方法论。

一个微妙的差别：Anthropic 强调"Skills 是文件"，可以 Git 版本控制，可以在 Google Drive 共享，不受平台绑定。阿里的 Agent 能力深度嵌入 IDE，更"好用"但也更"锁定"。

顺丰科技的 UAP（统一智能体平台）由 AI 技术平台负责人陈迪豪主导，架构分为三层：

1┌────────────────────────────────────┐

2│         业务应用层                  │

3│  物流决策 · 路径优化 · 供应链智能体  │

4├────────────────────────────────────┤

5│        Agent 平台层                │

6│  低代码编排 · 可视化工作流 · 插件    │

7│  多智能体协作 · AgentInsight 可观测  │

8├────────────────────────────────────┤

9│         MaaS 模型服务层             │

10│  多模型接入 · 异构计算 · 高速网络    │

11└────────────────────────────────────┘

"丰知"物流决策大模型：不是通用 LLM，而是融合了顺丰 30 年物流 know-how 的行业模型。关键设计：

• LLM 交互层：理解自然语言需求
• 小模型专业层：销量预测、路径优化、包装优化
• 多智能体协作：多个 Agent 按角色分工，通过 AgentInsight 实现全链路可观测

低代码 Agent 平台：业务人员可以通过可视化界面编排 Agent 工作流，不需要写代码。这比 Anthropic 的 SKILL.md 文件更低门槛，但也更依赖平台。

顺丰的路径最"务实"——不是做通用 Agent 平台，而是用 Agent 技术直接解决物流的具体问题：路径优化提效 X%、包装成本降 Y%。这种"垂直深耕"的策略与 Anthropic 的"水平开放"形成互补。

尽管三家的实现方式不同，但它们在底层遵循同一个范式：

1通用 Agent 基座

2    +

3可组合的能力模块（Skills / Agent 模式 / 低代码编排）

4    +

5按需加载的上下文管理（渐进披露 / 工作区感知 / 知识图谱）

6    +

7确定性工具（脚本 / 内置工具 / 插件）

8    =

9懂行的专业 Agent

1. 从"建 Agent"到"建能力模块"

  Anthropic："我们不再为每个领域建专门的 Agent，而是建 Skill。"
  阿里：从专用代码助手演进到通用 Agent 模式 + 可配置工具。
  顺丰：从单点 AI 功能到统一的智能体平台。
  核心逻辑：Agent 本身变得通用，差异化的来源从"Agent 架构"转向"领域知识编码"。

1. 渐进式上下文管理

  三家都意识到：不能把所有知识一次性塞进上下文窗口。

• Anthropic：三级渐进披露（元数据 → SKILL.md → 参考文件）
• 阿里：工作区自动感知 + 按需工具调用
• 顺丰：多智能体分工 + 各 Agent 独立上下文

  核心逻辑：上下文窗口是公共资源，只要必要的、在必要的时候。

1. 代码作为确定性锚点
   • Anthropic：预写脚本 > 即时生成代码
   • 阿里：内置工具 > Agent 自由发挥
   • 顺丰：标准化插件 > 每次重新实现

  核心逻辑：LLM 是概率性的，关键路径需要确定性。

最大的误区：把公司 Wiki 转成 Markdown 就叫 Skill 了。
真正的 Skill 是流程编码：

• 不是"我们的代码规范是什么"，而是"写代码时先做 A 检查，再做 B 验证，最后用 C 格式输出"
• 不是"数据库表结构文档"，而是"查收入数据时，记得过滤测试账户，按季度汇总，用这个 SQL 模板"
• 不是"部署流程说明书"，而是"部署前运行这个验证脚本，失败就回滚，不要跳过"

Anthropic 反复强调"concise is key"、"default assumption: Claude is already very smart"——因为 Skill 的目标不是教 Agent 基础知识，而是给它只有你们公司知道的上下文和流程。

模型能力在趋同。GPT、Claude、Qwen、DeepSeek 的差距在缩小。
企业的壁垒在哪里？

• 不是模型本身，而是行业 Know-how 的 Skill 化程度
• 不是技术架构，而是业务流程的 Agent 可执行化程度
• 不是数据量，而是数据被组织成 Agent 可用形式的程度

顺丰的"丰知"模型之所以有价值，不是因为模型参数多，而是因为它编码了 30 年的物流决策经验。

Anthropic 推 agentskills.io 的动机值得深思。
如果一个企业的所有 Skill 都是用 Anthropic 的格式写的，它就被 Anthropic 绑定了。但如果 Skill 格式是开放的、跨平台的，企业就可以在不同 Agent 之间自由迁移。
对中国企业来说：

• 短期：哪个平台好用用哪个
• 长期：确保你的 Skill/知识资产不绑定在单一平台上

三条路径，适合不同阶段的企业：

• Anthropic 路径适合希望保持工具链灵活性的技术团队
• 阿里路径适合深度使用阿里云生态的开发者
• 顺丰路径适合物流/供应链等垂直行业的数字化转型

但无论选哪条路，Agent 时代的核心命题不变：你的行业经验，能不能变成 Agent 能用的"新代码资产"？

本文基于对 Anthropic 官方工程博客、Claude API 文档、通义灵码官方帮助中心、阿里云开发者社区、顺丰科技公开技术分享、FSE 2025 LingmaAgent 论文等一手资料的深入分析和交叉验证。
调研时间：2026 年 6 月