今天是 2026 年 2 月 11 日。过去一段时间，我集中读完了 Anthropic 关于 Claude Agents 的四篇博客。读完之后最大的感受不是"又出了几个新名词"，而是——他们在做一件很多厂商不愿意明说的事：把 Agent 从"能聊天的能力展示"往"可稳定交付的工程系统"上推。

这四篇文章发布时间横跨 2025 年底到 2026 年初，主题分别是 Skills 与 MCP 的协同、2026 年软件构建趋势、Agent Skills 的设计理念，以及多 Agent 系统的使用时机。它们之间有一条清晰的脉络：不是教你把模型用得更花哨，而是教你把 Agent 做得更工程化。

如果你最近也在做 Agent 相关的事情，我猜你会卡在同一类问题上：

• • 到底什么时候该上多 Agent，什么时候在浪费钱？
• • 工具越接越多，模型反而越来越不稳定，怎么回事？
• • 团队的标准、流程、合规要求，怎么让模型"照做"而不是每次都要人纠正？

这篇推文，我想把四篇文章的核心框架合在一起讲清楚，并在最后给一份你明天就能动手的落地清单。

太长不看版

• • 从单 Agent 开始。 多 Agent 不是"更强"，它是"更贵 + 更难控"。只有出现特定信号才值得上。
• • 多 Agent 最常见的价值就三种：上下文保护、并行化搜索空间、专业化分工。没别的了。
• • 模型"通用能力"越来越强，但离"领域专家"还差一截。缺的不是 IQ，是积累的流程与标准。
• • Skills 解决的是"教它怎么做"：把工作流、最佳实践、模板、脚本打包成一组文件，并用渐进式披露按需加载，省上下文窗口。
• • MCP 解决的是"让它能访问什么"：标准化连外部系统与数据源（Notion、Slack、数据库、内部服务等）。
• • 最稳的组合是四层：Agent Loop（推理）+ Runtime（执行环境）+ MCP（连接）+ Skills（方法论）。分层清楚，系统才好演进。

一、先把"Agent"放回正确的分层里

很多团队一提到 Agent，脑子里是一锅粥：推理、执行、经验全搅在一起。结果就是 Prompt 越写越长，工具越接越多，产出还越来越不稳定。

Anthropic 在这几篇文章里反复讲一个分层：

这个分层的核心约束是：

推理层不要塞具体流程——流程要进 Skill。连接逻辑不要写在提示词里——连接要进 MCP。

这样做的收益很直接：

• • Skill 可以版本化、复用、审计。 谁改了什么、什么时候改的，Git 追踪得到。
• • MCP 负责"能不能连、连什么、权限是什么"，边界明确，出了事故能查到是哪条连接。
• • Agent Loop 的 Prompt 反而更短、更稳定。 你不再需要在系统提示词里塞一堆"连 Notion 用这个 API、格式按那个模板"。

用 Anthropic 原文的话说："The loop reasons, the runtime executes, MCP connects, and skills guide." 每一层有自己的事，各管各的，系统才好演进。

二、别把多 Agent 当成默认选项

"多 Agent"这个词一度很火。但 Anthropic 在 1 月 23 日那篇文章里说得很直接：大多数情况下，单 Agent 就够了。

为什么？因为一旦上了多 Agent，成本不是线性增长的：

• • Token 成本翻倍。并行搜索场景下可能 3～10 倍的 token 消耗。
• • 协调复杂度上去。谁负责合并？子 Agent 之间冲突怎么解决？怎么防止互相带偏？
• • 可观测性变差。问题出在哪个子 Agent、哪一步、什么时候开始偏的？排查成本很高。

他们给了一个非常实用的判断框架：只有当你看到清晰信号时，才上多 Agent。

三个"值得上多 Agent"的信号

信号 1：上下文被噪音淹没

典型场景：某个子任务需要拉一大堆日志、历史记录、原始数据，但最终你只需要一个结论或者一段摘要。

比如客服系统需要查订单历史、同时诊断技术问题——订单查询会产生 1000+ tokens 的中间信息，但主对话只需要一句"订单已发货，物流单号是 XXX"。

做法：让子 Agent 单独处理，主 Agent 只拿"可控长度的摘要"。你会明显感觉到：主对话更干净，后续推理更稳定。

信号 2：搜索空间太大，单 Agent 扫不完

典型场景：竞品研究、事故根因排查、替代方案评估。一条线索可能分叉出十几个方向，单 Agent 很难在有限上下文里把所有方向都覆盖到。

