Claude Code、MCP 与集成 — Claude Certified Developer Foundations Prep Course

屏幕 1：到本模块结束时你将能够做什么

定向 · 2 分钟到本模块结束时你将能够做什么

Claude Code 是你的终端原生开发伙伴。

在之前的模块中，你设置了基本的 API 组件：提示词、工具模式、上下文工程、代理循环和多模态摄取；本模块直接建立在该基础之上。Claude Code 允许你在终端环境中操作同一个模型，引入了权限层、配置系统和面向团队的共享功能。MCP 协议支持与外部服务的安全集成。在本模块中，你将学习如何为强大的安全性和有效部署配置 Claude Code 和 MCP。

到本模块结束时，你将能够： 1 通过探索、规划和编码循环运行 Claude Code，并选择与工作风险级别相匹配的权限模式，使代理保持高效，同时不被授予超过任务所需的权限。 2 阅读 AI 生成的代码，以校准的信任审查输出，对可靠的发现采取行动，验证不可靠的发现，并在错误调用成本高的地方放置人工审查门。 3 使用 CLAUDE. md、规则指令文件、钩子和子代理为 Claude Code 提供持久的项目上下文。 4 将工作流打包为技能、自定义命令和插件。编写一次技能，使其在 Claude Code、Messages API 和 Agent SDK 中以相同方式运行。 5 构建一个 MCP 服务器，使工具、资源和提示词对 Claude 可用，选择与客户端和服务器通信方式相匹配的传输方式，并设置控制谁加载它的配置范围。 6 将 Claude 连接到企业系统，使用受管制客户会接受的模式对这些连接进行身份验证，并确定代码现代化工作的范围，使其能够通过安全审查。

本模块适合已经让 Claude 在代码中工作、现在必须使其可配置、可共享和安全连接到真实系统的开发者。你是实用的、代码优先的、面向模式的。本模块假设你熟悉模块 2 中的 API 模式。它不会重新教授代理循环、工具模式或上下文工程。它教授围绕工作集成的工程决策：如何在权限模型下在终端中运行 Claude Code、如何为其提供持久的项目上下文、如何打包工作流以便队友可以安装它，以及如何通过 MCP 将 Claude 连接到外部和企业系统，而不泄露凭据或未通过安全审查。

"本模块中的构建"

本模块中的所有内容都围绕一个反复出现的问题构建：在你的机器上、在你的会话中或在暂存环境中工作的代码现在必须在其他人运行它时、在生产环境中、针对真实公司系统时能够经受住考验。在你的机器上，权限模式感觉很安全，项目规则足够小以至于可以遵循，技能找到了它的脚本，凭据就在配置文件中，连接在暂存测试中有效。一旦工作离开你的机器，这些便利中的每一个都可能成为失败：权限模式删除了从未在范围内的文件，一条规则被埋在数百行中，技能指向在其他机器上不存在的路径，提交的密钥在几小时内泄露，暂存专用的配置步骤导致生产连接中断。本模块中的工作是学习哪个配置决策可以防止哪个失败，在它们出现在队友或审计员面前之前。

教育内容免责声明/通知

我们构建了这个开发者课程模块 3：Claude Code、MCP 与集成，以帮助你用 Claude 完成真实工作。将其视为教育内容。它不构成法律、财务或其他专业建议，因此请根据你自己的情况调整你所学的内容。我们的产品和服务发展迅速，因此某些内容可能包含错误或已过时；请记住在 Anthropic 网站或文档上验证。课程中使用的示例和场景是说明性的，通常是虚构的。如果课程材料提到某家公司或产品，这并不意味着 Anthropic 认可它们、它们认可 Anthropic，或者我们有关联。另请注意，你对 Anthropic 产品和服务的使用受我们的条款、政策和文档的约束；如果本课程中的任何内容与它们冲突，它们具有控制权。

屏幕 2：Claude Code 代理循环、权限模式、设置以及人工门应该放在哪里

教学权限模式与人工门·17 分钟 Claude Code 代理循环、权限模式、设置以及人工门应该放在哪里模块 2 建立了代理循环在 API 级别如何工作的基础：模型调用工具，获取结果，并继续直到任务完成。 Claude Code 在你的终端中运行相同的循环，但添加了一个额外的层：一个权限系统，它控制代理想要采取的每个操作。在你配置任何东西之前，你需要理解循环如何运行以及权限模式控制什么。

Claude Code 如何通过任务工作：探索、规划和编码当你给 Claude Code 一个任务时，它不会立即开始编写。它读取文件、追踪相关逻辑，并首先建立代码库的图景；这是探索阶段。然后，一旦它理解足够以提出更改，它就创建一个计划。计划是它打算进行的编辑的结构化描述。只有在你审查并批准计划后，它才会进入代码阶段，在那里它编写并执行更改。这个序列很重要有两个原因。首先，它产生更好的输出：Claude Code 在触及任何东西之前理解代码库，所以它做出的假设更少，捕获更多下游影响。其次，这是权限模式插入的地方：计划模式将 Claude Code 保持在探索阶段，阻止所有文件编辑和 shell 命令，直到你释放它，使其成为不熟悉的代码库或高风险工作的有用默认值。

权限模式：批准、门和约束权限模式控制 Claude Code 停下来请求确认的频率。每种模式在速度和监督之间做出不同的权衡。正确的选择取决于你对代码库的了解程度以及更改的可逆性。选择每个选项卡以查看该模式自动批准的内容、它仍然控制的内容及其限制。

default acceptEdits plan auto dontAsk bypassPermissions

自动批准的内容：仅读取。在几乎每次编辑或命令之前提示。仍然控制的内容：所有文件编辑和 shell 命令都需要确认。限制：在受信任的工作上安全但缓慢。任何新项目或不熟悉代码库的基线。

自动批准的内容：读取、文件编辑和工作目录内的常见文件系统命令（mkdir、touch、rm、rmdir、mv、cp 和 sed）。自动批准的范围限于工作目录内的路径，受保护的路径仍然提示。仍然控制的内容：所有其他 shell 命令；工作目录外的写入；对受保护路径的写入。限制：受信任的本地工作，其中 shell 执行仍需要人工审查。如果代理必须运行脚本，则不适合。

自动批准的内容：仅读取。研究和提议；不进行编辑。仍然控制的内容：所有文件编辑和 shell 命令，直到你批准计划。限制：对敏感或不熟悉的代码库进行探索和规划。不适合必须写入输出的任务。

自动批准的内容：一切，但单独的分类器首先审查每个操作，并阻止任何超出你的请求范围、针对无法识别的基础设施或似乎由敌对或不适当内容驱动的操作。仍然控制的内容：生产部署和迁移、大规模删除、凭据泄露和强制推送到主分支默认被阻止。限制：减少提示但不保证安全；这是一个研究预览，不是对敏感操作审查的替代品。可用性取决于计划、模型版本和管理员设置。在构建前始终验证当前要求。

自动批准的内容：仅在允许规则中预批准的工具，加上只读命令。自动拒绝其他所有内容。仍然控制的内容：不在允许列表上的每个工具调用都被拒绝。没有确认队列。限制：为锁定的 CI 和脚本构建。它限制得很好，但这不是减少本地交互工作摩擦的方式。限制：仅在隔离的容器或虚拟机内，其中环境是一次性的。永远不要在开发者工作站上针对实时代码库。

自动批准的内容：所有工具调用。没有确认提示，没有安全检查。仍然控制的内容：在正常操作中没有任何东西。标准权限检查被绕过；只有灾难性删除命令如 rm -rf / 和 rm -rf ~ 仍然触发最后手段提示。限制：仅在隔离的容器或虚拟机内，其中环境是一次性的。永远不要在开发者工作站上针对实时代码库。

配置位置以及它适用于谁设置可以放在多个级别，每个级别确定它包含的规则的范围。

用户级别（~/. claude/settings. json）：适用于机器上的每个项目。这是放置应该跟随你到处的偏好的正确位置，例如探索工作的首选默认模式。项目级别（. claude/settings. json，提交到仓库）：适用于克隆仓库的每个人。这是放置团队范围的约定、项目使用的工具的允许规则以及不应该被触及的路径的拒绝规则的正确位置。本地项目级别（. claude/settings. local. json）：一个项目的个人覆盖，自动 git 忽略。这是放置你自己的偏好的正确位置，这些偏好不应该提交给整个团队。企业级别（managed-settings. json，由管理员设置）：不能被用户或项目文件覆盖。组织范围的安全控制的正确位置，例如拒绝对环境文件的编辑或在所有项目中阻止特定 shell 命令。

允许和拒绝规则分层在选定的模式之上。拒绝规则总是优先于允许规则，无论模式如何。最持久的治理控制是企业级拒绝规则：它不能被任何个人开发者移除，即使设置了绕过模式也适用。

人工仍然需要查看的地方：按最坏情况成本放置审查门权限模式和拒绝规则决定代理可以在不询问的情况下做什么。它们不决定你（人类）在操作执行前仍然需要查看的地方。该决定取决于一个问题，同一个问题将安全模式与风险模式分开：如果这个操作在没有人检查的情况下运行，最坏的结果是什么？错误的成本越低，你可以让通过的就越多。成本越高，越难撤销，一个步骤就越需要人工门在它执行之前。

同样的最坏情况问题放置门，无论代理是编写代码还是在自动化步骤中无人值守运行，例如在拉取请求上评论或阻止的机器人。三个放置方式来自它：

让低风险、可逆的操作通过而不需要门。格式修复或限制在工作目录内的编辑如果错误的成本很低，所以要求人工批准每一个会购买你不需要的监督并减慢工作。这是 acceptEdits 的用途。控制任何难以撤销或到达敏感路径的操作：工作目录外的写入、破坏性 shell 命令或对安全相关或受保护文件的编辑。那里错误调用的成本很高，所以代理应该暂停并在它运行之前为人工审查表面操作。拒绝规则确定性地强制这一点，而 default 或 plan 模式在你决定时保持提示。永远不要让代理成为你的团队标记为敏感的代码更改的唯一门。那里代理的工作是人工决策的输入，而不是替代品，所以无论代理或其自己的审查听起来多么自信，人工都必须在它合并之前审查更改。

门的放置和权限模式的选择是从两个方面看待的同一决定。模式为整个会话设置默认值，门是你为成本太高而不能留给默认值的一个操作覆盖该默认值的地方；两者都来自询问如果这个不受检查地运行会破坏什么。

