一个真实会崩的任务假设你对 AI 说:给这个项目的用户模块加上手机号登录,要跟现有的邮箱登录走同一套 session 逻辑,写完跑测试。一个单打独斗的 Agent 会怎么做?它得先找到现有登录代码在哪,读懂 session 是怎么签发的,找到测试文件的组织方式,搞清楚数据库 schema 要不要改,然后才能动手写,写完还要跑测试、看报错、修。前面那一大半——找、读、搞清楚——会往对话历史里灌进多少东西?第 1 步: exploreCode(login) → 返回 12 个文件的片段,3000 tokens 第 2 步: readFile(authService.ts) → 整个文件,2000 tokens 第 3 步: exploreCode(session sign) → 又 8 个片段,2500 tokens 第 4 步: readFile(userRepo.ts) → 又 1800 tokens 第 5 步: browseSymbols(auth/) → 符号列表,900 tokens ... 第 12 步: 终于开始写代码到第 12 步的时候,上下文里塞了两万多 token 的中间过程。而这些内容里,真正对写代码有用的可能只有三句话:「session 在authService.signSession()里签发」「用户表在userRepo.ts,加字段要改 migration」「测试用 vitest,放在test/auth/」。剩下的全是噪音。但它们还在上下文里,和有用信息挤在一起,每一轮都要重新喂给模型。这就是单智能体在长任务里的第一个死穴。✶ 为什么这是死穴,而不只是有点浪费上下文不是无限的,也不是免费的。它是一个共享且会被污染的资源:探索阶段的垃圾不会自动消失,它会一直挤占后面写代码阶段的空间。更糟的是,模型的注意力会被稀释——当有用信息埋在两万 token 噪音里,模型忘记原始目标是常态,不是异常。三个真问题上下文污染只是最显眼的一个。把单智能体推到复杂任务上,会同时撞上三面墙。问题一:上下文被中间过程污染就是上面那个例子。探索的过程和探索的结论价值差了两个数量级,但它们在同一个消息历史里,同等地占位置。问题二:能力过载一个 Agent 如果同时握着readFile、applyEdit、runCommand,那么在我只想看看这个文件的时候,它也有能力改掉它。这不是假想。模型在探索阶段顺手改点东西、在只该读的时候执行了命令,是真实发生的失败模式。工具箱越大,每一步走错的可能性越大——因为可选动作的空间更大了。问题三:无法并行找到 session 逻辑和搞清楚测试怎么组织是两件完全独立的事。它们不互相依赖,理论上可以同时做。但单智能体的 ReAct 循环是严格串行的:想 → 做 → 看 → 想 → 做 → 看。就算两件事毫无关系,它也只能一件一件来。一个需要 8 次工具调用的任务,就是 8 次模型往返的等待。解法:派人去干,只要结论三个问题,一个解法——开一个新的 Agent,给它独立的上下文和受限的工具,让它去干那件小事,只把结论带回来。对照着看:问题子智能体怎么解上下文污染子智能体有自己的消息历史。它读了 20 个文件,那 20 个文件的内容留在它的上下文里,主 Agent 只收到一句「session 在authService.signSession()」能力过载子智能体按角色分配工具。一个负责探索的子智能体,工具箱里根本没有applyEdit——不是不该改,是改不了无法并行主 Agent 可以一次派出三个子智能体,它们同时跑各自的 ReAct 循环用第一节那个任务举例,派人之后是这样:主 Agent: ├─ 派 explorer #1 → 找到登录和 session 签发逻辑 ├─ 派 explorer #2 → 搞清楚测试如何组织、用什么框架 │ (两个同时跑,各自烧自己的上下文) │ ├─ 收到 #1: session 在 authService.signSession(),邮箱登录入口在 loginByEmail() ├─ 收到 #2: vitest,测试放 test/auth/,每个 service 一个 .test.ts │ (主 Agent 上下文只增加了两段话) │ └─ 派 executor → 在 authService 加 loginByPhone(),复用 signSession(),补测试主 Agent 的上下文里,始终只有任务和结论。那两万 token 的探索过程,在子智能体结束时就跟着它一起消失了。✶ 这里的关键取舍子智能体的上下文隔离是双向的:主 Agent 看不到子智能体的过程,子智能体也看不到主 Agent 的历史。这带来一个必然代价——你派任务时必须把话说全。子智能体只能看到你给它的那一句 task 描述。所以任务描述的质量直接决定子智能体的成败,这是多智能体架构里最容易翻车的地方。那它是怎么实现的?到这里你可能会以为:这得是个大工程吧?要有任务队列、状态机、调度器、进程管理……实际上,在 LoopAgent 里,主 Agent 获得派人干活这个能力,靠的是给它的工具箱里多塞三个工具:// workflowTools.tsspawnSubagent// 派一个子智能体waitForSubagents// 等结果cancelSubagent// 撤回就这三个。主 Agent 的 ReAct 循环一行都没改——它调用spawnSubagent和调用readFile在机制上完全一样:发一个 tool_call,拿一个字符串结果。这是整个设计里最漂亮的一步。下一篇我们就从这三个工具的定义开始,看任务图是怎么在 ReAct 循环里一个节点一个节点长出来的。关于 LoopAgent本文的实现来自 LoopAgent——一个 VS Code AI 编程扩展,带代码智能索引、函数调用式 ReAct 循环和多智能体编排。本文提到的代码在src/extension/agent/下。觉得有用的话,欢迎点个 star ⭐项目地址:https://github.com/oi12344/loopagent-vscode 下一篇:02 · 三个工具,就是全部编排
){kind=tracking}
