Claude Code 的远程会话与桥接能力
Claude Code 的远程会话与桥接能力终端在本地，不代表执行一定在本地从很多人的直觉看，Claude Code 是一个本地终端工具。但源码很清楚地表明，它已经内建了不少远程能力： remote session direct connect bridge / remote-control SSH 相关流程 这意味着它的 UI、执行位置和会话位置可以分离。 先看入口层就知道这不是边缘功能main.tsx 里直接有这些导入： 12import { createRemoteSessionConfig } from './remote/RemoteSessionManager.js';import { createDirectConnectSession, DirectConnectError } from './server/createDirectConnectSession.js'; 这说明远程能力不是后面某个插件临时加的，而是入口层就正式考虑的运行形态。 先看远程能力关系图状态层已...
Claude Code 的多 Agent 与子任务机制
Claude Code 的多 Agent 与子任务机制它早就不只是单线程助手了如果只把 Claude Code 看成“一个主对话框里的模型”，你会错过它很重要的一条演化方向：它已经明显在支持多 Agent、子任务和协作型运行。 从源码能看到几个非常关键的信号： AgentTool SendMessageTool TeamCreateTool TaskCreateTool agentNameRegistry viewingAgentTaskId 这已经不是单线程工具的思路了。 先看它在工具层的入口12345678910111213export function getAllBaseTools(): Tools { return [ AgentTool, ... ...(isTodoV2Enabled() ? [TaskCreateTool, TaskGetTool, TaskUpdateTool, TaskListTool] : []), getSendMessageTool(), ...(isAgentSwarms...
Claude Code 的 Skills 系统
Claude Code 的 Skills 系统很多人把 Skill 想简单了第一次接触 Claude Code 的人，通常会把 Skill 理解成： 一段写好的 Prompt 一个 Slash Command 别名 或者一份放在仓库里的说明文档 这些理解都沾边，但都不完整。 从源码看，Claude Code 里的 Skill 更准确的定义是： 一套可以被系统加载、被模型发现、再由 SkillTool 正式执行的技能模块。 也就是说，Skill 不是普通文档。它在 Claude Code 里有自己的加载链路、发现链路和执行链路。 先从直觉上理解：Skill 到底解决什么问题Claude Code 已经有很多工具了，为什么还要单独做一套 Skills？ 因为很多复杂任务的问题，并不是“工具不够”，而是模型不知道： 这类任务应该按什么步骤做 这个团队平时遵循什么规则 某个场景下应该优先用哪些工具 哪些坑要提前避开 举个很典型的例子： “帮我提交代码” 不是一个简单命令 “做一轮安全审计” 也不是一个单步动作 “去线上排查问题” 更不是一句 Prompt 就能稳定完成的事 ...
插件、Skills 与 Agent 派生：Claude Code 如何走向平台化
插件、Skills 与 Agent 派生：Claude Code 如何走向平台化一个成熟系统不会只靠内置功能成长如果 Claude Code 只依靠官方内置能力，那它最多是一个很强的产品。但从源码目录看，它已经在向另一个方向演化：平台化 。 最明显的信号有三类： 插件系统 Skills 系统 Agent / Team / 子任务能力 插件：把能力装配交给生态源码里能看到不少和插件有关的模块： 插件加载 命令注入 插件技能 市场与安装管理 插件错误与刷新机制 这说明插件不是“外挂脚本”，而是被正式纳入会话能力图谱里的。 插件、Skills、Agent 三者不是并列替代关系它们解决的问题并不一样： 插件解决“系统如何长出新能力” Skills 解决“经验如何被复用” Agent 派生解决“任务如何被分工” 把这三条线放在一起看，平台化方向就非常明显。 Skills：把经验和流程显式化Skills 的意义很容易被误解。它不只是“额外说明文档”，更像是把一些专业经验、约束和工作流包装成可注入的能力单元。 这样做的价值是： 把某类任务经验固化下来 减少每次...
MCP 与 LSP 集成
MCP 与 LSP 集成先记住一句话如果说 Claude Code 的内置工具解决的是“我自己会什么”，那 MCP 解决的就是“我还能接入谁”。 很多人第一次接触 MCP，会把它理解成“插件协议”。 这个理解不能算错，但太浅了。从 Claude Code 源码来看，MCP 更像一层 外部能力接入总线 ： 外部工具可以接进来 外部资源可以接进来 外部 prompts 可以接进来 外部 skills 也可以接进来 真正重要的不是“又多了几个工具”，而是 Claude Code 的能力边界可以在运行时被重新扩展 。 Claude Code 里的 MCP，不只是调一个 server从源码看，Claude Code 对 MCP 做的事情远比“连上一个 server”多。 services/mcp/client.ts 负责的是完整的 MCP 客户端层，里面至少覆盖了这些事： 不同传输方式的连接 OAuth 和认证刷新 tools/list 拉取 resources/list 拉取 prompts/list 拉取 工具调用时的重试和交互 资源工具注入 MCP...
从源码看 Claude Code 的产品边界与局限
从源码看 Claude Code 的产品边界与局限看源码不只是为了赞叹，也要看边界Claude Code 很强，但研究一个系统如果只看它“做到了什么”，很容易失真。更有价值的做法，是同时看它： 为什么强 为什么要这么复杂 它的边界和代价是什么 第一条边界：它依然高度依赖工具与上下文从源码能看到，Claude Code 的很多能力来自： 工具系统 上下文注入 权限与状态管理 MCP / LSP / 插件扩展 这说明它的强，不是凭模型裸奔得来的。反过来说，如果这些配套能力缺位，它的表现也会明显下降。 也就是说，它不是“换个模型就能复制”。 第二条边界：复杂度非常高只看几个核心文件你就能感受到： main.tsx 极重 commands.ts 极长 AppState 很复杂 Bash / 权限 / 远程能力都有大量细节 这说明 Claude Code 的代价之一，就是系统复杂度很高。高复杂度带来的问题包括： 维护成本高 心智负担重 功能之间更容易相互影响 第三条边界：安全不是可选项，而是持续负担越强的工具，越需要强的权限治理。这点...
Claude Code 的 Plan Mode 在架构里处于什么位置
Claude Code 的 Plan Mode 在架构里处于什么位置Plan Mode 不是一个普通“模式切换按钮”很多人会把 Plan Mode 理解成：“先写计划，不直接写代码”的产品交互。但从源码看，它远不只是一个 UI 状态，而是贯穿： 工具系统 权限系统 会话状态 审批流 的一套架构能力。 先看它在工具层的存在方式在 tools.ts 里，Plan Mode 不是神秘隐藏能力，而是明确的工具： 123456789export function getAllBaseTools(): Tools { return [ ... ExitPlanModeV2Tool, ... EnterPlanModeTool, ... ]} 这说明 Plan Mode 的进入和退出，都是系统正式建模过的操作，而不是临时插进去的布尔开关。 先看整体关系图ExitPlanModeV2Tool 很能说明它的真正定位来看关键定义： 1234567891011121314export const ExitPlanModeV2Tool: Too...
权限与安全机制解析：为什么 Claude Code 不会无脑乱跑
权限与安全机制解析：为什么 Claude Code 不会无脑乱跑真正可用的工程代理，必须先解决安全问题一旦一个 AI 系统能读写文件、执行命令、访问外部资源，安全问题就不再是附属功能，而是主功能的一部分。 Claude Code 在这件事上明显下了很大功夫。从 ToolPermissionContext、权限请求组件、规则过滤逻辑都能看出来，它不是事后补丁式安全，而是架构级安全。 权限不是单点判断，而是多层控制从源码结构看，Claude Code 的权限体系至少有几层： 当前 permission mode always allow / deny / ask 规则 工具级过滤 特定场景下自动拒绝或避免弹窗 对危险规则的剥离 也就是说，系统不是只有“执行前问一下”这么简单。 权限系统在架构里分布得很散，但目标很集中你会在多个位置看到权限相关代码： ToolPermissionContext 各类 permission request 组件 工具过滤逻辑 某些自动模式与避免弹窗逻辑 虽然实现分散，但目标始终一致： 在不牺牲自动化价值的前提下，把危险动作控...
状态管理解析：AppStateStore 里到底保存了什么
状态管理解析：AppStateStore 里到底保存了什么Claude Code 不是一次性脚本，而是长期运行界面只要看 state/AppStateStore.ts，你就会立刻意识到一件事：Claude Code 绝不是一个“执行一下就退出”的普通 CLI。 它内部维护了大量 UI 与会话态数据，这说明它本质上是一个终端应用。 这里保存的状态远比你想象的多AppState 里能看到很多类型的信息： 当前 settings、model、verbose、状态栏文本 工具权限上下文 任务列表与前台任务 MCP 客户端、工具、命令、资源 插件启用状态和错误 通知队列与 elicitation 队列 远程连接状态 prompt suggestion、thinking、session hooks Todo、attribution、file history Companion、tmux、browser panel 等界面状态 这已经不是简单的“页面状态”，而是完整运行时状态。 为什么终端程序会需要这么重的状态因为 Claude Code 不只是显示文本，它还要同时协调很多异步对象： 模...
LSPTool：语言服务接入
LSPTool：语言服务接入它让 Claude Code 获得 IDE 级代码智能LSPTool 的意义不在于“又多了一个搜索工具”，而在于： Claude Code 不再只依赖文本搜索，而是能调用语言服务器做语义级理解。 这让它可以做： go to definition find references hover document symbol call hierarchy 也就是说，它已经接近 IDE 里的“代码智能”层。 关键源码tools/LSPTool/LSPTool.ts： 12345678910111213141516const inputSchema = z.strictObject({ operation: z.enum([ 'goToDefinition', 'findReferences', 'hover', 'documentSymbol', 'workspaceSymbol', 'goToI...