成本 · 复杂性 · 风险成本：在受信任的工作上以 default 模式运行会为每个工具调用添加提示延迟，这在长重构中会累积。复杂性：多个级别的设置和文件，带有覆盖层次结构，需要一致的关注。企业级的拒绝规则与项目级的允许规则相矛盾需要被维护项目配置的每个人理解。风险：风险在于为上下文使用错误的模式。例如，由于不耐烦在非隔离机器上设置的绕过模式会移除代理和你的实时文件之间的每个安全提示，并且与其他模式不同，也会移除受保护路径守卫。

屏幕 3：移除了唯一重要提示的绕过模式

注意权限模式与人工门·3 分钟移除了唯一重要提示的绕过模式

设置你切换到 bypassPermissions 以停止持续的提示，因为工作感觉很常规。代理已经表现良好好几天了，清理任务很简单，每个工具调用前的提示行为感觉像不必要的摩擦。

记录以下配对会话发生在已经无事故运行三天的代码库清理上。开发者："好的，我为这个切换到 bypassPermissions。这只是重命名旧 API 端点引用。没什么风险。" Claude Code：[扫描匹配模式 /v1/legacy/ 的文件 ... 找到 47 个文件] Claude Code：[更新端点引用 ... ] Claude Code：[运行后重命名清理脚本 cleanup. sh ... ] Claude Code：[删除了 /deploy/config/prod/ 中匹配 /v1/legacy/ 的 3 个文件 ... ] 开发者："等等。/deploy/config/prod/ 中有什么？" Claude Code：[文件包含生产部署的环境特定端点覆盖。它们已被删除。] 开发者："那个目录不应该在范围内。我在 /src/ 上工作。" Claude Code：[模式 /v1/legacy/ 匹配 /src/ 和 /deploy/config/prod/ 中的文件。在 bypassPermissions 模式下，删除前没有请求确认。] 会在 bypassPermissions 打开时被关闭的提示是会捕捉到这个错误的那个。在 default 或 acceptEdits 模式下，清理脚本不会在没有确认的情况下运行，用户可以在删除到达生产配置文件之前停止它。在 bypassPermissions 中，模式匹配比预期更广泛，没有提示站在脚本和它删除的文件之间。注意门的精确位置：它是会提示的脚本调用，而不是 rm 删除命令本身。acceptEdits 自动批准常见的文件系统命令，包括工作目录内路径上的 rm。如果 Claude 直接作为 rm 命令发出删除，acceptEdits 会无声地让它们通过；只有 default 模式为这些提示。

要注意什么绕过模式会沉默所有确认提示，包括你可能没有预料到的那些。这里的失败模式是代理匹配比你打算的更广泛的文件集，在没有检查点的模式下运行。BypassPermissions 也跳过其他模式保持的受保护路径守卫，所以即使仓库状态和 Claude 自己的配置也失去了它们的自动提示。要覆盖这个间隙，你必须在切换模式之前在敏感目录上设置拒绝规则。如果你想要更少的提示而不失去安全网，使用分类器门控模式（例如 auto）而不是完全绕过。

屏幕 4：检查点 1：组装设置文件并放置人工门

检查点权限模式与人工门·4 分钟检查点 1：组装设置文件并放置人工门现在试试。你正在为支付模块的受信任本地重构配置 Claude Code。重构应该自动批准文件编辑，但绝不能运行破坏性 shell 命令，并且文件 . env. production 绝不能被代理读取。下面是 settings. json 片段。

第 1 部分：选择组装正确配置的 settings. json 片段选择两个片段。 ✓片段 A. { "permissions": { "defaultMode": "default"} }✓片段 B. { "permissions": { "defaultMode": "bypassPermissions" } }✓片段 C. { "permissions": { "allow": ["Bash(npm run:)"], "deny": ["Bash(rm:)", "Bash(git push:*)"] } }✓片段 D. { "permissions": { "deny": ["Read(. env. production)"] } }✓片段 E. { "permissions": { "allow": ["Bash()", "Edit()"] } }

第 2 部分在重构期间，代理提议对几个生产服务读取的部署配置文件进行更改。对于那一个操作，人工门应该放在哪里？选择单一最佳答案。 a无处：设置已经自动批准编辑，所以让它运行。b人工审查并批准对部署配置文件的更改，然后执行写入，因为那里的错误值很难撤销并到达文件外的系统。c添加 bypassPermissions 以便代理永远不会暂停。d仅在下一个拉取请求期间在写入后审查更改。

提交暂时跳过

屏幕 5：使用 CLAUDE.md、规则文件、钩子和子代理的持久项目上下文

教学持久项目上下文·20 分钟使用 CLAUDE. md、规则文件、钩子和子代理的持久项目上下文之前我们看到 Claude Code 如何通过权限模式和设置文件控制操作。该配置层控制代理被允许做什么。这个集群建立在它之上：现在你将学习如何配置代理知道什么以及它如何表现，所以你在一个会话中定义的规则和项目上下文在下一个会话开始时仍然有效。

CLAUDE. md：加载到每个会话的项目文件每次 Claude Code 在项目目录中启动时，它都会查找根目录中名为 CLAUDE. md 的文件并读取它。内容被附加到你的提示词之前，任何来自你的消息到达。这意味着你放在 CLAUDE. md 中的每个约定、约束和命令都存在于每个会话的第一个提示词中，而不需要你重新陈述它。 /init 命令扫描你的代码库并生成一个启动 CLAUDE. md。生成的文件是一个很好的基线，但在使用前应该被验证。完善它以保持控制提示词结果的规则：你的测试命令、你的框架约定、代理不应该触及的路径以及与默认值不同的风格决策。大小是主要的失败模式。一个随着每个新指令而不断增长的 CLAUDE. md 可以稀释最重要的规则。一个更大的文件消耗更多的上下文窗口，这使得任何单一指令成为加载内容的更小部分，这减少了代理遵循捕捉真实错误的那一条规则的机会。将 CLAUDE. md 保持在改变行为的约束，并将其他所有内容移到按需加载的技能中。

规则指令文件：将指导范围限制到它适用的地方在前一部分中，我们建立了 CLAUDE. md 加载到每个会话中，应该保持适用于整个项目的指令。下一个问题是如何处理仅在代码库的一部分中重要的指导。这就是规则指令文件的用处：它们让你仅在相关的地方应用指令，而不是将它们加载到每个会话中。 CLAUDE. md 总是开启的，规则文件在该基线之上添加一个更窄的层。它们位于项目的 . claude/rules/ 目录中，可以使用其 YAML 前置事项中的 paths glob 限制到特定路径。以这种方式限制的规则仅在 Claude Code 处理匹配模式的文件时加载到上下文中，这允许规则应用于代码库的一部分，而不会使其余部分的上下文混乱。注意范围来自前置事项，而不是文件放置。规则文件可以组织到 . claude/rules/ 的子目录中（例如 . claude/rules/database/），但该结构仅是组织性的；没有 paths 字段的规则文件无条件地在启动时加载，与 CLAUDE. md 具有相同的优先级，无论它在 . claude/rules/ 内的位置如何。在实践中，将广泛的项目记忆和通用约束放在 CLAUDE. md 中，将狭窄的、路径特定的指导放在带有 paths 的规则文件中。像"永远不要修改数据库模式"这样的约束位于 CLAUDE. md 中，因为它适用于任何地方。像"数据库模块中的所有 SQL 必须包括显式事务边界"这样的约束位于 . claude/rules/database. md 中，前置事项如： --- paths:

"src/db/*/. sql"

--- 所以它仅在 Claude 处理这些文件时进入上下文。

钩子：在生命周期中的固定点运行你自己的脚本钩子允许你在工具调用执行之前或之后拦截和控制它。当你在 CLAUDE. md 中写一个特定规则告诉代理在每个编辑文件后运行 Prettier 时，代理大多数时候会遵循它。或者，钩子使它每次都发生，没有例外，因为钩子独立于模型决定做什么而触发。钩子在设置文件中定义，并使用 /hooks 命令配置。每个钩子绑定到一个生命周期事件、一个可选的匹配器，将其限制到特定工具类型，以及在事件触发时运行的命令。对于大多数护栏和自动化用例的核心事件是：

PreToolUse：在工具调用执行之前运行。因为它首先运行，PreToolUse 钩子可以检查工具调用并以代码 2 退出以阻止它，将原因写入 stderr 作为代理看到的反馈。这是你在配置层而不是希望代理尊重 CLAUDE. md 指令的情况下强制访问控制的方式。 PostToolUse：在工具调用完成后运行。由于调用已经发生，此事件无法阻止它，这使其成为自动化副作用的正确位置：在编辑后运行代码格式化程序、在文件更改后触发测试或记录操作以进行审计跟踪。 UserPromptSubmit：当你提交提示词时运行，在模型处理它之前。当你需要在任何工作开始之前注入上下文或验证请求时使用它。 Stop：当模型完成响应时运行。用于属于轮次末尾的后续操作，例如通知、清理任务或提交审计日志。 Notification：当 Claude Code 发送通知时运行，这发生在 Claude 需要工具权限或 Claude Code 已空闲 60 秒后。用它来将这些信号路由到外部通道或日志系统。 SessionStart：当会话启动或恢复时运行。用它来初始化状态、验证环境变量或在代理开始工作之前确认所需服务可达。 SessionEnd：当会话结束时运行。用它来进行拆卸任务、最终审计写入或通知会话已关闭。

使用 PreToolUse 事件强制路径限制的钩子在每个会话的每个工具调用中强制该约束，无论权限模式如何。这是护栏和约定之间的区别。

子代理：将工作委托给隔离的上下文子代理是一个专门的助手，Claude Code 可以委托任务给它，每个助手在自己的单独上下文中运行任务并仅返回其输出。它不继承你的主对话历史、你在上下文中积累的文件或你的当前会话状态。当你向子代理发送任务时，它从干净的状态开始，完成工作，并交回结果。内置子代理在启动时加载的内容不同；这种差异决定了你的项目规则如何应用。始终检查 Claude Code 文档中的当前列表，因为集合随时间增长，但知道影响你的项目规则的特定分割在版本中保持一致。Explore 和 Plan 内置子代理跳过 CLAUDE. md 和 git 状态以保持研究快速和便宜。它们针对速度进行了优化，所以在它们运行时，CLAUDE. md 中定义的项目级规则和仓库状态不在它们的上下文中。通用子代理加载两者。如果你委托任务给 Explore 或 Plan，并且你的 CLAUDE. md 中的规则适用，那是因为该上下文没有被加载。对于你的项目约束必须被尊重的任务，使用通用子代理或显式加载它需要的规则的自定义子代理。自定义子代理也不会自动看到你的技能。如果你在 . claude/agents 中定义自定义子代理，并且它需要特定的技能，你必须在代理的前置事项中显式列出该技能。内置代理没有预加载的技能。如果内置代理需要技能支持的行为，正确的路径是创建一个在其配置中列出这些技能的自定义子代理。