做法：拆成互不重叠的子方向，多个子 Agent 并行扫，然后汇总、交叉验证。代价你得提前认：并行往往意味着 3～10 倍的 token 消耗。值不值，要看这个任务对结果质量的要求有多高。

信号 3：工具太多，行为模式互相打架

当一个 Agent 手里有 20+ 工具、还跨多个不相关领域时，性能容易劣化。更常见的问题是"注意力分散"：明明该走 A 流程，它跑去试 B 工具，然后走了一条完全出乎你意料的路线。

做法：按领域拆专家子 Agent，每个只拿自己那一套工具与约束。比如 CRM 专家只管客户数据，营销专家只管活动和线索，不互相串场。

一个更好的切分方式：按"信息流"拆

很多人喜欢按"任务类型"来分 Agent，比如"搜索 Agent""分析 Agent""写作 Agent"。但 Anthropic 推荐的方式是按"信息流"切——

• • 哪些步骤会产生大量中间信息？（这些步骤适合隔离）
• • 哪些步骤是严格流程，有明确顺序和验收标准？（这些适合 Skill 管）
• • 哪些步骤需要访问外部系统？（这些走 MCP）

按信息流切，多 Agent 才会真正减噪，而不是把问题变成"多个不稳定的黑盒在互相传话"。

三、Skills：让 Agent 变成"懂行的人"，而不是"聪明的新人"

这是我觉得四篇文章里最有价值的一个概念。

Anthropic 的类比很扎心：

你愿意把报税交给一个"数学天才从第一性原理开始推导"，还是交给一个"报过几千次税的税务师"？

绝大多数人会选税务师。不是因为他更聪明，而是因为他知道哪些坑必须避开、什么格式税务局会认、哪些减免项90%的人都会漏。

今天的 Agent 就像那个数学天才——推理能力很强，但缺少积累的经验。你的公司标准格式是什么？一个输出到什么程度算"完成"？哪些错以前踩过？灰区怎么处理？这些东西不在模型的训练数据里，也不应该每次都靠 Prompt 临时教。

Skills 做的就是把这些东西打包：工作流、最佳实践、模板、脚本、资产文件，都放进一个可版本化的文件集合里。

一个简化的 Skill 目录长这样：

some_skill/
├── SKILL.md          # 主流程与触发规则（短，约500 tokens）
├── references/       # 支撑材料（长，按需加载，2000+ tokens）
└── scripts/          # 可执行脚本（当工具用）

渐进式披露：Skills 真正"工程化"的关键

这是 Skills 设计里最聪明的一个点。

传统做法是把所有流程、规范、示例一股脑塞进 System Prompt。结果呢？上下文窗口撑爆，模型"注意力"被稀释，该注意的没注意，不该执行的反而执行了。

Skills 用的是三层渐进式披露：

这意味着：你可以给 Agent 装几百个技能，但不会把上下文窗口撑爆。 大多数时候它只看到一堆名字和描述，真正需要某个技能时才读完整内容，再深入时才加载参考文档。

设计 Skill 的三个原则

写了几个 Skill 之后，我总结的实操原则：

1）SKILL.md 只写"做事骨架"

• • 触发条件：用户说了什么关键词时启用
• • 步骤顺序：第一步做什么、第二步做什么
• • 输出格式：固定小标题、必含字段
• • 质量门槛：什么情况算"完成"，什么情况要标注"待确认"

2）把"长知识"放进 references/

• • 规范文档、示例输出、模板、术语表、FAQ
• • 这些东西很长但不是每次都要看，按需加载就好

3）重复动作做成 scripts/

Anthropic 在文章里举了一个真实的例子：他们团队发现 Claude 每次都会重新写一段给幻灯片套品牌样式的脚本，内容大同小异。于是他们直接让 Claude 把它保存成一个 apply_template.py，下次直接调用就行。

这个思路适用于所有"每次都差不多"的操作：格式化报表、套 PPT 模板、批量改文件名、生成标准化输出。让模型调用脚本，比让它每次重新生成一份"差不多的脚本"靠谱得多。

技能的复杂度可以差很多

Anthropic 给了一个有意思的复杂度光谱：

• • 简单（~100 行）：状态报告编写器——基本就是模板 + 格式化
• • 中等（~800 行）：金融模型构建器——涉及数据抽取、Excel 建模、Python 计算
• • 复杂（2500+ 行）：RNA 测序流程——要协调 HISAT2、StringTie、DESeq2 多个工具

你不需要一上来就做复杂的。从最简单的开始，把一个高频流程标准化，跑通了再扩。

