当代码代理开始“分裂”：Subagents 背后的工程逻辑与使用范式重构

如果你已经把 OpenAI Codex 当成日常开发工具，那你大概率已经撞到过一个“隐性瓶颈”：任务越复杂，结果反而越不稳定。

最近 Subagents（子智能体）能力全面开放，本质上不是“多开几个线程”这么简单，而是把 AI coding agent 的执行模型，从单进程串行推理，升级成了可调度的分布式认知系统。

这篇不讲功能介绍，重点拆它背后的设计动机，以及为什么它会改变你写 prompt 的方式。

一、问题本质：不是模型不行，是“上下文架构”错了

很多人把 agent 出现质量波动，归因于模型能力，其实问题常常出在执行模型。

典型模式是这样的：

一个 agent，被要求连续完成：分析 → 修改 → 总结

表面看是一个任务，实际上是三种完全不同的“认知模式”：

• 分析：信息收集 + 模式识别
• 修改：精确操作 + 约束执行
• 总结：抽象压缩 + 表达生成

但在传统 agent 里，这三步是共享同一个上下文窗口的。

结果就是：

• 前面的推理痕迹（scratchpad）不断累积
• 中间的临时结论变成“噪声记忆”
• 后续任务开始误引用前面的上下文

这就是所谓的 Context Pollution（上下文污染）。

你看到的现象不是“AI 变笨了”，而是：

它的“工作记忆”已经被历史垃圾占满了。

二、Subagents 的核心设计：把“上下文”变成隔离单元

Subagents 并不是简单的并发执行，而是引入了一个关键抽象：

上下文隔离（Context Isolation） = 认知空间隔离

每个子智能体具备：

• 独立上下文窗口
• 独立推理链（chain-of-thought）
• 独立工具调用历史
• 独立权限边界

换句话说，它更像是：

从“一个人在多线程思考” → 变成“多个人各自专注一个问题”

这和操作系统里的进程模型非常类似：

三、从“提示工程”到“任务调度”：范式变化

Subagents 真正改变的，不是能力，而是使用方式。

以前你写的是：

“帮我做 A、B、C 三件事”

现在更接近：

“定义三个角色，并行执行 A / B / C，最后汇总”

这本质上是从：

• Prompt Engineering（提示工程）

升级为：

• Task Orchestration（任务编排）

你需要考虑的不再只是“怎么说”，而是：

• 怎么拆任务
• 怎么定义边界
• 怎么避免依赖
• 怎么控制资源

四、什么时候并行才有意义？

不是所有任务都适合 Subagents。

关键判断标准可以抽象成一个图：

任务依赖图（Task Dependency Graph）

✅ 适合并行（无依赖或弱依赖）

这些场景的共性是：子任务之间不需要彼此输出

1. 横向扫描类任务

• 多目录代码分析
• 多文件批处理
• 多模块审查

本质是 Map：

Input → [Agent1, Agent2, Agent3] → Merge

2. 多视角评估

• 安全审计
• 性能分析
• 可维护性 review

每个 agent 使用不同“评价函数”，避免互相干扰。

3. 批量数据处理

• CSV / 日志分析
• 数据清洗
• 格式转换

典型 embarrassingly parallel 问题。

❌ 不适合并行（强依赖）

1. Pipeline 型任务

A → B → C

例如：

• 先生成 schema → 再写代码 → 再跑测试

这种场景并行只会增加调度成本。

2. 高耦合修改

• 同一个文件多处联动修改
• 需要共享状态的 refactor

拆开反而会冲突。

五、子智能体 = 可编程的“组织结构”

Subagents 有意思的地方在于：它不是一个技术 feature，而是一种组织建模工具。

你可以把它理解为：

在代码执行层模拟一个工程团队

内置角色本质对应开发流程：

• explorer → 调研 / 信息收集
• worker → 实现 / 修复
• default → 协调 / 通用处理

但真正的威力在自定义角色。

六、角色设计的三个关键维度

一个高质量 agent，不是 prompt 写得多，而是约束设计得好。

1. 模型分层（Model Stratification）

不是所有任务都值得用大模型。

策略类似人力分工：

• 轻量模型 → 搜索 / 分类 / 提取
• 重模型 → 推理 / 设计 /决策

避免“用 GPT-5 做 grep”。

2. 权限隔离（Sandboxing）

典型配置：

• read-only agent → 只读分析
• write-enabled agent → 执行修改

好处：

• 降低误操作风险
• 提高系统可控性

3. 可观测性（Observability）

多个 agent 并行时，最大的问题是：

你不知道谁在干什么

通过：

• 昵称（nickname）
• 独立线程
• 可切换上下文

你可以实时 inspect 每个 agent 的状态。

七、安全模型：为什么它比你想的更重要

多 agent 系统最危险的不是“做错”，而是“悄悄做错”。

Subagents 的两个关键约束：

1. 权限继承（Privilege Inheritance）

子智能体权限 ≤ 主会话权限

→ 不存在“越权执行”

2. 人类审批（Human-in-the-loop）

关键操作必须确认：

• 删除文件
• 修改配置
• 执行命令

这实际上是在做一件事：

把 AI 从“自动执行系统”限制为“建议执行系统”

八、成本控制：防止系统“指数爆炸”

Subagents 最大的隐患不是复杂度，而是成本失控。

核心风险：

agent → 子 agent → 孙 agent → 指数级增长

系统通过三个参数限制：

1. max_threads

限制并发数量

→ 控制横向扩散

2. max_depth

限制递归层级（最关键）

→ 控制纵向爆炸

3. job timeout

防止长尾任务吞资源

这套机制本质是在模拟：

Kubernetes 的资源配额 + 调度限制

九、一个更本质的变化：AI 从工具 → 系统

把 Subagents 和之前的能力放在一起看：

• Skills → 可复用流程
• Automations → 定时执行
• Subagents → 并行执行

组合起来，其实是在构建：

一个“可编排的 AI 执行系统”

而不是一个聊天工具。

十、结论：你在写的不是 prompt，而是“组织结构”

Subagents 最值得重视的一点，不是性能提升，而是：

它强迫你用“系统设计”的方式使用 AI

你需要思考：

• 任务怎么拆（架构能力）
• 角色怎么定义（抽象能力）
• 权限怎么划（安全意识）
• 成本怎么控（工程约束）

这已经不是 prompt engineering 了，而更接近：

AI-native software engineering

如果你只把 Subagents 当成“并行加速器”，你会觉得它只是 Claude Code 的一个对标功能。

但如果你把它当成：

一个最小可用的多智能体操作系统

那它的上限，远不止写代码。