下面的地图命名每个机制、它加载什么、何时运行、其上下文成本以及什么属于它。使用它来决定哪个机制承载特定的项目知识，因为每个机制在它成本多少上下文和它如何可靠地应用之间做出不同的权衡。翻转每张卡以获得完整图景。

机制CLAUDE. md翻转 ↻ 它加载什么：完整文件内容在会话启动时前置到上下文。何时运行：每个会话，无条件。上下文成本：每个会话持久。随大小稀释。属于这里：通用项目约束、命令和框架决策。

机制规则文件翻转 ↻ 它加载什么：文件内容。通过 YAML 前置事项中的 paths glob 限制范围；没有 paths，加载如 CLAUDE. md。何时运行：当 Claude 读取匹配规则的 paths 模式的文件时。无范围规则在会话启动时加载。上下文成本：路径限制：仅在触发时添加到上下文。无范围：与 CLAUDE. md 相同的持久成本。属于这里：路径特定的指导，在其他地方会是噪音。

机制钩子翻转 ↻ 它加载什么：在生命周期事件处运行你的脚本。没有内容添加到上下文。何时运行：在配置的事件处（PreToolUse、PostToolUse 等）。上下文成本：最小：仅当路由回 Claude 时的脚本输出。属于这里：强制的护栏、自动化副作用、审计日志。

机制子代理翻转 ↻ 它加载什么：仅任务上下文。与主会话隔离。何时运行：当主会话为委托任务调度它时。上下文成本：返回摘要，而不是完整任务历史。属于这里：探索、调查和其输出会使主上下文膨胀的任务。也适用于可以分解和并行化的任务。

处理得很好返回多个会话的项目，其中稳定的规则集、每目录变化或无条件护栏会偿还设置。使用不同的方法你不会重新访问的一次性任务。对于不熟悉代码库的快速探索，设置开销是不值得的。

屏幕 6：不断增长的 CLAUDE.md，直到规则停止落地

注意持久项目上下文·4 分钟不断增长的 CLAUDE. md，直到规则停止落地

设置你的 CLAUDE. md 不断增长，因为每条新规则感觉值得添加。每个添加都是单独合理的，文件似乎是每条规则的正确位置。但在几周内，文件增长到超过 800 行。

追踪以下是来自在两个月的团队添加中积累的 CLAUDE. md 的项目的会话日志摘录。会话上下文窗口加载： CLAUDE. md：847 行内容包括：框架偏好（第 1-40 行）、测试约定（第 41-90 行）、风格指南（第 91-210 行）、依赖规则（第 211-320 行）、路径限制（第 321-360 行）、历史决策日志（第 361-700 行）、存档笔记（第 701-847 行）用户提示词："重构身份验证模块以使用新的令牌服务。不要修改 /legacy/tokens/ 目录。" Claude Code 操作：[读取身份验证模块 ... ] Claude Code 操作：[编辑 auth/service. ts ... ] Claude Code 操作：[读取 /legacy/tokens/store. ts 作为参考 ... ] Claude Code 操作：[编辑 /legacy/tokens/store. ts 以更新令牌接口 ... ] 来自 CLAUDE. md 的路径限制（第 347 行）："不要修改 /legacy/tokens/ 中的文件。" 用户："你刚刚编辑了 /legacy/tokens/store. ts。我说不要触及那个目录。" Claude Code："我道歉。/legacy/tokens/ 限制在项目指令中。编辑是在更新令牌接口的过程中进行的。我在继续之前没有标记冲突。" 规则在文件中；代理可以访问它。然而，失败是稀释：846 其他行减少了唯一重要指令的有效权重。历史决策日志和存档笔记应该被记录在某处，但它们不属于 CLAUDE. md。

要注意什么 CLAUDE. md 是改变当前会话行为的工作规则集，而不是不断增长的追加日志。你添加的每一行都减少了每一其他行的权重。如果规则是路径特定的，它属于规则文件。如果规则是历史上下文，它属于代理按需读取的单独参考文档。当你的 CLAUDE. md 增长超过几百行时，审计它：识别哪些规则是真正的会话关键，并移动其余的。你不能承受稀释的那一条规则应该是钩子的最短路径。

屏幕 7：检查点 2：拖动正确的值

检查点持久项目上下文·3 分钟检查点 2：拖动正确的值现在试试。你正在设置一个强制路径限制的钩子，下面的配置有两个空白。选择正确的：在工具调用执行之前运行的生命周期事件，以及钩子运行以阻止读取 . env. production 的命令。 { "hooks": { "__": [ { "matcher": "Read", "hooks": [{ "type": "command", "command": "__" }] } ] } }

空白 1：生命周期事件 PreToolUsePostToolUseUserPromptSubmitSessionStart 空白 2：命令 A 从 stdin 读取工具调用的脚本，检查文件路径，当路径是 . env. production 时以代码 2 退出（将原因写入 stderr）。B 将工具调用记录到审计文件并无条件退出 0 的脚本。C 打印警告并无条件退出 0 的脚本。

提交暂时跳过

屏幕 8：将工作流打包为插件：技能、自定义命令和市场安装

教学打包工作流·8 分钟将工作流打包为插件：技能、自定义命令和市场安装之前，我们涵盖了给 Claude Code 持久上下文和强制行为的机制：CLAUDE. md 用于始终开启的项目记忆、规则文件用于限制指导、钩子用于确定性护栏、子代理用于隔离任务委托。这些机制位于你的 . claude 目录中，并与项目一起版本控制。现在我们转向下一个问题：你如何打包该设置，以便队友可以在一个步骤中简单地安装它，而不是手动重复你的配置？

技能是代理按需加载的可重用工作流技能是一个便携式 Markdown 文件（SKILL. md 文件），放在 . claude/skills 中。前置事项识别技能并描述何时适用，正文保持步骤。同一技能可以在 Claude Code 中运行、通过 Messages API 调用或由 Agent SDK 加载。在三者中改变的不是文件本身；它是技能运行的地方、它如何被加载以及它被允许触及什么。一个只在 Claude Code 中看到技能的开发者可能会假设在 API 上不成立的事情，所以本部分概述了差异。

技能如何在每个中加载和运行选择每个选项卡以了解技能如何加载、步骤在哪里运行以及你需要知道什么。

Claude Code Messages API Agent SDK Claude 托管代理

技能如何加载：从文件系统上的 . claude/skills 发现。在描述匹配或当你按名称调用它时加载。步骤在哪里运行：在你的终端会话中，针对你的本地文件，在活跃权限模式和拒绝规则下。你需要知道什么：它是基于文件系统的，由设置层管理。

技能如何加载：随请求发送，在代码执行容器内运行，而不是你的应用程序环境。需要代码执行和技能测试版头。步骤在哪里运行：在 Anthropic 的代码执行容器内，而不是你的机器上。技能的文件系统和工具访问是该容器提供的任何东西。你需要知道什么：假设本地文件或本地工具的技能在这里的行为不同，因为它不在这些文件所在的地方运行。

技能如何加载：由 SDK 运行的代理加载，但是否加载文件系统设置（CLAUDE. md、技能）由 settingSources 配置控制。不要依赖默认值：始终显式设置为你打算的源，并在构建时根据 Agent SDK 参考确认当前默认行为。你通过"settingSources"（TypeScript）/ "setting_sources"（Python）设置它。步骤在哪里运行：在 SDK 运行的进程中，这是你的环境，一旦你告诉它加载文件系统源。你需要知道什么：常见的惊喜：在 SDK 下工作的技能什么都不做，因为 settingSources 从未设置，所以技能从未加载。

技能如何加载：定义一次作为命名模型、系统提示词、工具、MCP 服务器和技能的 API 资源。Anthropic 在代理运行时服务器端加载技能，所以你这边没有文件系统发现步骤。步骤在哪里运行：在 Anthropic 配置和运行的沙箱内，而不是你的环境。你的应用程序发送用户事件并读取流式结果。技能可以访问该托管沙箱提供的任何东西，而不是你的本地文件。你需要知道什么：目前是需要 managed-agents-2026-04-01 测试版头的公开测试版，会话存储在服务器端，这意味着托管代理目前不符合零数据保留或 HIPAA BAA 覆盖的条件。技能在定义代理资源时附加，而不是在会话时。更新代理定义以更改哪些技能可用。

三个可移植性规则

将描述写成匹配标准。模型通过将你的请求与其描述进行比较来加载技能，所以识别技能何时适用的描述在每个运行时中都有效，但模糊的描述在所有运行时中都无法加载。不要假设技能正文内存在本地文件系统或本地工具。在本地命令的技能在 Claude Code 中有效，但在 Messages API 上中断，其中它在没有命令的容器中运行。将技能的步骤限制在运行时保证提供的内容，或记录依赖。记住子代理不继承技能。这在模块 2 中是真的，在这里仍然是真的：子代理从干净开始，所以父代理依赖的技能必须在每个支持子代理的运行时中为子代理显式列出。

实际的收获是你可以编写一次技能并重用它，但你必须特别设计跨终端使用的能力。限制在清晰描述和无本地环境假设的技能在运行时间中干净地移植，但假设特定本地环境的技能不会。

处理得很好添加复杂性使用不同的方法

一个任务特定的程序编写一次并在交互式终端、API 集成和无头 SDK 作业中重用。每个运行时加载和沙箱技能的方式不同，所以你必须考虑 API 上的测试版头和 SDK 上的 settingSources。对于必须在项目中的每个会话中应用的指令，CLAUDE. md 仍然是正确的工具。技能用于按需、便携式程序。

