这个系列的课程带着大家学习 Claude Code，我不想一上来就带你钻某个局部概念，我想先带你站高一点，把 Claude Code 这一整套东西看完整。 只有全貌先建立起来，后面你再学 Memory、Skills、SubAgents、Hooks、MCP、Plugin、Agent SDK 时，才不会觉得这些能力彼此割裂。
先想一个问题。Claude Code 到底是什么？
有人会说，它是一个能看懂代码的 AI 助手。 有人会说，它就是命令行里的 AI 编程工具。 也有人会把它理解成一个更强的 Copilot，能读代码、改代码、跑命令、提 PR。
这些理解都对，但都只说到了一层。 如果站在 2026 年这个时间点再看，Claude Code 更准确的身份，其实是一个可编排、可扩展、可连接外部系统、还能跨端持续运行的 Agent 型编码平台。 它当然能当工具用，但真正厉害的地方，在于你可以围绕它去设计工作流，沉淀规则，挂接外部能力，甚至让它在你不盯着的时候继续干活。
换句话说，Claude Code 不只是一个工具，更像一台可以改装的机器。 你当然可以直接开，但你也可以给它加传感器、接自动化、装插件、换控制系统，最后把它变成一条稳定运转的工作流。
这一讲，我们就先把这台机器的结构看清楚。
先把 Claude Code 用起来
先别急着谈架构，先把它跑起来。 按照当前官方文档，Claude Code 已经不只是终端工具了，它现在同时覆盖终端、VS Code、JetBrains、Desktop、Web、移动端接力这些入口。不过如果你是第一次接触，我还是建议从 CLI 开始，因为这条链路最直，也最容易理解它背后的工作方式。 安装方式很简单：
bash
# macOS / Linux / WSL
curl -fsSL https://claude.ai/install.sh | bash
# Windows PowerShell
irm https://claude.ai/install.ps1 | iex
# Homebrew
brew install --cask claude-code
# WinGet
winget install Anthropic.ClaudeCode进入项目目录后执行：
bash
cd your-project
claude第一次启动会引导你登录。现在和早期相比，一个很明显的变化是，Claude Code 的可用入口已经比以前丰富得多。除了 Claude 订阅和 Anthropic Console 账户之外，终端 CLI 和 VS Code 这条线也支持第三方提供方接入。这个变化很重要，因为它说明 Claude Code 已经不再只是一个单点产品，而是在往平台化能力演进。
如果你习惯 IDE，如今官方已经不再是简单地让你外部开个终端配合编辑器使用。 VS Code 扩展现在是正式主入口之一，而且是官方推荐方式。 它已经支持 inline diff、@ 引用文件和目录、计划审阅、对话历史、多会话并行、远程会话恢复、终端输出引用、checkpoint 回溯这些能力。 JetBrains 也有专门插件，不再只是弱集成。
Desktop 和 Web 这两条线也值得单独提一下。 Desktop 现在已经不是一个单纯的图形壳子了，它支持多会话并行、可视化 diff 审阅、Schedule 页面、Dispatch 拉起会话、以及本地和远程任务的统一管理。 Web 端也不只是网页聊天框。现在它可以直接发起云端代码会话、跑长任务、创建 cloud scheduled tasks，还能把任务从浏览器或手机接回本地终端。
所以,今天再说 Claude Code 是一个命令行工具，严格来说已经不够了。 更准确的说法应该是，它有一个终端起家的内核，然后长出了一整套多端协同的工作界面。
从使用者到驾驭者
大多数人一开始用 Claude Code，路径都差不多： 用户提一个问题，Claude 回答，任务结束。 这当然已经很有价值。你可以让它理解项目、补一个函数、修一个 bug、整理提交、生成 PR。对很多人来说，这一步已经足够强了。 但如果只停在这里，其实你用到的还是表层能力。你是在用它，却还没有真正驾驭它。 真正的进阶发生在你开始把 Claude Code 当成工作流底座来使用的时候。这个时候你不只是提问，你会开始设计规则、配置记忆、拆分任务、接外部工具、设置自动检查、安排周期任务，甚至让它从 Telegram、Discord、iMessage、CI、Slack 或 Webhook 主动接收事件。
这个差别，用学开车来打比方就很容易理解。
- 使用者知道方向盘怎么打，油门怎么踩，刹车怎么停。
- 驾驭者知道发动机、传动、制动、底盘、辅助系统是怎么协同工作的，知道什么路况该开什么模式，甚至能自己改装这辆车。
对 Claude Code 也是一样。
- 使用者知道怎么提问，怎么让 Claude 帮自己写代码。
- 驾驭者理解记忆系统、Slash Commands、Skills、SubAgents、Hooks、MCP、Channels、定时任务、Plugin、Agent SDK 这些能力分别负责什么，又该怎么组合。
我们这一讲的目标，就是先让你看到引擎盖下面的东西。
Claude Code 底层技术全景图
如果把 Claude Code 的能力拆开看，我更愿意把它理解成四层：
- 基础层，也就是记忆与上下文层
- 扩展层，也就是能力与行为层
- 集成层，也就是外部连接与持续运行层
- 编程接口层，也就是 Agent SDK 层
这个拆法的好处在于，每一层都在回答一个不同的问题。
- 第一层回答的是，Claude 怎么记住你是谁、项目是什么、规则有哪些。
- 第二层回答的是，它具体靠什么机制去完成任务。
- 第三层回答的是，它怎么和外部世界打通，以及怎么持续运行。
- 第四层回答的是，如果默认能力还不够，你能不能直接用代码编排它。
下面我们一层一层看。
基础层：Memory，记忆系统
很多人提到 Claude Code 记忆时，第一反应还是 CLAUDE.md。这个理解不能说错，但今天已经不完整了。 截至 2026 年，Claude Code 的记忆体系至少要分成两部分看。 第一部分是你主动写进去的记忆，也就是各种 CLAUDE.md、规则文件和设置。它负责告诉 Claude 项目结构、技术栈、团队规范、禁区和工作流要求。 第二部分是它自己积累出来的 auto memory。这个变化非常关键。很多时候你没有手工写某条规则，但 Claude 在多次会话里逐渐学会了项目的 build 命令、常用调试路径、依赖安装方式、某个服务该怎么启动，这些信息会被系统自动沉淀下来，并在每次会话开始时一起加载。
官方文档现在明确把这两套记忆并列出来了：
CLAUDE.md适合写规范、规则、架构、流程- auto memory 适合沉淀 Claude 在实际工作中自己总结出的 build、debug 和偏好信息
也就是说，Claude Code 今天已经不只是读你给它的手册，它还会自己做笔记。 再往细一点看，CLAUDE.md 也已经不是单层结构。现在官方文档里支持：
- 组织级记忆
- 用户级记忆
- 项目级记忆
- 通过
@path/to/import引入其他规则文件 - 用
.claude/rules/做更细粒度的目录或模块规则
所以你可以把这套机制理解成 Claude 的入职培训体系。
- 组织级记忆，像公司通用制度
- 用户级记忆，像你个人的工作习惯
- 项目级记忆，像当前项目组开发规范
- 模块级规则，像具体子系统的补充说明
很多人一开始把 CLAUDE.md 写成一份超长说明书，结果 Claude 反而执行不稳定。 原因很简单，记忆系统的价值从来都不在于字数多，而在于信息是不是稳定、具体、可执行。真正有用的记忆，往往是简洁的规则、明确的约束和高频会用到的背景，而不是把所有知识一股脑塞进去。
扩展层：四大核心组件
这一层是 Claude Code 的能力中心，原始框架里把它拆成 Commands、Skills、SubAgents、Hooks。我觉得这个拆法今天依然成立，而且比以前还更清楚。
Commands，斜杠命令
Slash Command 的本质，是把一段你会高频重复使用的提示词或工作流显式打包成一个入口。你手动触发，它稳定执行。 它特别适合那些你不希望 Claude 自己猜，而希望你明确下达指令的场景。比如统一 commit 流程、固定 review 模板、部署动作、PR 评论整理、晨报生成，这些都很适合做成 Slash Command。 它的核心价值是确定性。 你知道什么时候触发，团队知道什么时候会执行，行为边界也清楚，审计和复用都方便。 所以如果你的诉求是某件事每次都按固定动作来，Command 往往比让模型自己判断更靠谱。
Skills，技能
Skill 的价值，不在于它能不能调用工具，而在于它把判断逻辑、行为策略、执行顺序和上下文约束装进了一套能力说明里。 这一点特别容易被低估。 很多人第一次接触 Skill，第一反应是，这不就是高级一点的 tool 包装吗。其实差别很大。Tool 解决的是我能不能做。Skill 解决的是我什么时候该做、该怎么做、做到什么程度。 比如用户说，帮我看看这段代码有没有安全问题。 如果只是工具调用，Claude 可以直接去读代码。但如果真要做好，它其实要先判断代码类型、运行环境、用户输入来源、鉴权逻辑、暴露面，再决定是轻量审一遍，还是深入挖。这个过程显然不是固定 checklist，它更接近一种上下文判断。Skill 在这里更像一套专家行为模式。 所以我更愿意把 Skill 理解成，给 Claude 植入一种专业姿势。它不只是单个函数，也不只是单段脚本，它是一整套处理问题的方法论。
SubAgents，子代理
SubAgent 是 Claude Code 很有威力的一环，因为它同时解决了两个问题：
- 任务拆解
- 上下文隔离 以前很多人对 AI 编程的一个抱怨是，越聊越乱。前面聊的是架构，后面掺进测试，再后来又塞进一堆日志、diff、命令输出，主上下文很快就脏了。 SubAgent 的作用，就是把高噪声、高负载、可分工的任务拆出去，让专门的代理独立处理，再把结果带回来。 而且现在和早期相比，SubAgent 已经不是一个纯高级技巧了。官方文档里已经把内建子代理做成了正式组成部分，至少包括：
- Explore，偏只读探索，适合搜索和分析代码库
- Plan，偏规划和方案思考
- General-purpose，通用执行型代理 除此之外，你也可以通过
/agents或配置文件创建自定义子代理。Claude 会根据每个子代理的描述，自行判断什么时候该委派。
这点很重要。它说明 Claude Code 的任务拆分能力，已经从 prompt 小技巧，变成了产品级能力。
Hooks，钩子
如果说前面三个组件解决的是能力和分工，那么 Hook 更像系统里的守门员和自动化总线。 早期很多人对 Hook 的理解还停留在，工具调用前后跑个 shell 脚本。这个理解今天已经太窄了。 现在官方 Hook 体系的覆盖面明显更完整，它已经覆盖了大量生命周期事件，比如：
SessionStartInstructionsLoadedUserPromptSubmitPreToolUsePermissionRequestPostToolUseSubagentStartSubagentStopPreCompactPostCompactSessionEnd
而且 Hook 的类型也不再只有命令脚本。官方文档现在明确支持：
- command hooks
- HTTP hooks
- prompt hooks
- agent hooks
- MCP tool hooks
- async hooks
这意味着什么？ 意味着 Hook 已经从一个简单脚本回调点，进化成了一套完整的事件自动化系统。 你可以在 PreToolUse 阶段拦高风险命令，可以在 SessionStart 阶段自动注入上下文，可以在 PostToolUse 阶段异步跑测试，可以在 PreCompact 和 PostCompact 上围绕上下文压缩做状态处理，也可以在 MCP elicitation 阶段接管交互。 尤其是新版本的 async hooks，我觉得很实用。以前你要在写文件后自动跑一套测试，经常会卡住主流程。现在可以把这类检查挂成异步 Hook，在 Claude 继续工作的同时后台执行，结果在下一轮再反馈回来。 从工程视角看，Hook 现在已经更像一条内部自动化总线，而不只是一个补丁点。
集成层：连接外部世界，以及让 Claude 持续运行
如果说前两层解决的是 Claude 知道什么、会做什么，那这一层解决的就是它怎么和外部世界连接，以及怎么在你不盯着的时候继续工作。 原来的讲法把这一层主要概括成 Headless 和 MCP，这个框架依然成立，但今天如果只讲这两个，就明显不够了。因为这一层近阶段扩张得很快，至少还要把 Channels、三种定时机制、Remote Control、多端协同都放进来。
Print Mode / Headless / 非交互运行
以前讲的是 Headless，这个概念在今天依然有用，但在官方文档里更常见的实际入口，已经是 print mode 这套非交互模式，比如 claude -p。 它的意义不只是无人值守，而是把 Claude Code 变成一个可以被脚本、CI、流水线和外部系统稳定调用的执行单元。现在你可以：
- 用
claude -p直接跑单次任务 - 用
--resume、--continue续接会话 - 用
--output-format或--json-schema拿结构化输出 - 用
--remote发起云端会话 - 用
--remote-control让本地会话可从其他设备接管
这意味着 Claude Code 今天的自动化能力，已经不只是能不能无人值守，而是能不能被系统化编排。
MCP，模型上下文协议
MCP 到今天已经不需要再解释成一个前沿新概念了，它已经是 Claude Code 连接外部工具的标准入口之一。 数据库、Jira、Slack、Google Drive、内部 API、知识库，这些原来和 Claude 之间隔着一层手工复制粘贴的东西，现在都可以通过 MCP 接进去。 而且 MCP 现在的能力也已经比最初丰富很多。除了工具调用之外，官方文档里还明确支持：
- MCP resources，并且可以通过
@直接引用 - MCP elicitation，也就是让服务端在中途向用户请求结构化输入
- OAuth 元数据配置
- tool search，也就是延迟加载工具定义，减少上下文占用
这里有个很值得关注的新点，就是 MCP resources。现在 MCP 服务器暴露的资源已经可以像文件一样，通过 @server:protocol://path 直接引用进提示词里了。对知识库、文档系统、数据库 schema、Issue 内容这类信息来说，这个体验比纯工具调用顺手很多。
tool search 也值得单独提一句。它默认会把 MCP 工具定义延迟到真正需要时再加载，这样即便你接了很多服务器，也不会把上下文窗口一上来就占满。这个能力对大规模工具接入非常关键。
Channels，通道机制
你刚刚提到的 channel 机制，确实是前面那版里漏掉的一块，而且它很值得单独讲。
截至 2026 年 3 月，Claude Code 官方已经把 Channels 作为 Automation 分类下的正式能力来介绍了。它目前还是 research preview，需要 Claude Code v2.1.80+，并且要求使用 claude.ai 登录，Console 和 API key 认证暂时不支持。
Channels 可以怎么理解？ 它本质上是一个能把外部事件主动推送进当前 Claude 会话的 MCP 通道。也就是说，Claude 不必自己去轮询外部系统，外部系统就可以把消息、告警、Webhook、CI 结果直接推进来。 这件事听起来很小，实际上意义很大。 因为一旦有了 Channels，Claude Code 的交互模式就从：
- 你坐在终端前主动问它 变成了：
- 终端开着，外部世界主动把事件推给它，它再在原会话里继续处理
官方当前给了 Telegram、Discord、iMessage 三个研究预览通道，还提供了 fakechat 这个 localhost demo。它们都是以 plugin 形式安装，然后通过 claude --channels plugin:... 启动。 我觉得可以把 Channels 理解成 Claude Code 的事件入口层。 如果说 /loop 解决的是定时轮询，Channels 解决的就是事件驱动。前者适合隔几分钟看看部署好了没，后者适合 CI 失败后立刻把结果推过来。 这也是为什么官方文档会明确说，想对事件实时响应，就优先用 Channels，而不是不断轮询。
定时机制：Cloud、Desktop、/loop
站在今天看，Claude Code 的定时能力已经不该再靠自己拼凑了，因为官方已经把它正式产品化了。 截至 2026 年 3 月，官方文档明确给了三种定时机制：
- Cloud scheduled tasks
- Desktop scheduled tasks
/loop
这三种机制的边界非常清楚。
1. Cloud scheduled tasks
这是跑在 Anthropic 云端基础设施上的定时任务。机器关机也能跑，适合日常 PR 巡检、夜间 CI 失败分析、周级依赖审计、文档同步这类稳定重复工作。 它可以从 Web、Desktop 或 CLI 的 /schedule 创建。每次运行会 fresh clone 仓库，支持配置环境、网络权限、连接器、仓库权限和自定义 cron 表达式。默认按你本地时区执行，最小间隔是 1 小时。 这意味着它早就超出简单 cron 封装的范畴了，官方现在给到的是一整套云端周期任务系统。
2. Desktop scheduled tasks
这类任务跑在你本机上，但不要求当前会话一直开着。只要 Desktop 应用开着、机器醒着，它就可以按计划启动新会话执行任务。 它的优势在于能直接访问你本地文件和本地工具，这一点 Cloud 任务做不到。
3. /loop
这是 CLI 里最轻量的定时能力，也是最容易上手的一种。它本质上是一个内建 bundled skill，可以在当前会话里快速设置周期任务。
比如：
bash
/loop 5m check if the deployment finished and tell me what happenedClaude 会把这个自然语言间隔转成 cron 表达式，在当前进程内后台运行。它特别适合会话内的临时轮询，比如盯部署、盯构建、盯某个 PR 状态。
不过它也有明显限制：
- 会话一结束，任务就没了
- 不跨重启持久化
- 任务默认 3 天过期
- Claude 忙时会延后触发
所以我的建议很简单。 如果你只是会话内临时盯一件事，用 /loop。 如果你需要本地文件和本地工具，但又希望稳定按时运行，用 Desktop scheduled tasks。 如果你要真正无人值守、机器关了也继续跑，就上 Cloud scheduled tasks。 也就是说，Claude Code 今天已经不再是只能靠外部 cron 驱动的系统，它自己已经内建了成体系的定时能力。
Remote Control，多端接力
另一个很容易被低估的新能力，是 Remote Control。 官方文档现在已经把它当成正式跨端协作入口。它允许你把一条本地 Claude Code 会话，通过浏览器、手机、平板继续接管。 核心点在于，任务本身依旧跑在你的本地机器上，只是通过 claude.ai/code 或移动端界面远程接管这条会话。 它的价值在于：
- 本地文件系统、MCP、工具、项目配置都还在
- 你可以在终端、浏览器、手机上交替发消息
- 网络断了、机器睡眠后还能自动重连
从使用体验上看，这相当于把本地 Agent 变成了一个可跨设备操作的持续运行单元。 如果再和 Channels 结合起来看，Claude Code 今天其实已经开始具备一种持续在线工作体的雏形了：
- Remote Control 解决你人不在电脑前，但还想接着干活
- Channels 解决外部事件主动推给当前会话
- Scheduling 解决让它周期性自己动
这三块加在一起，才是 Claude Code 今天真正和早期纯终端助手拉开差距的地方。
Plugins：从本地配置走向可分发能力包
当你把 Commands、Skills、SubAgents、Hooks、MCP 这些东西一套一套沉淀出来，想要分享给团队或社区时，就需要 Plugin。 我一直觉得，Plugin 更像一个打包容器。 也就是说，它主要负责把一组相关能力组织起来，做成可安装、可版本化、可分发、可市场化的产物。 截至 2026 年，Plugin 已经比很多人想象中更完整了。官方结构里除了常见的：
commands/agents/skills/hooks/.mcp.json现在还包括：.lsp.json，用来挂语言服务器，提供代码智能settings.json，可以指定插件启用时默认激活哪个 agent.claude-plugin/plugin.json，作为插件 manifest
这意味着 Plugin 已经不只是一个共享命令包，它正在变成 Claude Code 的能力分发单元。 特别是 .lsp.json 这一块，很值得注意。因为它说明官方已经在把代码智能这一层也纳入插件体系。你接的不只是命令和工作流，还可以接语言服务能力。 所以今天如果还把插件理解成，一堆 markdown 文件打包分享，那就有点低估它了。
编程接口层：Claude Agent SDK
如果前面几层还是配置驱动，那到了这一层，你已经可以直接写代码来编排 Claude 了。 这里有一个必须更新的点。 原来很多材料会写 Claude Code SDK，但截至 2026 年 3 月，官方已经正式把它更名为 Claude Agent SDK。这个改名不只是名称调整，背后对应的是能力边界的变化。 因为它早就不只服务编码场景了。现在官方把 Claude Code 的 agent loop、工具体系、权限模型、会话管理、上下文压缩、子代理机制、MCP 和插件能力，统一开放成了一套通用可编程接口。 所以今天更准确的理解应该是：
- Claude Code 是产品形态
- Claude Agent SDK 是这套引擎的编程入口 官方文档里现在强调的几个点，我觉得很值得你记住。
1. 它暴露的是完整 agent loop
也就是说，你拿到的不只是一个聊天接口，你拿到的是和 Claude Code 本体同源的一套代理循环能力。Claude 可以自己读文件、跑命令、改代码、用 WebSearch、用 WebFetch、用 Agent 工具拆子任务。
2. 会话管理已经很成熟
现在 SDK 不只是发一次 query。它支持：
resumecontinueforkSession- 持久化或非持久化 session
- 在指定消息点恢复会话
- 查询最近 session
这意味着你完全可以自己做一个多轮、可恢复、可回放的 Agent 系统。
3. 流式机制比以前完整很多
官方现在已经把 streaming input 和 streaming output 单独做成了能力说明。
你可以拿到：
SystemMessageAssistantMessageResultMessageCompactBoundaryMessageStreamEvent
如果启用 partial messages，还能看到文本增量、tool use 增量、message start/stop 这类细粒度事件。这个能力对做交互式 UI、进度条、实时可视化、前端消息渲染特别有用。 从某种角度看，这也可以理解成 SDK 层自己的消息通道机制。CLI 里的 Channels 解决的是外部事件如何推入会话，SDK 里的 streaming event 则解决的是 Claude 内部执行过程如何实时暴露给上层应用。
4. 子代理和插件都能程序化挂进去
TypeScript SDK 现在已经支持在 options 里直接定义 agents、hooks、plugins、mcpServers，还能动态切换 MCP server 状态，甚至支持 background task 停止。 也就是说，很多以前只能靠文件配置的能力，如今可以直接在应用代码里编排。
5. 接口还在继续演进
官方 TypeScript 参考现在还给了 V2 preview，也就是更简化的 send() / stream() 风格接口。这说明 SDK 本身还在持续抽象，未来很可能会更适合直接嵌入产品，而不只是给工程师写脚本。 如果你的诉求是自己用、团队内部沉淀工作流，用 Claude Code 本体加 Memory、Skills、Hooks、Plugins 通常就够了。 如果你的诉求是要把这套能力嵌进自己的系统、自己的产品、自己的多 Agent 编排框架里，那就应该往 Agent SDK 走。
组件关系和技术选型
前面这些组件讲完之后，最关键的问题就变成了： 面对一个真实需求时，到底该选哪种技术？ 我自己常用的判断方法，基本就三步。
第一步，先分清这是能力问题，还是流程问题
如果你是在定义一个能力入口，比如统一生成 commit message、统一做 review、统一生成晨报，那优先考虑 Command 或 Skill。 如果你是在定义执行过程中的约束和检查，比如修改文件后自动跑测试、执行危险命令前二次确认、上下文压缩前记录摘要，那优先考虑 Hook。
第二步，判断它需要显式触发，还是应该让 Claude 自己判断
如果你希望稳定、明确、手动触发，就用 Command。 如果你希望它根据上下文自己判断什么时候该介入，就用 Skill。
第三步，判断任务是否值得拆出去
如果任务噪声很大、步骤很多、容易污染主上下文，或者明显可以分工，那就该上 SubAgent。
第四步，判断它是不是外部连接问题
如果本质上是在接数据库、Jira、Slack、知识库、Google Drive、Webhook，那就进入 MCP。 如果它是外部事件主动推送到当前会话，那更像 Channels。 如果它是周期性执行，那就进入 Scheduling。
第五步，判断你要配置，还是要编程
如果现成配置就够，用 Claude Code 本体能力。 如果你要自己编排一套完整 Agent 流程，就上 Claude Agent SDK。 这套判断并不复杂，但特别实用。很多选型纠结，问题往往不在技术太多，而在一开始没有把问题归类清楚。
组合使用，才是 Claude Code 真正的威力
单独看每个组件，其实都不神奇。 一个 Slash Command，只是一个可重复入口。 一个 Skill，只是一套专家模式。 一个 Hook，只是一条自动化规则。 一个 MCP，只是一条外部连接。 一个 Channel，只是一条事件入口。 一个定时任务，只是一种周期触发方式。 但一旦这些东西开始组合，Claude Code 就不再是一个聊天工具，而是一条自动化生产线。
举个非常典型的例子。 如果你想实现这样一套流程： 每天早上自动检查开放 PR，发现高风险改动就深入审查，CI 失败时第一时间接收告警，必要时创建修复分支并通知团队。 这件事就很适合这样组合：
- 用 Cloud scheduled task 每天固定时间拉起一次 PR 巡检
- 巡检过程里调用专门的 review SubAgent
- SubAgent 根据上下文激活安全或性能 Skill
- Hooks 在真正改动代码或发起危险命令前做拦截
- CI 失败事件通过 Channels 直接推入当前会话
- Claude 通过 MCP 把结果写回 GitHub、Slack、Linear
你看，单个组件都不复杂，但组合起来之后，系统能力就完全不一样了。 这也是我一直觉得很多人低估 Claude Code 的地方。大家看到的是一个会聊天、会写代码的东西，但真正值钱的，其实是它背后的可组合能力。
总结
这一讲如果你只记住一句话，我希望是这句： Claude Code 今天已经不该再被理解成一个单纯的 AI 编程工具，它更像一套可编排的 Agent 基础设施。 你当然可以把它当助手来用，这样已经很强了。但它真正的上限，来自这些能力组合之后形成的系统性：
- Memory 负责持续上下文
- Commands 和 Skills 负责能力入口
- SubAgents 负责拆解和隔离
- Hooks 负责守门和自动化
- MCP 负责连外部工具和资源
- Channels 负责事件推送
- Scheduling 负责周期执行
- Remote Control 负责跨设备接力
- Plugins 负责打包、分发和能力市场化
- Agent SDK 负责把整套引擎开放成可编程能力
换句话说，真正厉害的地方，不在于它能帮你写一段代码，而在于你能不能让它长期、稳定、成体系地替你工作。 从这个角度看，使用者解决的是单次问题，驾驭者开始设计系统。 而你从这一讲开始，已经在往后者走了。