四、MCP：不是"更强工具"，而是"连接标准"

如果说 Skill 是"教它怎么做"，那 MCP 就是"让它能访问什么"。

Anthropic 给了一个非常好记的经验法则：

• • 解释"如何做" → 用 Skills
• • 需要"访问某物" → 用 MCP

两句话就能帮你把系统边界切清楚。

为什么要把连接独立出来？

因为"连接"这件事，本质上是工程问题，不是智能问题：

• • 权限怎么管？谁能读、谁能写、谁能删？
• • 失败了怎么重试？超时了怎么处理？
• • 速率限制怎么应对？
• • 连接行为怎么审计？出了安全事件怎么追溯？

这些东西如果放在 Prompt 里管，迟早会变成"不可控的软约束"——模型有时候会遵守，有时候会忽略，你永远不知道什么时候会出事。

Skills + MCP 一起用，效果最好

这两个东西不是二选一，而是天然互补的。Anthropic 在文章里举了两个典型的协同案例：

案例 1：会议准备（Skills + Notion MCP）

• • MCP 负责：连接 Notion——搜索页面、读取内容、创建新文档。
• • Skill 负责：定义流程——先查项目主页，再查上次会议纪要，再查相关人资料；输出要包含哪些段落、格式怎么写、什么算"完成"。

你得到的是"每次都按同一套路出材料"，而不是每次让模型自由发挥、每次出来的东西长得都不一样。

案例 2：金融分析——可比公司分析（Skills + 数据源 MCP）

• • MCP 负责：连接 S&P Capital IQ、Daloopa、Morningstar 等数据源，拉实时市场数据。
• • Skill 负责：定义方法论——用一致的公式抽数、算指标、做合规校验、按固定结构输出 comps 表。

重点不在"模型更聪明"，而在过程可控、结果可复查、合规可追溯。金融行业尤其在乎这个。

五、那篇"2026 趋势"里的真正信号

在《Eight trends defining how software gets built in 2026》里，有一个数据很值得注意：

开发者在大约 60% 的工作中使用 AI，但只能"完全委托"0～20% 的任务。

换句话说：AI 已经是日常工具了，但离"全自动"还非常远。绝大部分工作仍然需要人类主导，AI 辅助。

文章里提到了几个真实案例，也印证了这个判断：

• • Rakuten：在 vLLM（1250 万行代码库）中实现激活向量提取方法，Claude Code 自主工作了七小时，达到 99.9% 的数值准确率。但注意——这是一个边界非常清晰的工程任务。
• • TELUS：创建了超过 13,000 个自定义 AI 解决方案，工程代码交付速度提高 30%，总计节省超过 50 万小时。
• • Zapier：整个组织 89% 的 AI 采用率，内部部署了 800+ 个 Agent。

这些案例的共同特征是：不是模型变聪明了才成功的，而是流程被标准化了才规模化的。

翻译成一句接地气的话：

未来很长一段时间，你的竞争力不是"会不会用模型"，而是"能不能把工作拆成可验证、可复用、可规模化的流程"。

这也解释了为什么 Anthropic 把重点放在：

• • 多 Agent 的"何时用、怎么用"（而不是鼓励你到处多 Agent）
• • Skills 的"沉淀经验"（而不是再造一堆提示词）
• • MCP 的"连接标准"（而不是每家各写各的工具胶水）

他们甚至还推出了 Agent Skills 开放标准 ——跟 MCP 一样，Skills 也是跨平台可移植的。同一个 Skill 不管你用 Claude 还是其他平台，都应该能工作。这个方向很对：标准化才能带来生态，生态才能带来飞轮。

六、明天就能用的落地清单（给正在做 Agent 的你）

我把四篇文章的核心揉成一套"从 0 到上线"的最短路径，你可以直接对照你现在的系统。

1）先把单 Agent 做到可控

• • 写清楚一个问题：完成的定义是什么？（格式、必含字段、边界提示、失败条件）
• • 把输出做成"可检查"的：固定小标题、表格、JSON（内部用也行）。不要让模型每次都自由发挥文本格式。
• • 加一个最小评估集：10～30 个真实样本，每次改完跑一遍，别只靠"看起来不错"。

2）出现信号再上多 Agent

• • 上下文被噪音淹没了？→ 子 Agent 隔离
• • 搜索空间太大扫不完？→ 并行子 Agent
• • 工具太多互相干扰？→ 按领域拆专家

只有这三类情况，优先考虑多 Agent。 其他时候，先优化流程与技能。

