企业官网建设流程全解析

1. 为什么 SubAgent 的上下文隔离值得单独聊

Claude Code 里的 SubAgent（子代理）不是"再发一次请求"那么简单。它是一套围绕上下文隔离、工具裁剪、专业化系统提示、确定性结果回传构建的运行时子系统。你在主对话里让 Claude 读十几个文件、跑几轮搜索，上下文很快就被文件摘录和工具日志塞满；而 SubAgent 把这些中间产物全部封闭在自己的窗口里，只把精炼结论递回主循环。

这套机制能做什么？简单说，它让"一个代理背所有任务"变成"多个代理各背一个任务"。适合谁？适合已经在用 Claude Code 做多文件重构、代码审计、批量迁移，或者正在搭多 Agent 协作流程的开发者。如果你只是改个 typo，用不上它；但当你发现主对话越来越"健忘"、指令遵从性下降、Token 账单飙升时，SubAgent 就是结构性解法。

我试过在一个五万行的 Node 仓库里做深度审计，单代理跑到一半上下文就逼近上限，触发压缩后关键结论丢失。换成 SubAgent 编排后，主上下文只收结构化发现列表，稳定得多。这篇就把派生逻辑、执行链路、结果回传路径拆开讲，并给出可复制的 settings.json 骨架和验证动作，接入统一走 TaoToken 的 Key/API 通道。

2. TaoToken 前置：统一 Key 与 API 通道准备

在动 SubAgent 之前，先把模型通道打通。TaoToken 提供统一的 Key 和 API 入口，Claude Code 通过环境变量指向它即可，不需要在每个子代理里单独配一套凭证。

你需要准备两样东西：一个 API Key，以及确认接入地址。控制台里创建 Key 的入口在 https://taotoken.net/console ，Key 管理页在 https://taotoken.net/api-keys 。接入文档在 https://taotoken.net/doc ，遇到配置问题先翻这里。

关键点在于：SubAgent 派生时会继承主循环的模型通道配置，所以只要主进程的环境变量对了，子代理自动复用，不用逐个配。这也是统一 Key 的价值——多 Agent 协作时凭证只有一份，轮换和审计都简单。

注意：API 地址用 https://taotoken.net/api ，不要带查询参数。环境变量名按 Claude Code 的约定来，别自创。

3. 可复制配置：settings.json 骨架与环境变量

Claude Code 的配置分两层：一层是进程级环境变量（管模型通道），一层是 settings.json（管权限、工具、子代理行为）。先看环境变量，Linux/macOS 下写进 shell 配置：

export ANTHROPIC_BASE_URL="https://taotoken.net/api" export ANTHROPIC_AUTH_TOKEN="你的_TaoToken_API_Key" export ANTHROPIC_MODEL="claude-sonnet-4-5"

Windows PowerShell 用：

$env:ANTHROPIC_BASE_URL="https://taotoken.net/api" $env:ANTHROPIC_AUTH_TOKEN="你的_TaoToken_API_Key" $env:ANTHROPIC_MODEL="claude-sonnet-4-5"

然后是项目级 settings.json，放在项目根的.claude/settings.json。这份骨架覆盖权限白名单、子代理工具裁剪、以及一个自定义子代理的注册：

{ "permissions": { "allow": [ "Read", "Glob", "Grep" ], "deny": [ "Bash(rm:*)", "Bash(git push:*)" ] }, "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api" }, "agents": { "code-reviewer": { "description": "只读代码审查代理，输出结构化发现列表", "tools": ["Read", "Glob", "Grep"], "prompt": "你是代码审查专家。只读，不修改任何文件。审查代码质量、最佳实践、潜在缺陷。最终输出必须是结构化数据，不要对用户说话。" }, "explore": { "description": "只读搜索代理，定位代码位置", "tools": ["Glob", "Grep", "Read"], "prompt": "你是只读搜索代理。读取代码摘录而非整文件，定位代码位置但不做审查。最终输出为文件路径与行号列表。" } } }

几个参数说明。permissions.allow是宿主权限天花板，子代理的工具集永远是它的子集，不能放宽。agents下每个键是一个子代理类型，tools决定它的能力边界——code-reviewer 没有写权限，行为会被工具形状自然约束在"读与审"的轨道上，比在提示词里写"请不要改文件"可靠得多。prompt里那句"最终输出必须是结构化数据"就是结果回传契约的落点。

