子代理是路由与作用域机制，而非团队隐喻
描述字段是路由规则，工具列表是保证
一个 Claude Code 子代理之所以有效，是因为两个机制被写进了一个 markdown 文件：一个描述，将工作路由到正确的专家；一个工具限制，保证专家不会越出自己的轨道。Professor Glitch 2026 年 7 月的指南《Claude Code Subagents: Turn One AI Into a Whole Team》把描述称为「一条路由规则」，把工具限制称为「那个功能」——这正是我们在 Everythink 所沿用的框架，在这里 the space is the router。
文章的核心交易是精确的：子代理把冗长的工作转化为简短的回答，于是大约 40,000 tokens 的原始研究在专家的上下文中消亡，主对话只收到三个段落。那不是团队隐喻。那是一个路由决策加上一个作用域保证，二者皆可度量。[UNIQUE INSIGHT] the-space-is-the-router reframing：聊天机器人回答；AI OS 路由。子代理是这种路由的最小单元——一条有名字的车道，配一套被看守的工具集。
为什么一个过载的通才会退化
上下文腐烂是一个度量问题，不是能力声明
源文章明确指出失效模式：模型的工作记忆随其填满而退化。把 150,000 tokens 的文件转储和旧指令塞进一个对话，模型就开始遗漏东西——不是因为它笨，而是因为信号被埋住了。这正是我们把 Sisters 与 Oracle 分开的同一个理由。每个 Sister 是一个有类型的性格（analyst、contrarian、historian、institutionalist、disruptor），在自己的上下文中起草；Oracle 把草稿合并成一个归一化的 ensemble。如果一个模型同时持有每个 Sister 的原始草稿加上合并数学，信号就会崩溃。
上下文腐烂是真实的、可度量的，而修复它的机制是隔离——不是更大的窗口。Everythink 的 HAI Engine ✅ 自 2016 年起在生产中运行这一隔离模式。我们没有靠买更多 tokens 来解决上下文腐烂。我们靠把每次想象过程路由到它自己的干净房间并返回压缩结果来解决它。
干净交接是度量隔离机制
[PERSONAL EXPERIENCE] the engine has run in production since 2016——而让我们惊讶的部分，正如文章所报道的，是哪个部分最重要。不是自动化。是干净交接。当一个 Sister 完成一份草稿时，Oracle 收到的是草稿，不是 Sister 咀嚼过的数百页源材料。
那种压缩是一条度量边界。你可以数穿过它的 tokens。文章的数字——40,000 tokens 原始材料缩减为三个段落——与一次 Sister 到 Oracle 的交接形状相同。「主上下文保持干净」这一属性，恰在其交接机制被实现并执行时得到保证。Theorem 3：一个属性恰在其机制被实现并测量时得到保证。交接是机制；token 计数是度量。
描述字段是路由规则
「Use proactively」是路由谓词
文章明确指出描述不是文档。它是一条路由规则：Claude 读取每个子代理的描述并将进入的任务与之匹配。像「use proactively」这样的短语让 Claude 主动去调用该代理。模糊的描述意味着代理永远不会触发；精准的描述意味着它恰好在应该触发时触发。
这就是 the space is the router，在单个 prompt 的粒度上。在 Everythink，同一个原则构建了整个平台：一个 network 包含 communities，一个 community 包含 rooms，一个请求在被路由到拥有该能力的 room 之后才有什么东西响应。network-to-community-to-room 拓扑是一条以 URL 空间实现的路由规则；子代理的描述字段是一条以自然语言实现的路由规则。
当查询类型错误时，路由胜过检索
文章间接揭示的一个常见错误：人们去拿子代理，而他们实际需要的是一个 skill——一个按需加载进当前对话的可重复流程。文档划了线：在你的对话中运行的可复用工作流是 skill；应在自己的房间里发生并以摘要返回的冗长或受限工作是子代理。多数以为自己需要子代理的人需要的是 skill。
机制读法：查询类型必须匹配路由目标。把一个 skill 形状的请求路由给子代理，付了隔离成本——全新上下文、重新解释情况——却没有收益。把一个子代理形状的请求路由给 skill，则用 40,000 tokens 原始材料污染主上下文。
工具限制是 Theorem 3 的保证
「Nova can't send email」是一个属性，工具列表是它的机制
文章最承重的那句话很容易被略过：「None of them can touch each other's work. Nova can't send email. Quill can't touch a server. That's not a bug I tolerate, it's the design.」那是 Theorem 3 的白话表述。「Nova cannot send email」这一属性，恰在其机制被实现并测量时得到保证——而机制是 frontmatter 里的工具列表。如果邮件工具不在 Nova 的 tools: 字段里，属性成立。如果在，属性不成立。没有中间状态。一条写着「Nova should not send email」的策略是一个愿望；一份省略了邮件 API 的工具列表是一个保证。区别在于机制能否在边界上被度量。
作用域是边界，不是情绪
Everythink 把同样的边界纪律应用于它的模块表面。Social ✅、Campaigns ✅ 和 Whitelabel Network ✅ 是 Production 模块，带有作用域权限——社区版主无法 mint 一个 Eye Key，活动编辑者无法改写 network 的品牌，因为权限作用域在动作到达数据库之前就路由了它。Matchmaking ⚠️、Marketplace ⚠️ 和 Calendar ⚠️ 是 Partial——作用域机制存在，但仍在生产流量中被测量。Wallet & Token 🔵、Super App 🔵 和 Community Credit 🔵 是 Roadmap——作用域已规约，机制尚未实现，在我们能够声称保证之前不会声称。
Honest Architect 规则：永不提升一个状态。一个 Roadmap 模块不会因断言而变成 Production。「Community Credit balances are non-inflatable」这一属性，将恰在其会计机制被实现并测量时得到保证——在承诺任何结果之前须经过 Howey 审查。在那之前，它带着 🔵 标记。
workers-plus-reviewer 模式是一个 ensemble，不是组织架构图
评审者没有对捷径的记忆
文章描述了 Anthropic 的 Building Effective Agents 中的 orchestrator-workers 模式：一个主代理分解工作，workers 并行执行，一个独立代理评审。使它超越组织架构图的部分是：评审者没有对 workers 所走捷径的记忆，对他们的方法也没有依恋。它只读呈现出来的东西。
那恰恰是让我们的 Oracle 成为校准合并而非投票轮次的结构属性。Oracle 不知道哪个 Sister 起草了哪个场景。它接收归一化的输出，并按概率合并它们，降序排列，熵以 nats 计。独立性是让 ensemble 校准而非平均的机制。[ORIGINAL DATA] the 21-paper academic series plus Theorem 3 将此形式化：一个合并预测恰在贡献者独立且合并机制在测量自身散度时校准。
计划来自真实的工作，而非流程图
文章在一个点上很谨慎，那一点把真正的 orchestrator 与脚本化 pipeline 区分开：经理在当下决定计划。你不去脚本化「always spawn three workers」。你交出目标，主代理看实际的工作并决定多少 workers、谁做什么、什么需要检查——因为你无法预先预测子任务。这就是工作流引擎与 AI OS 的区别。前者执行你上月画的流程图；后者根据面前工作的形状来路由工作。这是我们自 2016 年起构建 HAI Engine 所围绕的形状——先路由，再响应。
何时不用子代理
委派结果，而非步骤
文章运行一年后的经验法则：委派结果，不委派步骤。如果你能用一句话交出任务并在不看过程的情况下判断结果，那就是子代理的工作。如果你需要监督，就留在主对话里。那是一个路由测试：边界能否承载一个干净的结果，还是工作会从中泄露？
一条推论：当各阶段共享上下文时，不要委派给子代理。如果规划、构建和测试都需要同一份累积理解，把它们分到隔离的代理意味着每次交接都要重新解释情况。保护主上下文的隔离变成了扼杀工作流的税。
常驻专家不是一次性子代理
文章画了一条有用的界线：为一次任务生成并消失的一次性子代理是承包商；带有持久记忆的常驻专家是雇员。你从承包商开始；你不断召回的那些，你雇用。机制的差别是在会话之间存活的记忆。
在 Everythink，Sisters 是常驻专家。它们的性格在运行时从 TOML 文件加载，编辑一个不需要重新编译，prompt 版本在每次运行时被盖戳以保证可复现性。它们是带办公桌和被测量产出的雇员。Oracle 是从未见过捷径的评审者。
这对你的 network 意味着什么
客户主权是一个作用域保证
子代理模式最深的教训不关于 AI。它关于主权。文章作者用五个他定义、限定并拥有的专家经营整个业务——Nova、Quill、Rack、Atlas 和他自己。没有一个能碰另一个的工作，因为他布了边界。那就是客户主权：你的 network、你的品牌、你的数据、你的路由规则。
在 Everythink，客户主权是以同样方式实现的作用域保证。一个 Whitelabel Network 所有者定义 communities、rooms、权限作用域和模块表面。Eye Key——带一个空格，从不带连字符——是开发者的带作用域凭证：它恰好带有所有者授予的权限，不多一条。「一个访客无法 mint 一个 Eye Key」这一属性由 auth 机制保证，而非由一句策略话保证。
作用域伦理：仅限民用与防御
子代理模式在作用域上是中性的。把 Nova 挡在服务器之外的同一个机制，也能把一个 targeting 代理限制在民用边界内——或不。机制不决定作用域；操作者决定。这就是为什么 Everythink 的书面策略边界仅限民用与防御用途，也是为什么那条边界是一个作用域决策，而非一句营销话。一个保证「该代理不能触碰进攻性目标」的机制，以与 Nova 的工具列表保证她不能发邮件相同的方式实现：在边界处省略该能力。
包容性设计是同一纪律在另一个方向上的应用。一个在更小模型上以零头价格运行的子代理，是一个低连通性包容机制——文章明确点名了成本拨盘。我们的多语言、多模态、低连通性设计遵循同一逻辑：路由层不假设快速连接或单一语言。
关键要点
- 子代理是一个文件里的两个机制：一个描述负责路由（the space is the router），一个工具列表保证作用域（Theorem 3）。
- 上下文腐烂是一个度量问题；修复是隔离，不是更大的窗口。HAI Engine ✅ 自 2016 年起在生产中运行此模式。
- 干净交接是一条度量边界——40,000 tokens 进，三个段落出——而「主上下文保持干净」这一属性恰在交接被实现并测量时得到保证。
- 「Nova can't send email」是 Theorem 3 的白话：属性恰在工具限制机制被实现时成立，而你可以读列表来度量它。
- workers-plus-reviewer 模式是一个 ensemble。Oracle 在不知道谁起草了什么的情况下合并 Sisters 的输出——独立性是校准机制。
- 永不提升一个状态：Social ✅、Campaigns ✅、Whitelabel Network ✅ 是 Production；Matchmaking ⚠️、Marketplace ⚠️、Calendar ⚠️ 是 Partial；Wallet & Token 🔵、Super App 🔵、Community Credit 🔵 是 Roadmap，须经 Howey 审查，不承诺结果。
- 委派结果，不委派步骤。路由测试是边界能否承载一个干净的结果。
常见问题
子代理和多代理团队是一回事吗？ 不是。团队是隐喻；子代理是一条路由规则加一个作用域保证。描述字段把工作路由给专家；工具列表保证专家不会越出自己的轨道。
为什么工具限制比 prompt 更重要？ prompt 是请求；工具列表是机制。「Nova cannot send email」这一属性由工具列表保证，而非由请求 Nova 不要发邮件保证。Theorem 3：一个属性恰在其机制被实现并测量时得到保证。工具列表在边界上可度量；prompt 不是。
我什么时候该用 skill 而非子代理？ 当工作是一个在你当前对话中运行的可重复流程时。子代理付隔离成本——全新上下文、重新解释情况——这对冗长或受限工作是值得的，对共享你上下文的流程则是浪费。
这与 Everythink 的 network-to-community-to-room 拓扑如何关联？ 二者都是路由机制。子代理的描述把一个 prompt 路由给专家；URL 空间把一个请求路由给拥有该能力的 room。路由发生在任何东西响应之前。那就是 the space is the router。
Sisters 是子代理吗？ Sisters 是常驻专家，性格在运行时从 TOML 持久加载。它们在各自干净的上下文中起草；Oracle 在不知道哪个 Sister 写了哪个场景的情况下把草稿合并成校准的 ensemble。独立性使预测校准而非平均。
Sources
- 2026 — Professor Glitch, askglitch.com, "Claude Code Subagents: Turn One AI Into a Whole Team" — https://www.askglitch.com/blog/claude-code-subagents
- 2026 — Anthropic, "Building Effective Agents"（被源文章引用以说明 orchestrator-workers 模式）— https://www.anthropic.com/research/building-effective-agents
- 2026 — Claude Code documentation, "Sub-agents" — https://code.claude.com/docs/en/sub-agents
创建你的 network 并自己布线路由规则——the space is the router，而保证活在机制里。
