夜雨聆风
AI助手(02):从对话到多Agent协作——Claude Code进化史
开篇
在开始介绍具体功能的使用之前，先简要过一下AI助手的功能，看看其发展演化过程。
经常听到各种关于AI的名词：MCP、RAG、Skill、Agentic……但剥开这些概念，核心逻辑没有改变：碰到瓶颈，找到解决办法，就沉淀为一项新功能。Claude Code的功能演进是个很好的观察窗口：每个功能的出现都对应一个具体的痛点。
这条演进线不只适用于Claude Code——Cursor、Windsurf、Gemini CLI，几乎所有AI工具都在走类似的路。理解了这个脉络，面对任何新工具你都能快速判断：它在解决哪些问题，适用于什么场景。
对话：起点
一切从最简单的形态开始：你在终端或者网页输入一个问题，AI回答你。
这个阶段的AI更像一个被动的顾问——你问它答，它有知识、能推理，但只能处理文本。总结材料、翻译文档、起草邮件，没问题。但查系统里的销售数据？登录项目管理工具看任务进度？做不到。知识渊博，但没有手脚。
这里先解释一个贯穿全文的概念——上下文窗口（Context Window）。你可以把它理解为AI的”工作记忆”：你发的消息、AI的回复、加载的文件内容，全部装在这个窗口里。容量有限，塞进去的信息越多，留给新任务的空间就越少。后面你会看到，很多功能演进的驱动力，就是如何更高效地利用这个有限的工作记忆。
不过用多了你会发现一个问题：很多提示词在反复输入。
Slash Command：可复用指令
比如你每周都要写周报，每次都得告诉AI”读取本周的工作记录，按项目分类，生成工作总结，格式是……”。第一次觉得方便，第五次就烦了。重复的事情就该自动化。
Slash Command的思路很直接：把常用提示词存成文件，用 /命令名一键调用。写好一个周报模板，之后输入 /weekly-report就行。就像手机里的快捷指令。
这一步把AI交互从”每次从零开始的对话”变成了”可积累、可复用的工作流”。经验沉淀成可执行的指令，团队里一个人写好的Command，其他人也能直接用。
但Command解决的是”说”的效率。很快你会碰到另一面墙：周报里需要从项目管理系统拉数据、从代码仓库查提交记录，Command写得再好也没用——AI本身碰不到这些外部系统。
工具与MCP：从问答到Agent
这是一个关键转折。
早期的做法是给AI”硬接”几个固定工具——读文件、执行命令、搜索内容。但每个AI产品各做各的，工具接口互不兼容，生态是割裂的。
MCP（Model Context Protocol）就是在这个背景下出现的。它定义了一个标准协议，让AI通过统一接口调用外部服务——数据库、API、浏览器、文件系统，什么都能接。MCP试图像USB统一硬件接口那样，统一AI与外部世界的连接方式。
当AI能够主动调用工具执行操作时，它就从被动的问答机器变成了能自主行动的Agent。这就是”Agent”这个词真正的含义——并不神秘，就是LLM加上了工具调用能力。
但工具多了也有代价：MCP会把所有工具定义一次性加载到上下文窗口中。工具定义越多，留给真正任务的空间就越少。
Skill：把能力打包
到这里，几条线的问题汇聚到了一起。
Command能组织提示词但太简单，承载不了复杂流程。MCP打通了工具能力但全量加载太浪费上下文。安全性也需要考虑——你不希望AI在生成周报时顺手去删个文件。
Skill就是在这个交汇点上出现的。它不是替代Command或MCP，而是在它们之上的一层编排机制——用Command的方式组织指令，用MCP的工具执行操作，同时通过分层加载解决上下文浪费。
核心优势在于分层加载——平时只加载一行简短描述，调用时才加载完整内容。MCP像是把整本工具手册摊开放在桌上，Skill则像是只放一个目录页，需要哪章再翻到哪章。此外还能限制可用工具、控制触发方式、附带脚本和模板来支持复杂工作流。
我自己目前有十几个Skill在日常使用——写周报、提交代码、管理项目任务、部署服务——基本上重复性的工作流都沉淀在这里了。
但Skill再强，也是单线程执行。有些任务天然需要并行，有些任务的中间过程会挤占上下文空间——这就是下一层要解决的问题。
Subagent：独立的子代理
你让AI整理一个大型项目的文档，它翻遍上百个文件，中间输出可能比最终结论大十倍——这些中间过程把上下文窗口挤满了，AI反而忘了你最初问的什么。就像派人去图书馆查资料，他把翻过的每一页都复印回来堆在你桌上，你反而找不到重点了。
另一个问题是效率：市场分析和竞品调研可以同时做，何必排队？
Subagent的思路很简单：派出去，只告诉我结论。每个子代理是一个独立的AI实例，有自己的上下文窗口，完成后只把结果摘要返回主对话，不污染主上下文。就像团队leader把任务分配给组员，组员各自去干，最后汇报结果就行。
子代理解决了”派人干活”的问题，但它们之间不能直接通信——每个子代理只跟主对话汇报，彼此不知道对方在做什么。当任务之间存在依赖关系时，这就成了瓶颈。
Team：多Agent协作
比如筹备一个产品发布：一个代理梳理功能清单，一个准备发布文档，一个检查测试覆盖——它们的工作有依赖关系。如果功能清单改了但文档的代理不知道，写出来的发布说明就是错的。
Team模式就是解决这个问题的：多个独立的Claude实例组成团队，共享任务列表，可以互相发消息。从”leader分配任务”进化到了”团队自组织协作”。
Team目前仍然是experimental（实验性功能），官方文档也明确标注了这一点。社交媒体上很多人展示了多角色协作的酷炫案例，但实际体验下来，大部分仅限于特定场景，效果不稳定。Token（AI处理文本的计费单位）消耗随代理数量线性增长，成本不低。方向对不对？我觉得对。好不好用？还需要迭代和时间。
小结
回顾整条线：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
前三步解决基础能力：从对话到复用指令，再到获得工具成为Agent。后三步解决工程问题：怎么高效管理上下文、怎么分配任务、怎么协调协作。
如果你刚开始用AI工具，不必一步到位。从对话开始，把常用操作沉淀成Command，再根据需要接入工具——每一步都会带来切实的效率提升。
下一期，我们进入实操——用Slash Command和Skill自动化日常工作流。
参考链接
- Claude Code 官方文档
- MCP 协议官网
- MCP 规范
- Claude Code Skills 文档
- Claude Code Sub-agents 文档