3）把"流程"写成 Skill，别写进 Prompt

你团队里最常见、最值得标准化的 3 个流程是什么？先把它们做出来。比如：

• • 会议准备 / 议程生成
• • 需求评审纪要
• • 周报 / 月报
• • 事故复盘
• • 竞品分析

每个 Skill 只要做到两件事就算成功：

• • 按顺序跑，别跑偏。
• • 输出一致，别看心情。

4）外部系统统一走 MCP

把连接从 Prompt 里抽出来。你现在可能不觉得有什么，但等你接了 5 个以上的外部系统，你会感谢自己当初做了这件事：

• • 权限、审计、失败重试——放到连接层解决。
• • Skill 只管流程，不管"怎么连"。

5）最后再谈"聪明"

当流程、边界、连接都清楚之后，你再去提升模型能力（换模型、加工具、加记忆），才会有确定性的收益。

否则你会陷入一种循环：模型偶尔表现很好，但你不敢放权，最后又回到"人肉监督每一步"——那还不如不用 Agent。

七、你可能正在踩的 6 个坑（对照自查）

1. 1. 把团队流程写进 System Prompt：越写越长，越改越乱，还没法审计谁改了什么。应该进 Skill，用 Git 管。
2. 2. 工具越接越多，但没有"先后顺序"：模型每次走的路线都不一样，产出自然不稳定。需要 Skill 定义流程骨架。
3. 3. 有连接但没权限边界：能读、能写、能删混在一起，上线就容易出事故。MCP 的权限管理不是可选项。
4. 4. 输出没有格式标准：看起来像人写的，但团队没法复用，也没法做自动校验。Skill 里定义固定输出格式。
5. 5. 上来就多 Agent：协作成本先爆炸，真正的问题（流程与验收）反而被掩盖。先把单 Agent 做到位。
6. 6. 没有评估集：只能靠感觉调，调到后面就变成"这次又玄学了"。哪怕只有 10 个样本，也比没有强。

八、从一个 Skill 开始：建议你先做"会议准备"

如果你想立刻动手，我建议从"会议准备"这个场景开始。原因很简单：

• • 频率高——每周都要开会
• • 痛点明确——每次都在找材料、拼信息、写大纲
• • 验证快——下周开会就能用，效果好不好一试便知

下面是一个最小 Skill 模板，只要能跑通就算成功：

---
name: Meeting Prep (Notion)
description: 为一次会议生成可复用的会议材料：背景、问题清单、决策点、风险与下一步
---

## 触发条件
- 用户说"准备会议 / 写会议材料 / 生成议程"

## 输入
- 会议主题
- 参会人（可选）
- 项目名或 Notion 链接（可选）

## 工作流程（严格按顺序）
1. 通过 MCP 搜索项目主页与最近 2 次会议纪要
2. 提取现状、未决问题、关键指标（不确定就标注"待确认"）
3. 生成议程（含每项的目标与预计时长）
4. 生成"需要对齐的问题清单"（按优先级排列）
5. 输出一页版会议材料（固定小标题，见下方）

## 输出格式（固定，每次必须按这个来）
- 📋 背景（一段话，不超过 100 字）
- 📊 现状（3 条，每条一句话）
- 🎯 本次要决策的 1～3 件事
- ⚠️ 风险与依赖（最多 5 条）
- ➡️ 下一步（负责人 / 截止时间 / 交付物）

注意这份模板里，我刻意只写"骨架"。具体怎么在 Notion 里搜、搜哪些库、你们团队喜欢什么格式，都放进 references/ 目录，需要时再加载。

当你把第一个 Skill 跑通之后，后面再扩展"事故复盘""竞品分析""周报月报"，速度会快很多——因为你已经知道了 Skill 应该怎么写、测试怎么跑、团队怎么协作。

总结：一张图看清全局

如果让我用一句话总结这四篇文章的核心信息，那就是：

Agent 的竞争力不在于模型有多聪明，而在于你能把多少"人的经验"系统化地喂给它。Skills 是经验的载体，MCP 是能力的通道，两者缺一不可。

你现在在哪一步？

[1] 还在 Prompt 里塞所有东西
    → 先拆出 1 个 Skill

[2] 单 Agent 能用但不稳定
    → 加评估集 + 固定输出格式

[3] 想上多 Agent
    → 先确认三个信号（上下文 / 搜索空间 / 工具冲突）

[4] 外部系统越接越乱
    → 统一走 MCP，Skill 只管流程

[5] 都做到了
    → 恭喜，你可以开始考虑模型升级和记忆系统了