给工作流一个显式入口点自定义命令是定义程序的快捷方式。在当前 Claude Code 中，技能是推荐的格式，用于显式和自动调用：你直接用 /skill-name 调用技能，或当相关时 Claude 自动加载它。较旧的 . claude/commands/ 目录格式仍然有效，但是是一个遗留过程。当你想要仅在你显式调用它时运行的工作流时，使用前置事项中带有 disable-model-invocation: true 的技能。插件命令自动命名空间：插件的名称成为前缀，所以支付插件中的 run-tests 命令被调用为 /payments:run-tests。这就是为什么两个插件可以都运送 run-tests 命令而不冲突。作者应该将插件名称视为接口的一部分，因为它为你运送的每个命令添加前缀，并意识到重命名插件会重命名它们全部。

使设置可安装的打包层插件将技能、钩子、子代理和 MCP 服务器捆绑到单个可安装单元中。插件可以通过市场打包和分发，市场是某人创建和共享的插件目录。官方 Anthropic 市场在你启动 Claude Code 时自动可用，你可以使用像 /plugin marketplace add <owner/repo> 这样的命令添加第三方市场，托管在 GitHub 仓库中。队友可以运行一个简单的安装命令来获得相同的设置。插件用一个版本化、可审计的安装替换手动设置步骤的页面。插件放置组件如下：

技能进入技能目录。钩子、子代理和设置进入各自的位置。

插件清单描述捆绑，安装命令将其连接到目标安装。插件可以由个人或企业范围下载。企业管理员可以通过托管设置在组织范围内部署插件。托管市场允许列表控制用户被允许添加哪些市场源，所以组织控制插件来自哪里。允许列表限制用户可以添加什么，但不会自动注册市场。如果你想在不要求用户运行添加命令的情况下将市场推送给所有用户，将允许列表设置与托管设置中的 extraKnownMarketplaces 配对。优先级来自部署范围：因为托管设置在配置层次结构中位于用户和项目设置之上，在托管范围部署的插件优先并且不能被用户或项目文件覆盖。查看参考层以获取确切的设置名称。

打包决策表下表识别每个层、它是为谁的以及何时使用它。

层什么是它谁是它为了什么时候使用它

技能一个 Markdown 文件在 . claude/skills 中，当其描述与任务匹配或按名称调用时加载。一个使用 Claude Code 交互的个人开发者或团队。当任务特定程序应该保持在上下文之外直到需要时，例如仅在工作需要时加载的 PR 审查或部署检查清单时使用技能。自定义命令当你显式调用它时运行定义程序的命名快捷方式。想要高频程序的可预测、显式入口点的开发者。当程序有清晰的名称并且你想直接触发它而不是依赖描述匹配任务时使用自定义命令。插件通过市场分发的技能、钩子、子代理和 MCP 服务器的版本化捆绑。想要一步安装共享、版本化设置的团队。当工作设置目前位于一台机器上并需要被共享、版本化并在团队中保持一致时使用插件。

成本 · 复杂性 · 风险成本：技能在激活时添加上下文成本，但插件添加安装和维护开销。要问的问题是你是否想一次性支付设置成本，如你对插件安装所做的那样，或重复地支付，如每个开发者运行相同手动步骤时所做的那样。复杂性：在其技能中硬编码绝对路径的插件将为作者正确安装并为其他所有人失败，因为任何烘焙到技能或钩子命令中的路径或环境假设是最可能在机器间中断的东西。风险：插件将它捆绑的组件携带到每个安装中。重要的是要记住作者依赖的拒绝规则或钩子不包括在内，除非它被显式列为捆绑的一部分。如果技能或钩子与作者依赖的护栏相关，但护栏不包括在捆绑中，那么保护不会转移到队友的机器。

屏幕 9：检查点 3：将技能放在正确的运行时

检查点打包工作流·3 分钟检查点 3：将技能放在正确的运行时现在试试。三个团队想在不同的地方重用相同的 review-checklist 技能。对于每一个，匹配技能加载和运行必须配置什么。注意：源呈现四个运行时情况。所有四个都包括在这里，所以匹配保持完整。 A 开发者想要技能在他们在 Claude Code 终端中请求审查时加载。通过显式设置 settingSources 启用文件系统源，以便代理从项目加载技能。不要依赖默认值，并在构建时根据 Agent SDK 参考确认当前默认行为。将 SKILL. md 放在 . claude/skills 中，描述与审查请求匹配。定义代理作为列出技能的 API 资源，并在调用上设置 managed-agents-2026-04-01 测试版头。编写技能，使其步骤不依赖本地文件，因为它将在 Anthropic 的沙箱中运行。发送代码执行和技能测试版头，并编写技能，使其步骤不依赖本地文件或本地工具。B 服务调用 Messages API 并希望技能作为请求的一部分运行。通过显式设置 settingSources 启用文件系统源，以便代理从项目加载技能。不要依赖默认值，并在构建时根据 Agent SDK 参考确认当前默认行为。将 SKILL. md 放在 . claude/skills 中，描述与审查请求匹配。定义代理作为列出技能的 API 资源，并在调用上设置 managed-agents-2026-04-01 测试版头。编写技能，使其步骤不依赖本地文件，因为它将在 Anthropic 的沙箱中运行。发送代码执行和技能测试版头，并编写技能，使其步骤不依赖本地文件或本地工具。C 计划的无头作业使用 Agent SDK 并期望来自仓库的技能加载。通过显式设置 settingSources 启用文件系统源，以便代理从项目加载技能。不要依赖默认值，并在构建时根据 Agent SDK 参考确认当前默认行为。将 SKILL. md 放在 . claude/skills 中，描述与审查请求匹配。定义代理作为列出技能的 API 资源，并在调用上设置 managed-agents-2026-04-01 测试版头。编写技能，使其步骤不依赖本地文件，因为它将在 Anthropic 的沙箱中运行。发送代码执行和技能测试版头，并编写技能，使其步骤不依赖本地文件或本地工具。D 产品团队想要相同的 review-checklist 技能在 Anthropic 托管的长期运行代理内运行，可通过代理 ID 跨会话访问。通过显式设置 settingSources 启用文件系统源，以便代理从项目加载技能。不要依赖默认值，并在构建时根据 Agent SDK 参考确认当前默认行为。将 SKILL. md 放在 . claude/skills 中，描述与审查请求匹配。定义代理作为列出技能的 API 资源，并在调用上设置 managed-agents-2026-04-01 测试版头。编写技能，使其步骤不依赖本地文件，因为它将在 Anthropic 的沙箱中运行。发送代码执行和技能测试版头，并编写技能，使其步骤不依赖本地文件或本地工具。

提交暂时跳过

屏幕 10：在你的机器上安装的插件在其他人的机器上失败

注意打包工作流·3 分钟在你的机器上安装的插件在其他人的机器上失败

设置插件干净地安装告诉你包被正确组装；然而，它不告诉你插件将有效运行，因为安装和执行是不同的事情。安装将文件复制到位。执行根据它们运行的机器解析这些文件指向的路径和变量。当插件作者将他们自己机器的布局烘焙到技能中时，安装在任何地方都成功，但执行在除作者自己的设置之外的任何地方都失败。这个间隙发生是因为这是作者看不到的东西。

发生了什么开发者构建了部署工作流技能，将其打包为插件，并在本地测试。本地测试通过，插件通过内部市场发送给团队，每个队友的安装成功，但队友运行技能的那一刻，它失败了。根本原因位于技能的 SKILL. md 中，在指向 /Users/alexmorgan/projects/deploy-utils/validate. sh 的命令中。该目录存在于作者的机器上，其他任何地方都不存在。技能携带了作者主目录的绝对路径，所以每个队友的运行查找了一个在他们的系统上或包含在技能中的文件。同一插件中的第二个技能依赖于环境变量 DEPLOY_TOKEN，作者在他们自己的 shell 配置文件中设置，插件的 README 从未提及它。三个队友花了两个小时调试，然后才追踪到第二个失败到缺失的变量。插件错误地将作者的机器视为团队的机器，这导致了中断。上面示例中的两个失败有相同的根本原因和相同的绝对路径。它位于 SKILL. md 中作为纯文本，审查文件的审查者可以捕捉到它。环境变量可能很危险，因为包中没有任何东西宣布相关的依赖，意味着技能运行良好，直到需要变量的步骤，只有那时它才失败。这就是为什么它可以花费三个人两个小时来修复。

要注意什么技能、钩子命令或插件组件中的任何路径引用必须相对于项目根目录或使用环境变量作为基路径。使用 $CLAUDE_PROJECT_DIR 引用存储在项目中的脚本，使用 ${CLAUDE_PLUGIN_ROOT} 引用捆绑在插件内的脚本，所以路径无论谁的机器运行它或会话从哪个目录启动都能正确解析。确保技能、钩子命令或插件组件中的任何路径引用必须相对于项目根目录或使用环境变量作为基路径。使用 $CLAUDE_PROJECT_DIR 引用存储在项目中的脚本，使用 ${CLAUDE_PLUGIN_ROOT} 引用捆绑在插件内的脚本，所以路径无论谁的机器运行它或会话从哪个目录启动都能正确解析。确保插件依赖的任何脚本、配置文件或其他资产要么捆绑在插件内，要么包含在共享项目位置中，所以每个队友在安装后可以访问相同的文件。记录插件需要的每个环境变量，并在安装时验证它，以便缺失的变量立即浮出而不是在运行中期。然后在干净的机器上测试安装，然后分发；这将捕捉构建机器可能隐藏的任何问题。

屏幕 11：检查点 4：修复损坏的插件定义

检查点打包工作流·4 分钟检查点 4：修复损坏的插件定义现在试试。以下 SKILL. md 在作者的机器上有效，但当队友克隆项目并安装插件时会失败。选择单一缺陷，然后选择正确的修复。 --- name: deploy-validate description: Validates a deployment configuration before release. ---

Steps

Run the validation script: /Users/alexmorgan/projects/deploy-utils/validate. sh 绝对路径
If the script exits with a non-zero code, report the error to the developer.
If validation passes, confirm the deployment configuration is safe to proceed.

第 1 部分 · 缺陷是什么？ A技能名称与插件名称不匹配。B描述太短，模型无法匹配。C第 1 步中的绝对路径 /Users/alexmorgan/projects/deploy-utils/validate. sh。D第 2 步应该报告给用户，而不是开发者。第 2 部分 · 正确的修复是什么？ A使用 CLAUDE_PROJECT_DIR 从项目根目录引用脚本，所以它无论项目克隆到哪里都能解析。B用指向共享网络驱动器的另一个绝对路径替换路径。C用主目录快捷方式替换路径：~/projects/deploy-utils/validate. sh。D移除第 1 步，使技能不再调用外部脚本。

