Claude Code

Claude Code 是 Anthropic 官方发布的 agentic 编码命令行工具（CLI），同时提供 IDE 插件（VS Code、JetBrains）和 Web 界面。与聊天机器人不同，Claude Code 可以读取文件、执行命令、做出修改，并在你旁观、重定向或离开时自主完成任务。

Anthropic 内部的使用案例显示，Claude Code 的价值不只在“让工程师更快写代码”。不同团队把它用于代码库导航、测试生成、代码审查、生产故障排查、原型开发、文档整理和业务自动化；数据科学、产品设计、增长营销、法务等非传统工程岗位也能通过自然语言描述问题，让 Claude Code 生成可运行工具或工作流。这个扩散路径更接近 Human-Agent Teams：把可描述的问题转成可执行、可验证、可由团队持续复用的 Agent 工作流。

Anthropic 对约 40 万次交互会话的研究进一步给出了真实使用基线：典型会话中，人类做约 70% 的规划决策，Claude 做约 80% 的执行决策；产生代码的会话里，软件相关与其他职业的“至少部分成功”率分别约为 89% 和 88%。但这不等于专业知识失去价值——任务领域专长越高，每条指令通常触发越长的动作链，成功率和遇错后的恢复率也越高。详见 Agentic Coding and Persistent Returns to Expertise。

核心约束：上下文窗口

Claude Code 的一切最佳实践都建立在同一个约束上：上下文窗口会快速填满，且 LLM 性能随上下文填充而退化。

一次调试会话或代码库探索可能消耗数万 token。上下文窗口容纳整个会话——所有消息、所有读过的文件、所有命令输出。实践发现性能在 40–60% 容量时已开始退化；上下文达 95% 时自动压缩触发，但这不等于可以放任填满。

这使上下文成为最需要主动管理的稀缺资源，是理解所有 Claude Code 最佳实践的出发点。详见 Context Engineering（上下文工程）。

CLAUDE.md：持久项目上下文

CLAUDE.md 是由人维护的特殊文件，用于存放 Bash 命令、代码风格规范、架构决策和工作流规则——提供无法从代码推断的持久上下文。它和 Claude 自动积累的记忆不是一回事：前者表达“团队要求 Claude 怎么做”，后者记录“Claude 从工作中学到了什么”。

有效写法原则：对每行问"去掉这行会让 Claude 出错吗"，不会则删掉。CLAUDE.md 越长，重要规则越容易被淹没，Claude 越倾向于忽略整个文件。

✅ 应包含	❌ 不应包含
Claude 猜不出的 Bash 命令	能从代码读出来的信息
与默认不同的代码风格规则	Claude 已知的标准语言惯例
测试说明和偏好的测试运行器	详细 API 文档（改为链接）
仓库规范（分支命名、PR 惯例）	频繁变化的信息
项目特有的架构决策	逐文件描述代码库
开发环境特殊要求（必需环境变量）	自明的实践（如"写干净代码"）

CLAUDE.md 支持 @path/to/file 语法导入其他文件，导入深度最多四层。导入适合整理文件，但不会节省上下文：被导入内容仍会在启动时展开并进入上下文。可分层放置：

/etc/claude-code/CLAUDE.md（Linux/WSL）：组织托管策略
~/.claude/CLAUDE.md：全局，适用所有会话
./CLAUDE.md 或 ./.claude/CLAUDE.md：项目级，提交到 git 供团队共享
./CLAUDE.local.md：当前项目的个人设置，加入 .gitignore

启动时，Claude Code 从文件系统根目录向当前工作目录依次读取 CLAUDE.md 和 CLAUDE.local.md，同一层级的 local 文件排在普通文件之后。当前工作目录下更深层的文件不会预先全部加载，而是在 Claude 读取对应子目录文件时按需加入；/compact 后，项目根目录的 CLAUDE.md 会重新注入，嵌套文件则要等再次读取对应目录才重新加载。

