今天是 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. 把团队流程写进 System Prompt：越写越长，越改越乱，还没法审计谁改了什么。应该进 Skill，用 Git 管。 2. 工具越接越多，但没有"先后顺序"：模型每次走的路线都不一样，产出自然不稳定。需要 Skill 定义流程骨架。 3. 有连接但没权限边界：能读、能写、能删混在一起，上线就容易出事故。MCP 的权限管理不是可选项。 4. 输出没有格式标准：看起来像人写的，但团队没法复用，也没法做自动校验。Skill 里定义固定输出格式。 5. 上来就多 Agent：协作成本先爆炸，真正的问题（流程与验收）反而被掩盖。先把单 Agent 做到位。 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] 都做到了
→ 恭喜，你可以开始考虑模型升级和记忆系统了