提交暂时跳过

屏幕 12：构建和配置 MCP 服务器：传输、范围和 GitHub 服务器

教学MCP 服务器·21 分钟构建和配置 MCP 服务器：传输、范围和 GitHub 服务器之前的部分介绍了插件作为将技能、钩子、子代理和 MCP 服务器捆绑到单个可安装单元的打包层。本部分进一步解释了什么是 MCP 服务器捆绑以及如何构建它们。构建 MCP 服务器时，最初的决策之一是确定适当的传输机制和定义服务器的范围。

什么是 MCP 服务器，为什么它与直接连接工具不同？直接将工具连接到应用程序时，你负责定义工具的模式及其功能。两者都位于该应用程序的代码中。如果三个不同的应用程序需要访问同一外部服务，每一个都维护自己的集成。模型上下文协议或 MCP 将工具定义与单个应用程序分离，并将它们转变为称为服务器的过程。 MCP 服务器是一个暴露工具、资源和提示词的过程，MCP 客户端可以使用。Claude Code 有一个内置的 MCP 客户端。当你连接到 MCP 服务器时，Claude Code 发现它提供的工具并可以在会话期间调用它们。使用 MCP 服务器，你构建一次能力，每个连接到它的 MCP 客户端都可以访问它，而无需重新实现集成。

MCP 服务器也暴露资源和提示词 MCP 服务器暴露工具、资源和提示词。我们已经了解了工具：模型可以调用的操作。另外两个涵盖工具调用不会给你所需内容的情况。资源是服务器暴露的只读数据，供客户端获取并直接放入上下文，而不是模型调用工具来获取它。客户端按其地址请求资源，服务器返回数据。资源有两种形式：直接资源有固定的数据地址，不需要参数，例如可用文档列表，模板化资源在地址中放置参数，例如需要文档标识符的文档地址。当你想要已知数据从轮次开始就在上下文中时，使用资源。你想要这个当直接拉取资源比使用工具调用去获取它更便宜和更可预测时。资源支持在 MCP 客户端中变化；在依赖此模式之前验证你的客户端有机制将资源注入上下文。提示词是服务器暴露的预写指令模板，以便客户端可以按名称调用经过审查的提示词，而不是要求每个用户编写自己的。用户已经可以用自己的话要求模型做大多数任务，所以提示词在需要特定措辞时很有用：一个任务，其中精心构建的指令产生明显更好的结果而不是用户会输入的任何东西，并且你想要每个客户端获得相同的质量。在服务器上打包指令意味着提示词在一个地方维护并在连接服务器的任何地方重用。

传输：Claude Code 如何与服务器通话传输是 MCP 客户端和 MCP 服务器之间的通信通道。正确的传输取决于服务器运行的地方。选择每个选项卡以了解它是什么以及何时使用。

stdio HTTP SSE

stdio 将服务器作为本地进程在与客户端相同的机器上运行。客户端将服务器作为子进程启动，并通过标准输入和输出进行通信。这是本地工具、个人脚本或你在自己机器上运行的开发服务器的正确选择。它不适用于你想在团队中共享或远程托管的服务器。

HTTP 是任何不在本地运行的服务器的推荐传输形式。它通过标准 HTTP 连接连接，支持托管在不同机器上的服务器。当你注册 HTTP 服务器时，你提供 URL，客户端通过网络连接。共享团队服务器和托管集成使用 HTTP。

SSE（服务器发送事件）是先于当前 HTTP 传输的较旧传输方式。它已被 HTTP 传输取代，不再推荐用于新服务器。如果你在现有配置或文档中遇到 SSE，将其视为遗留选项而不是当前推荐。

上下文成本每个连接的 MCP 服务器贡献工具定义，如果预先加载，会占用上下文窗口。默认情况下，Claude Code 延迟这些定义而不是预先加载它们，并使用搜索步骤仅在任务需要时发现和加载相关工具。仅调用的工具进入上下文。一个选择加入模式在它们适合大约 10% 的上下文窗口时预先加载工具定义，仅在超过该限制时延迟。无论哪种方式，仅连接你需要的服务器都会保持每个请求精简，因为每个连接的服务器都添加到模型必须考虑的定义池中。

提示词缓存：为可重用请求一次性支付你刚刚看到的 MCP 服务器的上下文成本问题既有成本又有窗口维度。每个请求从头开始重新处理其输入，包括上一个请求中相同的部分，意味着你每次都为重新处理支付。提示词缓存可以阻止你为相同的稳定内容支付两次。缓存存储在请求的稳定前缀上完成的处理工作，以便后续请求可以重用它而不是重新处理相同的令牌。第一个请求将前缀写入缓存，后续请求以缓存中相同点之前的相同内容发送，成本为一小部分。内容必须完全匹配：缓存点之前的单个更改字符会使该缓存失效并强制新写入。这就是为什么缓存的最强候选是请求中很少改变的部分，例如长系统提示词、大型工具定义集或你提出多个问题的参考文档。你通过标记缓存断点打开缓存；没有全局设置打开缓存。在 Messages API 中，你向你想缓存的最后一个块添加 cache_control 字段，类型为 ephemeral；这缓存该块及其之前的所有内容。你可以放置最多四个断点。请求按工具、系统提示词和消息的固定顺序处理，所以工具后的断点缓存工具定义，同时保持消息动态。缓存有时间限制。默认缓存生命周期是从最后一次读取起五分钟。选择加入一小时生命周期可通过在断点上设置 ttl 为 1h 获得。五分钟默认适合请求每几分钟到达的来回模型，因为每次读取重置时钟。一小时选项适合请求之间有更长间隙的工作负载，例如在步骤之间暂停的代理，其中五分钟窗口会在下一个请求之前过期。如果窗口在下一个请求之前过期，你最终为没有读取收益的写入成本再次支付。请注意，缓存仅适用于最小令牌阈值之上（对于大多数当前模型为 1,024 个令牌），所以短提示词即使设置了断点也不会被缓存。

检索增强生成：Claude 如何仅拉入请求需要的知识你刚刚看到的 MCP 服务器的上下文成本问题与大型参考材料体创建的问题相同。模型为每个请求读取其上下文窗口中的所有内容，所以你预先加载的文档越多，使用的上下文就越多，工作的空间就越少。检索增强生成，通常缩写为 RAG，是解决这个问题的模式。模型不是将每个文档加载到上下文中，系统将材料存储在上下文窗口外，找到与当前请求最相关的部分，并仅在请求时向模型提供这些部分。模型然后从该检索的切片而不是整个库生成其答案。 RAG 有两种形式：经典 RAG 预先做艰苦的工作。在任何人提出问题之前，源材料被分成块，每个块被转换成一组数字（称为嵌入），捕捉其含义数学上。这些数字存储在数据库中。当用户提出问题时，系统将问题转换成相同类型的数字，然后找到哪些块有最相似的数字。想象一个图书馆员，在图书馆开放之前，已经读过每本书并为每一章写了精确的摘要卡，所以当你带着问题到达时，他们可以立即拉出正确的卡。代理搜索完全跳过预先索引。没有预构建的数据库。相反，模型在你提出问题的那一刻弄清楚它需要什么，然后去获取它：搜索实时源、按需读取文档、在任务展开时拉入结果。想象一个研究者，当你提出问题时，他们去自己找答案而不是查阅预准备的卡。你可能已经遇到过代理搜索而不知道其名称。在 Claude Code 中，当你连接到许多外部工具（MCP 服务器）时，Claude 不会预先加载每个工具定义；那会太多一次性保持。相反，它发现并仅加载当前任务需要的工具。Claude. ai 项目对上传的文档的工作方式相同：当项目的知识库增长超过可以适应活跃窗口的内容时，它仅表面与每个问题最相关的文档部分，而不是加载所有内容。两种方法做相同的基本事情；它们都找到相关的材料切片并从中生成。区别是时间：经典 RAG 通过匹配针对预先构建的索引找到切片；代理搜索通过在需要时搜索找到它。检索的两个属性值得在你使用它之前理解：

它扩展。当你的源材料增长时，每个请求的成本保持平坦，因为模型仅接收与该问题相关的切片，而不是整个库。知识库可以增长到数千个文档，单个问题仍然拉回大约相同数量的文本。这就是让检索在规模上工作的原因：源可以继续增长而不会请求随之增长。它仅与它找到的一样好。模型推理它接收的切片。如果检索步骤错过了你需要的文档，模型永远看不到它。这意味着你如何组织材料很重要：带有模糊名称的文件（"notes_final_v3. pdf"）比带有描述性名称的文件（"Q3 退款政策，2024 年 8 月更新"）更难表面。将相关文件分组在一起也有帮助。好的检索从组织良好的源开始。

配置范围：谁加载服务器范围确定哪些用户和项目加载服务器。每个范围对应不同的配置位置。

本地范围将服务器配置存储在当前项目路径下的 ~/. claude. json 中。它仅适用于你当前工作的项目，不与队友共享。这是适合与特定项目上下文相关的服务器的正确范围，你还没有准备好提交到仓库，或仅在一个项目中有意义的工具。用户范围将服务器配置存储在你的个人 Claude 设置中，并使其在所有项目中可用。它仍然是个人的：队友看不到它，它不写入仓库。这是适合你在每个项目中使用的个人实用程序的正确范围，例如本地数据库工具或你依赖的脚本，无论你在哪个代码库上工作。项目范围将服务器配置写入仓库根目录的 . mcp. json 文件。当该文件提交到版本控制时，克隆仓库的每个人都自动获得相同的服务器。这是适合整个团队可以访问的服务器的正确范围，因为配置与代码一起旅行。要记住的一件事：项目范围的服务器从每个队友的机器运行。对于 stdio 服务器，提交的配置存储启动命令，每个克隆生成自己的本地子进程，所以每个队友需要安装运行时（例如 Node 用于 npx 启动的服务器）。企业范围通过由管理员控制的集中管理配置部署。管理员可以将服务器推送给组织中的所有用户，而无需个人配置步骤。这是适合共享内部服务、安全工具或任何必须在组织中存在且不能留给个人开发者配置的服务器的正确范围。

