子 Agent 到底怎么工作？从一次任务交接说起

你打开一个陌生项目，问 Agent：“这个项目怎么启动？入口文件在哪里？”

为了回答这个问题，它可能要读说明文档、查启动脚本，再顺着配置找到入口。直接让一个 Agent 做完当然可以。但如果你还让它修改功能、排查报错，这些查资料的过程也会挤进同一段对话，越积越多。

这时，可以把“查清启动方式”交给一个子 Agent。它专门读文件、找依据，最后把结论交回来；主 Agent 继续处理你原来的问题。

子 Agent 的作用，是把一块可以独立完成的工作交出去，再拿回一份能继续使用的结果。 先顺着这次交接走一遍，比一上来记一堆 API 名字更容易理解。

一次委派，只看四步

在 AI SDK 的这套模式里，主 Agent 通过一个工具调用子 Agent。这个工具像一个明确的交接入口：主模型提出任务，程序启动子 Agent，子 Agent 完成后再把结果送回去。

下面四步连起来，就是一次完整委派。点击节点，可以查看这一步具体交接了什么。

从用户提问，到拿回研究结果

主 Agent 拆出任务

从“帮我熟悉这个项目”中，拆出“查清启动命令与入口文件”。

主 Agent 仍然负责用户的完整目标。这次只把范围清楚的一小块研究交出去，并通过研究工具提交任务。
程序启动子 Agent

研究工具把任务和项目背景一起传给子 Agent。

模型提出调用请求后，SDK 执行工具函数。真正启动子 Agent 的是这段程序调用，不是两个角色仅靠名字就自动连在一起。
子 Agent 查找依据

它在自己的上下文里读文档、查配置，找出命令与入口。

子 Agent 可以按需要多次使用读取或搜索工具。查过哪些文件属于研究过程；找到的结论还需要附上相应依据。
主 Agent 接回结果

拿到结论和证据后，继续回答用户，或开展下一步工作。

例如收到“启动命令来自 package.json，入口由构建配置指定”。主 Agent 再结合用户目标组织答案；子任务结束不代表整个任务结束。

这里值得注意的是第三步：子 Agent 有自己的研究过程。它可以阅读很多内容，而主 Agent 不必把每一次搜索和每一段文件都重新读一遍。这是拆分研究任务的一项实际收益。AI SDK 的 Subagents 文档也把卸载大量探索内容列为主要用途之一。

现在假设主 Agent 只交代了一句：“研究一下这个项目。”

问题马上来了：哪个项目？要研究什么？查到什么程度算结束？主 Agent 在聊天里见过项目路径，不代表子 Agent 的独立上下文里也有。

与其给子 Agent 一个含糊的角色设定，不如给它一张能执行的任务卡：

这次要交付的研究

目标：找到启动命令和入口文件。

位置：当前选中的项目目录。

范围：读取文档与配置，本次不改文件。

交付：结论、对应文件位置，以及还没确认的地方。

这几项把“研究一下”变成了可检查的工作。路径可以由应用从当前会话中取得，再放进任务输入，减少模型转述路径的环节。至于能读哪些文件、能不能修改配置，要由实际的工具和权限决定；在文字里写了一个路径，并不会自动建立访问隔离。

同样，交付也应该具体。比如“配置中声明的启动命令是 npm run dev，但我没有实际运行”，就比“研究完成”有用得多：前一句说清了找到什么、依据在哪一层、验证到哪一步。

子 Agent 查文件可能要花一些时间。如果界面一直没有变化，用户很难判断它是在工作，还是已经停住了。因此，我们可以把阶段性进度持续显示出来。

但界面需要的内容，和主 Agent 下一步需要的内容，并不完全相同。

同一次研究，从进行中到交付

正在查找

用户看到：“正在检查项目文档和启动配置。”

这是进度，说明当前正在做什么。此时还没有最终研究结果，主流程继续等待这次工具调用。
找到线索

用户看到：“已找到启动脚本，正在确认入口。”

界面更新同一条任务的当前状态，而不是把每一份完整状态反复追加。找到一条线索，也还不能报告任务成功。
交付结果

主 Agent 收到：启动方式、文件依据和未验证事项。

用户可以查看过程；主 Agent 可以只接收整理好的交付内容，用它继续工作。两种输出的详细程度可以不同。

AI SDK 提供流式输出，让界面逐步接收更新；也提供 toModelOutput 这样的转换入口，用来决定工具结果中的哪些内容交给主模型。

不过，选出一段文字，不等于自动写好了一份总结。 如果子 Agent 最后只写“完成了”，原样取出最后一段文字，主 Agent 收到的也只有“完成了”。要拿到有用结果，仍然得把交付要求说清楚，并检查输出是否真的满足它。

回到最初的问题。现在子 Agent 返回了一个启动命令，我们就可以直接告诉用户“已经验证能启动”吗？

还不能。读到配置里的命令，只能说明项目声明了这种启动方式。它是否能在当前环境里运行，要实际执行后才知道。同理，有最终输出，只说明这次工具调用交回了东西；它可能因为步数用完而结束，也可能没有找到全部答案。

取消任务也有类似的边界。用户按下停止按钮后，取消信号需要继续传到子 Agent 和底层请求，执行代码也要配合处理。这个信号不会撤销已经完成的文件修改，更不会自动关掉整个服务。

所以，主 Agent 接回结果后，应当保留这些区别：哪些是文件里查到的，哪些已经运行验证，哪些仍然缺少信息。用户据此才能决定下一步，而不是被一句笼统的“成功”带过去。

如果只是读一个短文件、回答一个明确问题，主 Agent 直接完成通常更省事。引入子 Agent 会增加一次交接，也可能增加等待时间和模型调用成本。

当一块工作需要大量探索、可以独立开展，而且最后能交付清晰结果时，委派才更值得尝试。比如查一个陌生项目的启动链路：子 Agent 消化阅读过程，主 Agent 拿到结论和证据，继续推进用户原来的目标。

设计时可以先问自己一个问题：这块工作交出去之后，对方能否在明确的范围内完成，并交回一份我能接着用的东西？ 如果不能，先把任务交代清楚，比继续增加 Agent 角色更有帮助。

本文以 AI SDK 的子 Agent 工具调用模式为例。图中内容是教学示意，不代表执行过某个真实项目。