提示：项目级子代理优先于用户级。同名时项目级覆盖用户级，遵循"就近优先"。

4. 验证请求：派生动作与成功结果

配置写完，先验证通道通不通，再验证子代理能不能派生。

第一步，确认模型通道。用 curl 打一次最小请求：

curl https://taotoken.net/api/v1/messages \ -H "x-api-key: 你的_TaoToken_API_Key" \ -H "anthropic-version: 2023-06-01" \ -H "content-type: application/json" \ -d '{ "model": "claude-sonnet-4-5", "max_tokens": 64, "messages": [{"role": "user", "content": "回复 OK 两个字母"}] }'

返回里能看到content数组带文本，说明 Key 和地址都对。若返回 401，检查 Key；返回 404，检查地址是否误加了路径。

第二步，在 Claude Code 里触发一次派生。启动后输入：

用 explore 子代理找一下项目里所有处理登录逻辑的文件，只返回文件路径和行号

成功时你会看到主循环派生了一个子代理，UI 里出现子代理的 spinner 和 label，几秒后返回一个文件路径列表。关键观察点：主对话里没有出现子代理读过的文件内容，只有最终列表。这就是上下文隔离生效的直接证据。

第三步，验证结果回传契约。再触发一次：

用 code-reviewer 子代理审查 src/auth 目录，返回 JSON 格式的发现列表，字段包含 file、line、severity、desc

成功返回应当是一个可直接解析的 JSON 对象，而不是"我审查了一下，发现了一些问题……"这种散文。如果拿到的是散文，说明子代理的 prompt 里回传契约没写清，回去补上"最终输出必须是结构化数据"。

5. 本篇常见错排查

派生没反应，主循环直接自己干了。多半是子代理类型名拼错，或者 settings.json 的agents键没被加载。检查文件路径是不是.claude/settings.json，以及类型名大小写是否一致。

子代理报工具不可用。你给它的tools里写了某个工具，但宿主的permissions.deny把它禁了。记住工具集是"宿主权限 ∩ 类型声明"，deny 优先。把冲突项从 deny 里挪走，或换个子代理类型。

回传内容撑爆主上下文。常见于后台子代理。local_agent 后台任务的.output文件是完整对话记录的符号链接，用 Read 去读它会灌入数万行。正确做法是直接消费 Agent 工具返回的结果对象，或用 TaskOutput 按需取，别去 Read 那个文件。

子代理说"我不知道刚才那个问题"。这是 prompt 不自包含。子代理不继承主对话历史，它的唯一输入就是你给的 prompt。把目标、约束、已知信息、期望格式全部打包进 prompt，检验标准是：单独拷给一个无背景的代理，它能否无歧义执行。

并发改文件互相覆盖。多个子代理同时写同一仓库会竞态。需要并发写时给子代理开isolation: "worktree"，让每个子代理在独立 git worktree 里工作。只读任务不用开，开了是浪费。

去重循环不收敛。如果你在编排里去重，基准要用"全部已见过"的集合，而不是"已确认"的集合。用已确认做基准，被否决的发现下一轮会被重新报出，循环永远不 dry。

6. 接入与后续：按场景分流

排障和接入配置的问题，优先看 API Keys 页和接入文档：Key 管理在 https://taotoken.net/api-keys ，配置细节在 https://taotoken.net/doc 。这两个页面覆盖了环境变量、地址、鉴权头这些最容易踩坑的点。

想先验证模型对话是否正常，用模型对话入口 https://taotoken.net/models 打一次最小请求，确认通道通了再上 SubAgent 编排。

如果你要长期跑编码任务、搭 Agent 协作流程，Coding Plan 更合适，入口在 https://taotoken.net/coding-plan ，它针对长周期、多轮次的编码场景做了配额和稳定性优化。

最后给一个实操建议：SubAgent 是手段不是目的。判断标准很简单——派生的隔离与专业化收益，是否大于派生本身的协调成本。改一行 typo 派子代理是过度工程化；读一堆文件只为拿一个结论，那才是它该上场的地方。把控制流留在确定性代码里，叶子交给模型，关键路径加对抗式验证，这三条守住，多 Agent 协作就不会在成本或正确性上翻车。