针对单个 MCP 工具而不是整个服务器的权限规则连接服务器暴露其完整工具列表，但你很少想要代理在不检查的情况下到达这些工具中的每一个。权限层从权限模式部分扩展到 MCP 工具，规则可以命名单个工具而不是整个服务器。 MCP 工具在权限规则中由其服务器和工具名称标识：mcpservertool。mcpgithubcreate_issue 上的允许规则让那一个工具在没有提示的情况下运行，同时同一服务器上的每个其他工具仍然提示。一个写入能力工具上的拒绝规则阻止它，同时同一服务器上的只读工具保持可用。这是你连接广泛服务器但保持代理在它可以做什么的狭窄切片内的方式。一个工具上的拒绝覆盖服务器上的允许。 API MCP 连接器是另一个有用的控制。如果你通过 API MCP 连接器到达服务器，mcp_toolset 对象让你为每个工具设置启用标志。这个启用标志让你注册服务器但仅暴露你想要模型看到的特定工具。权限规则决定暴露的工具是否可能运行；启用标志决定模型是否看到工具。第一个是治理控制，第二个是上下文成本和范围控制。这些控制经常一起使用。在发布前始终根据文档验证确切的规则语法和连接器测试版头。

GitHub MCP 服务器：传输、范围和身份验证的具体示例 GitHub MCP 服务器是由 GitHub 维护的远程服务器，暴露用于仓库管理的工具，包括审查拉取请求、打开问题、搜索代码等。通过演练连接过程，你可以看到传输、范围和身份验证如何在由其他人维护的服务器中一起工作。 GitHub 服务器使用 HTTP 传输，因为它由 GitHub 远程托管。你通过提供服务器 URL 注册它，客户端通过网络连接。对于范围，当你的整个团队需要访问相同的仓库工具时选择项目范围，当仅你需要访问服务器时选择本地范围。 GitHub MCP 服务器的身份验证使用个人访问令牌。你在 GitHub 中生成令牌，然后在你的 MCP 配置的请求头中作为 Bearer 令牌传递它。令牌必须通过环境变量提供并在配置文件中引用。它不能提交到 . mcp. json，因为直接写入提交文件的令牌进入仓库历史，不能通过在后来的提交中覆盖文件来移除。 OAuth 是不同的身份验证机制，用于服务通过基于浏览器的登录流对个人用户进行身份验证的服务器。Linear 是使用此模式的服务器示例。当你第一次连接到 Linear MCP 服务器时，客户端重定向到 Linear 的登录页面。批准访问后，令牌被发出并自动存储。没有凭据被手动复制或管理。OAuth 是任何集成的正确模式，其中服务的授权模型与用户身份相关。 GitHub MCP 使用你生成和存储的服务凭据；Linear MCP 启动登录流，为你处理凭据。两者都是远程 HTTP 服务器，两者都遵循相同的传输和范围逻辑。身份验证步骤是不同的。

MCP 设置参考下表为每个部署上下文捕捉传输和范围决策。

上下文传输范围配置位置秘密处理

个人本地工具（仅在你的机器上运行）stdioLocal~/. claude. json（每项目条目）仅环境变量。永远不要在配置文件中。共享团队服务器（所有队友连接到相同服务）HTTPProject（. mcp. json）. mcp. json 提交到仓库根目录OAuth 或环境变量。API 密钥绝不能提交到 . mcp. json。个人实验（还没准备好共享）stdio 或 HTTPLocal个人 Claude 设置仅环境变量。组织范围部署（管理员管理）HTTPEnterprise托管设置（管理员控制）秘密由管理员管理。配置锁定以防止覆盖。

成本 · 复杂性 · 风险成本：每个连接的 MCP 服务器将其工具定义添加到上下文窗口。连接的服务器越多，每个请求越大。仅加载给定任务需要的服务器。复杂性：传输和范围是独立的决策，但它们相互作用：stdio 服务器不能是项目范围用于共享，因为它仅在一台机器上运行。在选择范围之前，将传输与服务器运行的地方匹配。风险：将 API 密钥提交到版本控制中的 . mcp. json 是本部分中最常见的错误。密钥进入仓库历史，其中稍后轮换不足以移除暴露。秘密进入环境变量。配置文件仅保持服务器地址。

处理得很好你想在多个 Claude Code 会话中使用并与团队共享的可重用集成，其中能力足够稳定以作为单独过程维护。GitHub 服务器是一个很好的例子。增加成本或复杂性不仔细管理环境秘密的团队应该被密切监视。添加 MCP 服务器增加秘密可能被误处理的地方数量。风险集中在 . mcp. json 文件上，它提交到仓库。使用不同的方法一次性任务，其中工具逻辑可以直接位于代码库中，不需要在会话中重用或跨应用程序。对于单个项目集成由一个人使用，直接在 API 调用中连接工具可能比维护服务器更简单。

屏幕 13：与配置文件一起进入仓库的 API 密钥

注意MCP 服务器·4 分钟与配置文件一起进入仓库的 API 密钥

设置服务器在工作，团队需要共享设置，清理身份验证方法感觉像是你可以在交接后做的事情。那个快捷方式将临时硬编码的 API 密钥变成了共享凭据暴露，一旦配置文件被提交。

发生了什么开发者连接到数据仓库 MCP 服务器，使用服务帐户 API 密钥。为了在设置期间快速让服务器工作，密钥被直接放在 . mcp. json 配置文件中。计划是在与团队共享设置之前将其移到环境变量。开发者提交了 . mcp. json 到项目仓库，以便队友可以通过克隆仓库连接到相同的服务器，密钥随之提交。在 48 小时内，三个队友克隆了仓库，CI 管道触发了新克隆。密钥现在在四个地方：本地机器、仓库历史、三个队友机器和 CI 运行器的文件系统。意识到这一点后，开发者将密钥移到环境变量，更新了 . mcp. json，并提交了更正的文件。但密钥仍在提交历史中，服务帐户必须被轮换。轮换破坏了两个已配置相同密钥的外部服务，这花了三个小时的工作来修复。更正的 . mcp. json 使用环境变量引用而不是内联值：之前（不要使用） { "type": "http", "url": "https://warehouse. internal/mcp", "headers": { "Authorization": "Bearer sk-abc123... " ............. 内联凭据 } } 之后（正确） { "type": "http", "url": "https://warehouse. internal/mcp", "headers": { "Authorization": "Bearer ${WAREHOUSE_MCP_TOKEN}" ............ 环境变量引用 } }

要注意什么提交到配置文件的 API 密钥被提交到仓库历史。在后来的提交中覆盖文件不会从历史中移除密钥；它仅从当前版本中移除它。任何写入提交文件的凭据值必须被视为已泄露并轮换。正确的模式是将值放在环境变量中并在配置文件中引用变量。为了防止代理直接将凭据值写入提交文件，使用两个层。首先，在 CLAUDE. md 中添加约定指令，说明凭据值绝不能写入 . mcp. json。这在每个会话期间向模型发出规则信号。其次，用 PreToolUse 钩子支持该指令，检查对 . mcp. json 的写入和编辑操作，查找看起来像内联凭据值的模式，如果检测到一个则以代码退出以阻止操作。CLAUDE. md 指令传达意图；钩子确定性地强制它，无论模型决定做什么。这是从权限模式部分看到的相同钩子与指令区别：CLAUDE. md 中的指令当文件增长或上下文移动时可以不一致地遵循，钩子在每个相关工具调用处无例外地触发。

屏幕 14：检查点 5：将传输和范围匹配到每个部署场景

检查点MCP 服务器·4 分钟检查点 5：将传输和范围匹配到每个部署场景现在试试。对于下面的每个部署场景，选择正确的传输和范围。提供了标记的配置片段。 A 你仅在开发机器上使用的本地 SQLite 查询工具。HTTP + Project（. mcp. json）HTTP + Enterprise（托管设置）stdio + Localstdio 或 HTTP + Local B 托管在你公司基础设施上的代码搜索服务，整个工程团队应该访问。HTTP + Project（. mcp. json）HTTP + Enterprise（托管设置）stdio + Localstdio 或 HTTP + Local C 你本周针对一个特定仓库测试的实验性网络抓取服务器，还没准备好共享。HTTP + Project（. mcp. json）HTTP + Enterprise（托管设置）stdio + Localstdio 或 HTTP + Local D 你的组织的 IT 团队需要部署到每个开发者的 Claude Code 安装的安全扫描服务器。HTTP + Project（. mcp. json）HTTP + Enterprise（托管设置）stdio + Localstdio 或 HTTP + Local

提交暂时跳过

屏幕 15：将 Claude 连接到企业系统并安全地对其进行身份验证

教学企业集成·18 分钟将 Claude 连接到企业系统并安全地对其进行身份验证之前本模块涵盖了如何构建 MCP 服务器并配置其传输和范围。对于仅由你的团队在内部项目上使用的服务器，GitHub 个人访问令牌示例涵盖了身份验证模式。本部分涵盖当集成必须在受管制环境中工作时改变什么：身份、秘密处理和数据驻留问题，原型通常忽略的问题，变成生产部署必须回答的要求。

为什么企业集成与工作原型不同回答一个问题的原型连接 Claude 到内部服务：连接是否有效？生产企业集成必须回答几个额外的问题：模型作为谁行动，那个身份是否可审计？它可以访问什么数据，那个数据在哪里离开组织？管理员能否锁定配置，使没有个人开发者可以改变身份验证设置？访问可以以满足合规审计的方式记录吗？这些问题对企业软件不是新的；它们与适用于任何外部系统接触受管制数据的相同身份、访问和合规要求相同。将它们作为集成设计的一部分对待是将演示与部署就绪的东西分开的原因。

按服务类型的身份验证模式正确的身份验证机制取决于服务运行的地方以及它支持什么身份模型。选择每个选项卡以了解模式和何时使用。

具有用户身份的远程服务具有服务身份的远程服务具有文件系统访问的本地服务

使用 OAuth。MCP 服务器返回 401 未授权以发出需要身份验证的信号。客户端启动基于浏览器的登录流。用户批准访问后，令牌被发出并存储。没有人手动复制秘密；OAuth 流是云服务、SaaS 工具和任何集成的预期模式，其中用户的身份是授权模型的一部分。本模块前面的 Linear MCP 服务器使用此模式；GitHub 服务器相比之下，使用作为头传递的个人访问令牌进行身份验证。

使用通过环境变量传递的 API 密钥。密钥标识服务帐户。密钥绝不能提交到配置文件；它位于执行点的环境中。对于使用 Agent SDK 的 CI 管道，密钥由管道运行器作为秘密注入，而不是烘焙到代码中。