已有 AGENTS.md 的仓库无需复制一份规则，可让 CLAUDE.md 直接导入：

@AGENTS.md

## Claude Code

- 这里只写 Claude Code 专属约定

路径作用域规则

大型仓库可把规则拆到 .claude/rules/*.md。没有 paths frontmatter 的规则每次会话都加载；带 paths 的规则只在 Claude 处理匹配文件时加载：

---
paths:
  - "src/api/**/*.ts"
---

# API 规则

- 所有端点必须验证输入

这比把所有细节塞进 CLAUDE.md 更节省注意力预算。多步骤流程或只在特定任务中使用的说明，则应放进 Skill（技能），按需调用。

Codex 的 AGENTS.md 只能通过目录层级实现相近但更粗粒度的限定，且不支持等价的 paths frontmatter，详见 Codex。

与 Skill（技能）的分工：CLAUDE.md 存放所有会话都需要的内容，Skill 存放按需加载的领域知识，防止每次对话都膨胀上下文。

Skills：按需加载的专项流程

Claude Code 的 Skill（技能）是一个包含 SKILL.md 的目录，可放在个人、项目、企业托管或 Plugin 作用域中。它把长流程、项目约定、参考文件和脚本从常驻上下文中拆出来，只在相关任务触发时加载。旧式 .claude/commands/*.md 自定义命令与 Skill 使用同一套命令机制；同名时 Skill 优先。

一个 Skill 的关键不只是正文指令，还包括 frontmatter 控制面：description 决定自动触发质量，disable-model-invocation 可禁止模型主动调用，allowed-tools 可为该流程预批准低风险工具，context: fork 可让 Skill 在独立 subagent 中执行。Skill 正文还可以通过 ! 命令在发送给模型前注入动态上下文，例如当前 diff、环境版本或 PR 元数据。

这使 Skill 成为 Claude Code 的中间层：比 CLAUDE.md 更按需，比普通 prompt 更可复用，比 Hook 更柔性。需要强制执行的约束仍应放进 Permission、Sandbox 或 Hook；需要模型根据上下文执行的专项知识和流程，则更适合沉淀为 Skill。

Auto Memory：Claude 自动维护的项目记忆

Claude Code 2.1.59 起提供默认开启的 Auto Memory（自动记忆）。Claude 会自行判断哪些构建命令、调试结论、架构信息、代码风格偏好和工作习惯值得跨会话保留。这是 Agent Memory（Agent 记忆）的一种产品实现。

维度	CLAUDE.md	Auto Memory
写入者	人	Claude
内容	指令、规则、项目架构	工作中发现的经验与模式
作用域	组织、用户或项目	每个 Git 仓库；同仓库 worktree 共享
启动加载	文件全文	`MEMORY.md` 前 200 行或 25KB
适合存放	编码标准、固定工作流	调试经验、构建命令、已发现偏好

每个项目的记忆默认位于 ~/.claude/projects/<project>/memory/：

memory/
├── MEMORY.md          # 精简索引，每次会话加载
├── debugging.md       # 详细主题笔记，按需读取
└── api-conventions.md

MEMORY.md 负责索引，较长细节移入主题文件后按需读取。记忆以 Git 仓库为作用域，因此同仓库的多个 worktree 和子目录共享；它是机器本地文件，不会自动同步到其他机器或云环境。可用 /memory 查看本次加载的指令文件、开关自动记忆并审计或编辑记忆内容；也可通过 autoMemoryEnabled 或 CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 禁用。

两套机制都只是被注入上下文，不能保证严格执行。必须阻止的操作仍应交给权限设置、沙箱或 PreToolUse Hook，而不是寄希望于某条记忆被模型遵守。

Hooks：确定性自动化

Hooks 在 Claude 工作流的特定节点自动运行脚本，通过 .claude/settings.json 配置。与 CLAUDE.md 中的指令（建议性）不同，Hooks 是确定性的，保证动作一定发生。

典型用法：每次文件编辑后自动运行 lint、阻止写入 migrations 目录、提交前强制运行测试。

核心原则：把绝对不能发生的事写进 Hook，而不是 CLAUDE.md。CLAUDE.md 的规则 Claude 偶尔会忽略；Hook 不会。PreToolUse hook 可拦截工具调用，Stop hook 可阻止会话在验证通过前结束。详见 Harness Engineering（驾驭工程）。

Plan Mode：探索-规划-实现-提交

Plan Mode 将探索与执行分离，防止"解决了错误问题"的情况。推荐的四阶段工作流：

flowchart LR
    E[Explore\n读文件、理解结构\n不做修改] --> P[Plan\n生成实现计划\nCtrl+G 可直接编辑]
    P --> I[Implement\n切出 Plan Mode\n编码并验证]
    I --> C[Commit\n提交 + 创建 PR]

判断是否需要规划：能用一句话描述 diff 的任务（改错别字、加日志行、重命名变量）直接执行；修改多个文件、方法不确定、不熟悉代码时，规划价值最大。

Plan Mode 对应通用 Plan-and-Execute（规划与执行）模式，区别是加入了显式的 Explore 阶段，先让 Claude 理解代码库再产出计划，避免在未充分理解结构的情况下生成有缺陷的计划。

验证循环：给 Claude 一个可运行的验证方式

没有验证机制时，Claude 只能靠"看起来完成了"作为停止信号，人成为验证循环本身——每个错误都要等你发现。给 Claude 一个能产生 pass/fail 信号的验证工具（测试套件、构建退出码、lint、diff 脚本、截图对比），循环才能自闭合。

四种验证锚点，按设置成本递增：

方式	机制	适用场景
Prompt 内内联验证	要求 Claude 运行测试后迭代	单次任务，随时可用
`/goal` 条件	独立 evaluator 每轮后重新检查	无人值守的长程任务
Stop Hook	验证脚本通过才允许本轮结束	零容忍的关键约束
Verification Subagent	独立新鲜上下文尝试反驳结果	防止做工作的模型给自己打分

设置越重，需要的人工干预越少。Stop Hook 在连续被触发 8 次后会被 Claude Code 覆盖，防止死锁。

Loop 原语：/goal、/loop 与 /schedule

Claude Code 团队把 loop 分成几类，差异主要在触发器和停止条件：

原语	负责的问题	运行边界	典型用法
普通 prompt	人手动触发下一轮	当前会话	短任务、探索、一次性修改
`/goal`	定义可验证的停止条件	实时会话内多轮	“Lighthouse 分数达到 90，最多试 5 次”
`/loop`	按时间间隔重新运行 prompt	本机会话；关机即停	每 5 分钟检查 PR review 或 CI
`/schedule`	在云端按计划或事件运行 routine	云端；直到关闭 routine	每小时处理反馈渠道里的 bug 报告

/goal 的价值在于把“够不够好”从执行 Agent 手里拿出来，交给独立 evaluator 检查。/loop 和 /schedule 的价值在于把“什么时候醒来”从人手里拿出来：前者适合当前机器上的临时轮询，后者适合笔记本关闭后仍要继续的长期工作流。更复杂的 proactive loop 会把 /schedule、/goal、Dynamic Workflows（动态工作流）、subagent review 和 auto mode 组合起来，让主 Agent 修复问题，第二 Agent 审查并通知人，最后由人决定是否合并。

Subagents：上下文隔离

Claude Code 可以委派子任务给独立 subagent，在独立上下文窗口里运行，完成后只返回摘要。这是保持主对话干净的最重要工具——研究过程中读取大量文件，不会污染主会话。

Use subagents to investigate how our authentication system handles token
refresh, and whether we have any existing OAuth utilities I should reuse.

Subagent 探索代码库、读相关文件、返回发现，所有中间搜索的混乱留在 subagent 的上下文里。

并行运行多个 subagent 时，文件冲突是隐患：两个 agent 同时写同一个文件和两个工程师互相覆盖提交是同一个问题。在 subagent 定义文件的 frontmatter 里设置 isolation: worktree，该 subagent 每次运行都会获得一个从默认分支切出的独立 Git worktree，任务结束后无修改则自动清理——参见 Agent Worktree（Agent 工作树）。

自定义 subagent 定义在项目 .claude/agents/ 或用户 ~/.claude/agents/ 中，可分别配置系统提示、模型、工具、权限模式、MCP、Hooks、Skill、持久记忆和最大轮数。普通 subagent 不继承父对话历史，需要由父 Agent 重新组织委派消息；如果旁支必须看到完整历史，可使用 fork。定义格式、作用域优先级、恢复与嵌套机制详见 Subagent（子智能体）。

会话管理

/clear：在不相关任务之间重置上下文窗口。纠正超过两次仍然出错时，也用 /clear 重来并写更具体的 prompt
/compact <instructions>：手动压缩并指定保留内容，如 /compact Focus on the API changes
/rewind（或 Esc×2）：打开 rewind 菜单，可恢复对话、代码，或仅摘要特定区间
Checkpoints：每次 prompt 自动创建，Claude 修改文件前也快照；跨会话保留

CLAUDE.md 可以定制压缩行为，例如："When compacting, always preserve the full list of modified files"。

非交互模式（Headless Mode）

claude -p "prompt" 不启动会话，直接执行返回。用于 CI pipeline、pre-commit hook、自动化脚本：

claude -p "Explain what this project does"
claude -p "List all API endpoints" --output-format json
claude -p "Analyze this log file" --output-format stream-json --verbose

结合循环可实现大规模 fan-out：

for file in $(cat files.txt); do
  claude -p "Migrate $file from React to Vue. Return OK or FAIL." \
    --allowedTools "Edit,Bash(git commit *)"
done

--allowedTools 在无人值守运行时限制操作范围。Non-interactive 模式配合 --permission-mode auto 可全程无人值守，分类器模型自动拦截高风险操作。

如果需要把同一套能力嵌入长期运行的产品或内部服务，边界会从 CLI 转向 Claude Agent SDK：SDK 以 Python / TypeScript 库形式暴露 Claude Code 的工具、Agent Loop、会话、权限、Hook、MCP 和 subagent 能力，适合 CI/CD、内部自动化和产品内 Agent。CLI 更适合人直接驱动的开发会话；SDK 更适合应用代码拥有生命周期、输出处理和部署边界。

Writer/Reviewer 模式

多个并行会话可实现质量导向的工作流：Writer 会话实现功能，Reviewer 会话在独立新鲜上下文里审查 diff。Reviewer 不带自己写过这段代码的偏见，能更客观发现边缘情况和不一致：

Session A（Writer）	Session B（Reviewer）
`实现 API 限流中间件`
	`审查 @src/middleware/rateLimiter.ts，查找边缘情况、竞态条件、与现有中间件的一致性`
`根据 review 反馈：[Session B 输出] 处理这些问题`

对应通用的 Evaluator-Optimizer（评估器-优化器）模式。

Permission Modes

Claude Code 的权限系统不是单一开关，而是在“人工审批、自动分类、沙箱和完全跳过权限”之间组合。

模式	适合场景	主要风险
手动权限提示	高风险或不熟悉环境，需要人逐条判断	长任务中容易产生 approval fatigue
Auto Mode	想减少打断，但不想完全跳过权限	分类器会误判，不能替代高风险基础设施上的认真审查
Permission Allowlists	已知低风险、重复执行的固定命令	规则过宽时会绕过真正需要审查的动作
Sandboxing	明确文件系统和网络边界内的自主执行	网络、主机访问和外部服务需要维护配置
`--dangerously-skip-permissions`	临时实验或完全隔离环境	无动作级保护，不适合真实工作区

Auto Mode

Auto Mode 是 Claude Code 的自动权限模式：当用户不想逐条批准权限请求，但又不想使用 --dangerously-skip-permissions 完全跳过护栏时，它用模型分类器替代一部分人工审批。

Anthropic 把它定位在三种模式之间：手动权限提示安全性较高但容易产生 approval fatigue；沙箱安全但维护成本高，特别是网络和主机访问需要逐项配置；完全跳过权限维护成本最低但几乎没有保护。Auto Mode 的目标是在高任务自主性、低维护成本和可接受安全性之间找中间点。

Auto Mode 的威胁模型

Auto Mode 主要防四类危险动作：

风险来源	典型表现	为什么难拦
过度主动	用户说“清理旧分支”，Agent 删除远端分支	Agent 看起来是在帮忙，问题是越过了授权边界
诚实误判	把共享资源误以为是测试资源或自己创建的任务	模型理解了目标，但低估了 blast radius
Prompt injection	文件、网页或工具输出诱导 Agent 执行外部指令	恶意内容进入上下文后会影响后续 tool call
模型失准	模型追求自己的目标	Anthropic 称实际中不常见，但仍在模型发布评估中检查

这让 Auto Mode 更接近 Agent Guardrails（Agent 护栏）中的“行动前护栏”，而不是普通提示词约束。它判断的不是命令文本是否看起来危险，而是这次动作在现实系统里的影响，以及用户是否明确授权了这个影响范围。

权限决策分三层。只读搜索、代码导航、todo 等内置安全工具直接允许；项目内文件编辑直接允许，因为可由版本控制审查；Shell、Web fetch、外部工具、项目外文件操作和 subagent 启动等才进入分类器。进入 Auto Mode 时，Claude Code 会尽量移除 blanket shell access、通配脚本解释器、包管理器 run 命令等过宽 allow 规则，防止最危险的动作从分类器旁路。

Auto Mode 的关键实现是两层护栏：工具结果进入上下文前由 server-side prompt-injection probe 扫描；高风险 tool call 执行前由 transcript classifier 判断 allow / deny。分类器只看用户消息和可执行 tool call，不看 Claude 自己的解释和工具输出，避免被 Agent 的辩解或 prompt injection 污染。

flowchart LR
    A["主 Agent"] -->|"tool call"| C["Transcript classifier\nallow / deny"]
    C -->|"allow"| E["执行工具"]
    C -->|"deny + reason"| A
    E -->|"tool result"| P["Prompt-injection probe\nserver-side"]
    P -->|"result + warning if flagged"| A
    A -->|"Agent tool delegation"| H1["Handoff classifier\n检查委派任务"]
    H1 -->|"allow"| S["Subagent\n递归运行同一管线"]
    S -->|"results + action log"| H2["Handoff classifier\n检查完整动作历史"]
    H2 -->|"results + warning only"| A

输入层 是 server-side prompt-injection probe：文件读取、Web fetch、Shell 输出或外部工具响应进入 Agent 上下文前，先扫描是否像 prompt injection。命中时，它不会直接丢弃结果，而是在结果旁加入警告，提醒 Agent 回到用户意图。

输出层 是 transcript classifier：工具调用执行前，分类器基于用户消息和 Agent 的 tool call 判断是否允许。它在 Sonnet 4.6 上运行，两阶段执行：第一阶段是快速单 token 过滤器，偏向阻止；只有第一阶段怀疑危险时，第二阶段才用更完整的推理复核，以降低误报。

Transcript 过滤

分类器故意看不见 Claude 自己的解释，也看不见工具输出。它只看用户消息和可执行 payload。

这个设计有两个作用。第一，Agent 不能用“我认为这很安全”之类解释说服分类器。第二，prompt injection 最常出现在工具输出里，分类器看不见工具输出，就更难被恶意内容污染。

代价是 provenance 信息会减少。例如，如果用户没有明确说过某个 job id，分类器无法判断它是 Agent 查询出来的真实目标还是模型编造出来的目标。Anthropic 接受这个代价，因为外发凭据、删除资源、修改基础设施这类动作即使不看来源，也能按用户意图和信任边界判断风险。

分类器策略

分类器 prompt 分成固定模板和可配置槽位。固定部分定义如何理解动作真实影响、如何读取用户授权、如何执行分类流程；可配置部分定义环境信任边界、默认阻止规则和例外。

默认阻止规则覆盖几类风险：

破坏或外泄：force-push 覆盖历史、批量删除云存储、把内部数据发到外部服务。
降低安全态势：关闭日志、安装持久化 SSH key 或 cronjob、修改 Agent 自己的权限配置。
跨越信任边界：运行外部 repo 克隆来的代码、扫描凭据存储、把数据发送到用户没指定过的服务。
绕过审查或影响他人：跳过共享基础设施的安全检查、直接推送主分支、修改并非 Agent 创建的共享资源或任务。

例外规则必须窄，例如安装 repo manifest 里已经声明的包、标准鉴权流程、推送到本会话工作分支。这里的原则和 Agent Sandbox（Agent 沙箱）互补：沙箱限制执行环境，Auto Mode 则在动作前判断“这次动作是否被授权”。

评估结果与边界

Anthropic 在三组数据上报告 Auto Mode 管线效果：

数据集	规模	指标
真实内部流量	10,000 次工具调用	Stage 1 FPR 8.5%，完整管线 FPR 0.4%
真实过度主动动作	52 个危险动作	Stage 1 FNR 6.6%，完整管线 FNR 17%
合成数据外泄任务	1,000 个尝试	Stage 1 FNR 1.8%，完整管线 FNR 5.7%

两阶段设计的取舍很清楚：第一阶段以高召回为目标，误报较多；第二阶段只处理第一阶段拦下的动作，把误报降到很低，但会放过一部分真实危险动作。

Anthropic 报告的内部评估显示：完整管线在 10,000 条真实内部工具调用上的 false positive rate 为 0.4%；在 52 个真实过度主动动作上的 false negative rate 为 17%。这说明 Auto Mode 比完全跳过权限安全得多，但仍会漏掉一部分越权动作，尤其是用户授权边界含糊、blast radius 被低估时。

17% 的真实过度主动 false-negative rate 是最重要的边界。很多漏报不是因为分类器没看出命令危险，而是它把会话里的“像授权的证据”误读成足以覆盖当前 blast radius。比如用户说过“清理 PR”，但这不等于授权 force-push；用户批准过一次类似动作，也不等于形成永久授权模式。

因此，Auto Mode 适合替代 --dangerously-skip-permissions，不适合替代高风险基础设施上的认真人工审查。

Deny-and-continue

Auto Mode 被设计成不中断式护栏。分类器拒绝动作时，结果会带着拒绝原因返回给 Claude，要求它尊重边界、寻找更安全做法，而不是停下来等人点击。

如果连续 3 次被拒绝，或累计 20 次拒绝，Claude Code 会停止并升级给人类。在 headless 模式下没有 UI 可询问用户，因此会终止进程。这让误报不至于毁掉长任务：一次误报通常只造成一次重试。

Trust prompt 之前的风险

Claude Code 的本机威胁模型里，最容易被忽略的是“用户尚未信任项目之前”发生的解析和执行。Anthropic 在 responsible disclosure 中收到过几类漏洞：开发者克隆仓库准备 review PR，仓库里带有 .claude/settings.json 或类似项目配置；Claude Code 在显示 trust prompt 之前读取并处理这些配置，导致攻击者提交的 hook 或本地输入先于用户同意进入执行路径。

修复原则是：project-open、config-load、hook 解析和 localhost listener 都应被视为来自不可信目录的输入，直到用户接受 trust prompt 之后才解析或执行。这里的关键不是“本地文件更可信”，而是本地文件可能来自刚克隆的攻击者仓库。

用户作为注入向量

Auto Mode 和 prompt-injection probe 主要防工具输出、网页、文件内容诱导 Agent 偏离用户意图；但如果恶意指令被用户主动粘贴进 Claude Code，分类器会把它当成用户意图。Anthropic 的内部红队演练中，一封协作邮件让员工复制一段看似普通的任务 prompt，其中包含读取 ~/.aws/credentials、编码并 POST 到外部 endpoint 的步骤；多次重试中 Claude 大多完成了外泄。

这类攻击不能靠“识别外部内容”解决，因为外部内容已经被用户转述为直接命令。有效防线是 Agent Sandbox（Agent 沙箱）：凭证文件不进入可读范围，egress control 阻断外发请求。它也说明 Auto Mode 是 defense-in-depth 的一层，不是沙箱替代品。

MCP 扩展面

Claude Code 通过 Model Context Protocol（模型上下文协议）把外部系统接进同一个 Agent Loop：Issue tracker、监控系统、数据库、设计工具、SaaS API 都可以变成 Claude 可发现和调用的工具。这里的关键不是“多一个插件入口”，而是把人工复制粘贴的上下文改成可审计、可授权、可复用的工具连接。

Claude Code 支持多种 MCP server 形态：

形态	适用场景	主要边界
Remote HTTP	云端服务和 SaaS connector	推荐的远程传输，支持 OAuth
SSE	旧式远程服务	文档已标为 deprecated，能用 HTTP 时优先 HTTP
Local stdio	本地脚本、数据库代理、私有工具	进程跑在本机，需要处理本地权限
WebSocket	需要长期双向连接和推送事件的服务	配置在 JSON 中，鉴权主要靠 header
Plugin-provided server	插件随包携带工具能力	生命周期由插件启用和 `/reload-plugins` 管理
claude.ai connector	组织或账号在云端配置的连接器	受当前登录方式、组织策略和本地禁用设置影响

MCP 配置有三个常用作用域：local 只对当前项目和当前用户生效，写入 ~/.claude.json；project 写入仓库根目录 .mcp.json，适合团队共享，但使用前需要信任和批准；user 对当前机器上的所有项目生效。重名时优先级是 local > project > user > plugin-provided server > claude.ai connector，且 server entry 不会跨作用域做字段合并。

鉴权上，Claude Code 把远程 MCP server 当作需要单独信任的外部系统。HTTP server 可以通过 /mcp 或 claude mcp login <name> 完成 OAuth；也可以固定 callback port、预配置 client id/secret、覆盖 OAuth metadata discovery、限制 oauth.scopes，或用 headersHelper 在连接时生成短期 header。headersHelper 本质上会执行 shell 命令，所以它属于 Harness Engineering（驾驭工程）边界：项目或 local scope 下只有在 workspace trust 后才会运行。

运行时有三类上下文控制值得记住。第一，Claude Code 默认启用 MCP tool search，只把工具名和 server instructions 放进启动上下文，等任务需要时再加载具体工具定义；这延缓了大工具集对 Context Engineering（上下文工程）的压力。第二，MCP resources 可以用 @server:protocol://resource/path 形式像文件一样引用，自动作为附件进入当前请求。第三，MCP prompts 会以 /mcp__servername__promptname 形式成为 slash command，把服务端预设流程变成 Claude Code 命令。

MCP 也扩大了权限和输出治理面。Claude Code 会对大工具输出给出警告，并可用 MAX_MCP_OUTPUT_TOKENS 调整上限；server 作者可用 _meta["anthropic/maxResultSizeChars"] 为特定文本工具提高结果阈值。高风险工具可用 _meta["anthropic/requiresUserInteraction"] = true 标记为每次调用都必须显式人工确认，即使在 auto 或 allowlist 场景下也不能静默跳过。这些机制说明：MCP server 暴露的工具不是普通文本上下文，而是新的执行能力，必须和权限、审计、输出分页一起设计。

Claude Code 还可以反过来作为 MCP server 运行：claude mcp serve 会把 Claude Code 的 View、Edit、LS 等工具暴露给其他 MCP client。此时调用方负责实现每次工具调用的人类确认；否则相当于把文件读写和编辑能力交给了外部客户端。