stdio 传输，没有网络身份验证。安全边界是文件系统权限模型。设置文件中的拒绝规则是治理层。

管理秘密本身是安全身份验证的另一半。凭据永远不与引用它的配置一起旅行：配置文件仅保持变量引用，值位于环境变量或在执行点注入的托管秘密存储中。在秘密管理器中存储服务帐户密钥而不是文件中，并按计划轮换它们，并在任何怀疑暴露后立即轮换。如果密钥泄露，你必须轮换它，但记住，你不能轮换烘焙到提交代码中的值。将每个凭据限制到其任务需要的最窄访问，所以泄露的密钥仅到达该集成所需的内容。

身份验证后管理秘密：存储、轮换和与配置分离选择正确的身份验证模式建立连接，但保持它是一个单独的问题。本模块前面提到的 MCP 密钥泄露不是身份验证方法的坏选择，它是一个位于错误地方的凭据，一旦它传播就无法清理。三个实践保持这种情况不发生，每一个解决凭据被暴露的特定方式。第一个实践是分离：凭据永远不与引用它的配置一起旅行。配置文件保持变量引用，值位于文件不在的地方。这是泄露密钥失败破坏的规则。它重要的原因是机械的：配置文件被提交、共享和克隆。内联写入的值随着这些副本中的每一个旅行，提交的值以覆盖不移除的方式进入仓库历史。如果你将值保持在文件之外，那么文件保持安全共享。第二个实践是值一旦在文件之外就去哪里。对于仅在一台机器上或一个管道运行中存在的值，在执行点注入的环境变量就足够了：CI 运行器将其设置为秘密，配置按名称读取它，没有任何东西写入磁盘。对于几个服务或人需要的值，秘密存储更好。秘密存储是一个托管服务，保持凭据、在运行时返回给授权调用者，并记录谁读取什么。它集中值，所以单个轮换更新每个消费者一次，并移除当每个服务在自己的文件中保持自己的凭据时积累的副本。当秘密是本地和短期的时使用环境变量，当秘密被共享或必须被审计时使用秘密存储。第三个实践是轮换：用新的替换凭据按计划并在任何怀疑暴露后立即。轮换是对泄露密钥的唯一适当响应，因为已暴露的密钥不能再被秘密。你必须发出新的。这就是为什么内联凭据模式成本这么高：烘焙到提交代码中的值不能干净地轮换，因为旧值保持在历史中，每个硬编码到它的消费者在改变时中断。从秘密存储或环境变量读取的凭据轮换而不触及使用它的代码，因为代码按名称引用值，名称在其后的值改变时不改变。两个习惯可以使轮换更便宜：将每个凭据限制到其任务需要的最窄访问，所以泄露的密钥仅到达该集成所需的内容。保持每个凭据使用哪些服务的记录，所以轮换不会浮出其消费者。本模块前面识别的泄露密钥失败：凭据写入提交文件。为了防止这种情况发生，应用这三个实践：分离将值保持在文件之外，秘密存储或环境变量给值一个文件不共享的家，轮换可以帮助恢复仅当前两个被保持时。

受管制行业在工作身份验证之上添加什么金融服务或医疗保健客户提出的问题比"身份验证是否有效？"更多。他们问数据在哪里处理，访问如何记录，以及管理员是否可以锁定配置，使开发者在审计窗口期间无法改变身份验证设置。本模块前面部分的企业托管配置回答了最后一个问题：管理员部署的服务器配置，不能被个人用户覆盖，意味着身份验证设置在组织中是一致的，不依赖每个开发者的设置文件是正确的。审计钩子回答日志问题：记录每个工具调用及其参数到审计存储的 PostToolUse 钩子提供合规审查需要的记录。钩子无论模型决定什么都确定性地为每个调用触发，日志不是模型可以跳过的东西。数据驻留回答处理问题：配置有特定区域中 HTTP 端点的服务器，结合将处理固定到该区域的平台部署，给合规审查者一个可检查的答案，数据去哪里。这就是为什么本模块前面的基础设施要求和平台选择在审计时重要，而不仅仅在构建时。

代码现代化：将完整模块应用于遗留更改代码现代化是一个有用的测试用例，用于本模块涵盖的所有内容，因为它集中了每个工具被设计管理的风险。大规模更改不熟悉的遗留代码库携带高爆炸半径、不可预测的依赖和有限的可逆性。本模块的工具在应用前直接解决每个风险。探索、规划和编码循环是此类工作的核心工作流。计划模式将代理保持在只读探索阶段，同时你建立对其更改的信心。你可以审查提议的编辑，识别任何触及你没有预期的路径的东西，并在修改单个文件之前推回。钩子强制护栏，防止在最敏感阶段编辑特定路径。CLAUDE. md 携带新目标模式的约定，所以代理在完整更改范围中一致地应用它们，而不是漂回它在周围代码中读取的遗留模式。高风险工作的负责范围方法在会话开始前解决三个问题。

如果出错，爆炸半径是什么：哪些系统依赖被改变的代码，如果编辑错误，下游会破坏什么？更改如何被审计：是否有 PostToolUse 钩子记录每个工具调用，那个日志是否满足需要审查代理触及什么的人？谁在每个阶段开始下一个阶段之前批准？计划模式强制探索和执行之间的边界，但批准决策本身是你在工作开始前定义和记录的。

这些问题不特定于现代化工作。它们适用于任何高风险代理任务。代码现代化清晰地表面它们，因为范围很大，代码库不熟悉，错误的成本很高。

身份验证和集成检查清单下表命名每个服务类型的关键决策。

服务类型身份验证方法秘密位置记录什么谁可以锁定配置

具有用户身份的远程（SaaS、云）OAuthOAuth 提供者发出的令牌并由客户端存储。PostToolUse 钩子到审计日志。管理员通过企业托管设置。具有服务身份的远程（内部 API）环境变量中的 API 密钥仅环境。永远不要在提交的配置中。PostToolUse 钩子到审计日志。管理员通过企业托管设置。本地（文件系统、本地数据库）文件系统权限不需要凭据。拒绝规则强制路径访问。PostToolUse 钩子到审计日志。企业托管设置中的拒绝规则。

成本 · 复杂性 · 风险成本：OAuth 流为每个用户每个服务添加一次性设置步骤。API 密钥管理需要秘密轮换过程，通过 PostToolUse 钩子的审计日志为每个工具调用添加小开销。复杂性：受管制环境添加原型中不出现的要求。在范围期间识别它们是保持集成按计划进行的纪律。风险：风险集中在原型向生产的移动。使用硬编码凭据、没有审计日志且不能集中锁定的系统不会通过受管制客户的安全审查。修复不难，但它们需要在审查前注意。

处理得很好任何接触受管制客户关心的数据的集成，其中相同的工具已支持企业托管设置和审计钩子。预先范围安全要求添加很少开销并防止集成在最终审查处停滞。增加成本或复杂性不熟悉 OAuth 流或企业秘密管理的团队。这些模式在大多数受管制组织中需要与安全或 IT 团队协调，时间表需要考虑到这一点。使用不同的方法永远不会看到生产数据的原型或概念证明。完整的企业集成检查清单对仅演示集成不值得，但为秘密应用环境变量习惯成本什么，是好的实践。

屏幕 16：在暂存中工作的 OAuth 连接在生产中失败

注意企业集成·3 分钟在暂存中工作的 OAuth 连接在生产中失败

设置 OAuth 连接端到端在暂存中工作，所以将其移到生产感觉像是常规切换。团队错过的是 OAuth 重定向 URI 按主机注册，通常按环境管理，所以暂存中的成功不意味着生产主机被授权完成登录流。

浮出缺失步骤的对话以下交换发生在部署后审查中，在 MCP 集成失败后。集成已通过所有暂存测试。安全审查者："每个生产登录尝试通过 MCP 连接都失败。错误是重定向 URI 不匹配。OAuth 应用在哪里注册？"

开发者："我在开发期间为暂存. mycompany. com 注册了它。我们上周移到生产。连接在整个暂存中工作。"

安全审查者："那就是问题。OAuth 提供者仅接受你显式注册的重定向 URI，production. mycompany. com 不在允许列表上。每个登录尝试命中检查，失败 URI 匹配，并循环回登录屏幕。"

开发者："所以我只需要将生产 URI 添加到应用注册？"

安全审查者："是的，在你这样做之前，检查你的暂存应用注册是否应该是与生产分开的应用。大多数企业客户要求每个环境的单独 OAuth 应用注册作为其安全政策的一部分，所以在环境中使用相同应用注册是我会标记的第二个问题。" 开发者已经端到端测试了 OAuth 流并确认它有效在暂存中，意味着生产失败不是代码缺陷。相反，它是适用于每个主机和每个环境的配置步骤，开发者不知道要为生产做。

要注意什么 OAuth 重定向 URI 按主机注册，所以工作的暂存 OAuth 连接不意味着生产连接被配置。在将任何 OAuth 认证的 MCP 集成移到新环境之前，将新主机的重定向 URI 添加到 OAuth 应用注册。对于受管制的企业客户，验证暂存和生产是否需要单独的 OAuth 应用注册。在部署检查清单中包括注册步骤，以便它不会在第一个生产登录尝试处被发现。

屏幕 17：检查点 6：从追踪诊断身份验证失败

检查点企业集成·3 分钟检查点 6：从追踪诊断身份验证失败现在试试：读取下面的连接追踪。命名身份验证失败机制，然后从三个选项中选择正确的针对性修复。连接追踪 [MCP 客户端] 连接到 https://data-api. internal/mcp ... [MCP 客户端] GET /auth/token，401 未授权 [MCP 客户端] 读取凭据来自：/home/jenkins/. config/mcp-credentials. json [MCP 客户端] 凭据值：WAREHOUSE_TOKEN= sk-**[已编辑] [MCP 客户端] 使用凭据重试，401 未授权 [MCP 客户端] 3 次尝试后连接失败 A修复 A：轮换 API 密钥并用新值更新 /home/jenkins/. config/mcp-credentials. json。B修复 B：轮换被拒绝的密钥，然后将凭据移出文件并在 CI 管道运行器配置中作为环境变量注入。更新 MCP 配置以引用变量。C修复 C：为此服务从 API 密钥身份验证切换到 OAuth。

提交暂时跳过

屏幕 18：累积集成任务：检查点

累积累积集成任务·6 分钟累积集成任务：检查点下面的集成有三个错误，分布在本模块涵盖的层中：一个在 Claude Code 配置层，一个在插件或打包层，一个在 MCP 或身份验证层。对于每个文件：识别错误并写一句话描述它在运行时做什么或未能做什么。

文件 1：. claude/settings. json { "permissions": { "defaultMode": "bypassPermissions", "deny": ["Read(. env. production)"] } }

文件 2：. claude/skills/migration-validate/SKILL. md --- name: migration-validate description: Validates migration scripts before they run against production. ---

Steps

Run: /Users/priya/scripts/validate-migration. sh
Report validation results.

文件 3：. mcp. json { "mcpServers": { "data-warehouse": { "type": "http", "url": "https://warehouse. internal/mcp", "headers": { "Authorization": "Bearer sk-prod-warehouse-abc123" } } } }

显示模型答案暂时跳过

模型答案文件 1（settings. json）：defaultMode 是 bypassPermissions；移除生产工作站上的每个确认提示，包括破坏性操作。拒绝规则用于 . env. production 是正确的；仅模式是错误的。文件 2（SKILL. md）：第 1 步使用绝对路径 /Users/priya/scripts/validate-migration. sh；此路径仅存在于作者的机器上，在任何队友克隆项目后都不会解析。文件 3（. mcp. json）：API 密钥 sk-prod-warehouse-abc123 提交内联在授权头中；它进入仓库历史，其中在后来的提交中覆盖文件不足以移除暴露，必须被视为已泄露。

你捕捉了多少？

全部三个正确错过了 API 密钥（错误 3）三个中的两个正确三个中的一个正确

屏幕 19：累积集成任务：组装

累积累积集成任务·6 分钟累积集成任务：组装现在写出所有三个文件的更正版本。为 settings. json、SKILL. md 和 . mcp. json 生成完整的更正内容。

显示模型答案暂时跳过

模型答案文件 1：settings. json（更正） { "permissions": { "defaultMode": "acceptEdits", "deny": ["Read(. env. production)"] } } 文件 2：SKILL. md（更正） --- name: migration-validate description: Validates migration scripts before they run against production. ---

Steps

Run: $CLAUDE_PROJECT_DIR/scripts/validate-migration. sh
Report validation results.

文件 3：. mcp. json（更正） { "mcpServers": { "data-warehouse": { "type": "http", "url": "https://warehouse. internal/mcp", "headers": { "Authorization": "Bearer ${WAREHOUSE_MCP_TOKEN}" } } } } settings. json 在权限中将 defaultMode 设置为 acceptEdits；自动批准文件编辑和常见文件系统命令，但控制破坏性 shell 命令，生产迁移工作站的正确权衡。技能使用 $CLAUDE_PROJECT_DIR，所以路径从克隆后任何机器上的项目根目录解析。MCP 配置将凭据引用为环境变量，所以它永远不会提交到仓库历史。

你的组装如何比较？

正确的组装缺少权限修复缺少路径修复缺少秘密修复

屏幕 20：七个关键收获

总结关键收获·6 分钟七个关键收获每部分一个收获，将模块联系在一起。

1 权限模式是风险决策，而不是速度决策。 Claude Code 给你从提示一切到提示无的模式。权限模式应该与工作和环境的风险概况相匹配，而不是对更少提示的偏好。生产工作站上针对实时代码库的绕过模式移除代理和你的文件之间的每个检查点。必须不被触及的路径上的拒绝规则，在项目或企业级设置，涵盖模式单独不涵盖的间隙。

2 AI 代码审查给你一组发现来分类，而不是应用的判决。信任审查者可以从它面前的差异中证明的发现，如缺失的空检查或未关闭的资源，并确认它引用的行。将任何关于运行时行为或另一个系统的声明视为假设来测试，因为审查者在没有会证明它的证据的情况下做出了该声明。将人工门放在发现变成难以逆转的操作的点，并通过给它它否则必须猜测的约定来提高审查者的准确性。

3 技能是便携式的，但"在任何地方运行"是你设计的东西。同一 SKILL. md 可以在 Claude Code、Messages API 和 Agent SDK 中运行，但每一个加载和沙箱它的方式不同：Claude Code 中的文件系统发现、API 上的测试版头和代码执行容器、SDK 上的 settingSources。限制在清晰描述和无本地环境假设的技能干净地移植；假设它被编写的终端的技能不会。在每个运行时中，子代理从干净开始：它们不会自动预加载技能。

4 持久上下文需要为每个关注的正确机制。 CLAUDE. md 是会话持久的项目记忆，但随大小稀释。规则文件将指导限制到它适用的地方。钩子确定性地强制护栏，而不是概率性地。子代理将探索工作保持在主上下文之外。这四个机制各解决不同的问题，所以将所有它们强制到 CLAUDE. md 产生单个文件，更难维护和更容易忽视。

5 可共享的设置需要便携式组件。引用作者主目录绝对路径的插件将在一台机器上安装并在所有其他机器上失败。将被共享的技能、钩子和插件组件必须引用相对于项目根目录的路径，任何环境变量要求必须被记录或在安装时验证。在分发前从干净机器测试安装。

6 传输和范围是独立的决策，有依赖的后果。 stdio 用于在你的机器上运行的服务器。HTTP 用于远程托管或由多个开发者访问的任何东西。本地范围保持服务器个人；项目范围通过 . mcp. json 与仓库共享它。组合必须与部署意图相匹配：共享团队服务器需要 HTTP 传输和项目或企业范围。. mcp. json 中的 stdio 服务器是看起来可共享但不是的配置。

7 企业集成需要在部署前识别安全要求。受管制客户询问身份、数据驻留、访问日志和配置控制。答案来自用户身份服务的 OAuth、服务凭据的环境变量、审计日志的 PostToolUse 钩子和配置锁的企业托管设置。这些都不难实现，但所有都难以在生产部署未通过安全审查后改装。

接下来是什么模块 4 涵盖生产工程、评估和安全：如何衡量你的 Claude Code 集成是否在规模上正确工作、如何构建评估工具，以及如何设计生产级安全护栏。本模块的权限模式、钩子和身份验证模式是这些评估测试的基础。

来源

Claude 101（Skilljar） Claude Code 101 实际行动（Skilljar）使用 Claude API 构建（Skilljar） code. claude. com platform. claude. com docs. claude. com

你现在可以安全地运行 Claude Code、将其作为团队资产共享，并将其连接到真实系统。从权限模式到企业身份验证，你现在掌握了在集成离开你的机器后保持其工作的配置决策。

屏幕 21：本模块的关键术语

词汇表关键术语·3 分钟本模块的关键术语按字母顺序。点击术语以展开其定义。

Claude Agent SDK一个可编程接口，暴露 Claude Code 在终端中运行的相同代理循环。它允许开发者从代码调用循环、设置权限模式和可用工具，并在没有交互式会话的情况下运行任务。相同的权限模型和拒绝规则适用于终端也适用于 SDK。 CLAUDE. md一个 Markdown 文件放在 Claude Code 项目的根目录。其内容在每个会话开始时前置到上下文窗口。它保持通用项目约束、约定和应该无条件地在所有会话中应用的命令。增长超过大约 200-300 行的文件冒着稀释关键规则的风险。钩子绑定到 Claude Code 执行中的生命周期事件的命令（PreToolUse、PostToolUse、UserPromptSubmit、Stop）。与 CLAUDE. md 中的指令不同，钩子无论模型决定什么都在配置的事件处确定性地运行。PreToolUse 钩子可以以代码 2 退出以在运行前阻止工具调用。 MCP（模型上下文协议）一个开放通信层，允许 Claude Code 等 MCP 客户端连接到暴露工具、资源和提示词的 MCP 服务器。协议定义客户端如何发现和调用服务器的工具。使用 MCP 将工具定义和维护移出单个应用程序代码并进入任何 MCP 客户端可以附加到的可重用服务器。 MCP 传输MCP 客户端和 MCP 服务器之间的通信通道。stdio 在与客户端相同的机器上将服务器作为本地子进程运行。HTTP 通过网络连接到远程托管的服务器。传输选择决定服务器可以在哪里运行以及谁可以连接到它。权限模式Claude Code 中的设置，控制代理在执行工具调用之前停下来请求确认的频率。模式范围从 default（在几乎每个操作之前提示）到绕过模式（根本没有提示）。拒绝规则覆盖任何模式；企业设置级别的拒绝规则不能被任何个人配置绕过。插件Claude Code 组件（技能、钩子、子代理和 MCP 服务器配置）的版本化捆绑，通过市场分发。安装插件给接收者与作者相同的设置一步。插件用版本化、可审计的安装替换手动设置步骤的页面。规则指令文件在 Claude Code 中将指导限制到特定路径或条件的文件。与无条件地为每个会话加载的 CLAUDE. md 不同，规则文件仅在 Claude Code 在它监督的目录中工作时激活。用于将路径特定指导保持在主项目记忆文件之外。子代理Claude Code 启动以处理委托任务的单独执行上下文。子代理不继承主对话的上下文或积累的文件；它从干净开始，执行任务，仅返回摘要。为探索或调查工作使用子代理保持主会话上下文不被不会重用的内容填充。

屏幕 22：恭喜！你已成功完成本模块。

模块完成开发者路径·2 分钟恭喜！你已成功完成本模块。你现在可以在正确的权限模式下运行 Claude Code，为其提供持久的项目上下文，将工作流打包为可共享的插件，并通过 MCP 将 Claude 连接到真实系统，而不泄露凭据或未通过安全审查。本模块中的配置决策是在集成离开你的机器后保持其工作的原因。

4 个 8 个检查点通过了

MSO 基础令牌、上下文窗口、采样、模型层级、提示词模式和 API 传输机制。

生产级提示词、代理与工具使用生产就绪的提示词、工具使用循环、流式传输、上下文和记忆管理、检查点代理循环。

Claude Code、MCP 与集成权限模式、持久上下文、插件打包、MCP 服务器和企业身份验证。

你在这里

生产工程、评估和安全评估、追踪、失败处理、成本和编排预算、在生产中保持的安全边界。

接下来

加速器和 IP 贡献打包加速器、准备可验证的贡献、选择部署平台、标记信任边界。

审查模块重新开始开始模块 4 → 返回课程主页

模块 3 完成。