当AI Agent从演示demo走向真实生产环境，上下文窗口爆满、响应延迟等痛点开始显现。Inngest联合创始人提出的三种核心子代理模式——同步执行、异步汇报、定时延后，为Agent系统设计提供了关键架构思路。本文深度解析这些模式如何通过上下文压缩技术解决系统可持续性问题，并探讨通用Agent与专业化Agent的权衡之道。

你有没有想过，为什么很多 AI agent 系统在演示时看起来很酷，但一旦投入实际使用就会遇到各种问题？上下文窗口爆满、响应变慢、对话质量下降，这些都是真实存在的痛点。最近我读到 Inngest 联合创始人 Dan Farrelly 的一篇文章，他分享了一个非常有意思的观点：每个真正能投入生产的 AI agent 系统，最终都会需要三种 sub-agent（子代理）模式。不是两种，也不是四种，恰好是三种。这个观点让我深入思考了很久，因为它触及了 AI agent 系统设计的本质问题。

Dan Farrelly 在开发通用 AI agent 系统时发现，问题的关键不在于你是否需要 sub-agent，而在于你如何把它们连接起来。他提出的三种模式分别是：同步执行并等待结果、异步执行后汇报、以及定时延后执行。听起来很简单，但这三种模式背后隐藏着对 AI agent 系统架构的深刻理解。我在研究这个话题时发现，这不仅仅是技术实现的问题，更是关于如何让 AI agent 真正为用户创造价值的问题。

Sub-Agent 到底解决了什么问题

在深入了解这三种模式之前，我觉得有必要先理解 sub-agent 存在的根本原因。Dan Farrelly 给出了一个非常清晰的定义：sub-agent 是由父 agent 生成的独立 LLM 执行上下文，用于处理特定范围的任务。父 agent 描述任务、提供工具，然后获得结果。关键是，sub-agent 应该在自己的上下文窗口中运行，这样就不会污染父 agent 的上下文。

这个设计背后的核心目的是 context compression（上下文压缩）。Cursor 团队在最近的 Latent Space 访谈中也提到了这一点。Sub-agent 的存在让父 agent 永远不需要吸收被委托任务的完整执行轨迹。想象一下，一个 sub-agent 可能读取了 8 个文件、进行了 15 次工具调用，但父 agent 只会看到一个 750 token 的摘要。

在我看来，这才是 sub-agent 真正的价值所在。很多人以为 sub-agent 的主要作用是实现并行执行，但 Dan 在文章中明确指出，真正的投资回报率来自于上下文管理，而不是并行性。父 agent 保持精简，就能在单次对话中处理更多任务，不会触及上下文限制，也不会降低响应质量。Dan 在 Utah 项目的测试中发现，使用 sub-agent 后，添加到父 agent 上下文中的 token 数量减少了 90% 以上。

这个数据让我意识到一个更深层的问题：我们在设计 AI agent 系统时，往往过度关注功能的丰富性，却忽视了系统的可持续性。一个 agent 如果在对话进行到一半时就因为上下文窗口满了而无法继续工作，那么它再强大的功能也失去了意义。Sub-agent 提供了一种优雅的解决方案，让系统能够在保持功能丰富性的同时，维持长期对话的能力。

三种 Sub-Agent 模式的本质

Dan Farrelly 总结的三种核心模式分别是：Sync（同步模式）- “做这件事并等待”、Async（异步模式）- “去做这件事，完成后汇报”、以及 Scheduled（定时模式）- “稍后做这件事”。每个 AI agent 系统都需要这三种模式，它们各有各的用途和考量。

同步模式是最直接的。父 agent 生成一个 sub-agent 并阻塞等待，直到结果返回。Sub-agent 运行、完成工作，然后将摘要作为工具结果返回。Dan 建议在以下情况使用同步模式：父 agent 需要答案才能继续工作。数据查询、分析、代码生成等需要反馈到下一步的任务，任何响应会影响接下来发生什么的情况。

我理解的同步模式本质上就像函数调用。你调用、等待、获得返回值。虽然结果会进入父 agent 的上下文窗口，但由于它是摘要而不是完整轨迹，那 90% 以上的压缩率意味着父 agent 可以委托很多次，上下文才会成为问题。这种设计非常聪明，它在保持控制流清晰的同时，也确保了系统的可扩展性。

异步模式则完全不同。父 agent 启动一个 sub-agent 后立即继续对话。Sub-agent 独立运行，完成后直接向用户回复。Dan 指出，这应该是你的默认选择。适用于长时间运行的研究、报告生成、起草、分析等具有副作用但不需要返回值的任务。

父 agent 不等待。Sub-agent 是完全独立的函数运行。完成后，它会发出一个包含响应和渠道路由信息的事件，回复会通过发起请求的任何渠道传递给用户。这里的权衡是：父 agent 无法整合结果。如果你启动三个异步 sub-agent，每个都在完全隔离中运行。这是一个特性而非缺陷，零协调开销，免费的并行执行，但这意味着父 agent 无法在同一轮中跨它们进行综合。

我觉得异步模式体现了一种非常现代的思维方式。传统的软件设计往往追求同步和可预测性，但在 AI agent 的世界里，我们需要接受一定程度的异步性和不确定性。把 sub-agent 想象成同事：你交接工作，说”完成后告诉我”，然后继续前进。多个异步 sub-agent 可以同时运行，无需任何协调代码。这种设计不仅提高了效率，也让系统更加灵活和可扩展。

定时模式是大多数人会忽略的，但 Dan 认为这是最有意思的一种。父 agent 安排一个 sub-agent 在未来特定时间运行。适用于后续跟进、应该智能化的提醒、定期检查，任何”稍后”应该意味着”在执行时使用最新数据”的情况。

这与传统的定时任务有本质区别。”提醒我明天上午 9 点检查部署指标”不是在上午 9 点发送通知，而是在上午 9 点运行一个 agent，实际拉取实时指标并发送分析。”周一向这个线程发送后续邮件”不是在周五编写的定时消息，而是周一运行一个具有完整线程上下文的 sub-agent。

我认为定时模式揭示了 AI agent 与传统自动化工具的根本差异。传统工具执行预设的动作，而 AI agent 在执行时刻根据当前状态做出决策。这种”延迟执行但智能决策”的能力，让 AI agent 能够处理那些需要时间维度考量的复杂任务。定时 sub-agent 是动态的、具有上下文意识的，在执行时使用世界的当前状态运行。不需要异步之外的新基础设施，它是相同的函数、相同的处理程序、相同的传递机制，唯一的区别是事件上的时间戳字段。

决策框架与实际应用

Dan Farrelly 提供了一个简单但实用的决策框架：需要结果才能继续？使用同步模式。独立任务，不需要阻塞？使用异步模式。多个独立任务？使用异步模式（并行）。应该在未来特定时间发生？使用定时模式。不确定？默认使用异步，它更便宜，让父 agent 保持精简。

让我印象深刻的是 Dan 的一个建议：不要为模型做选择，给它提供所有三个工具并配有清晰的描述，让它自己正确选择。这体现了一种信任 AI 判断能力的态度，也反映了现代 LLM 在理解任务需求方面的成熟度。

在实现层面，Dan 的团队采用了一个非常优雅的设计：一个函数处理三种模式。区别在于它如何被触发以及结果去哪里。他们使用 Inngest 构建了一个可重用的函数，通过不同的触发方式和结果路由来区分三种模式。这种统一的设计大大简化了系统架构，降低了维护成本。

关键的区别在于框架指令。同步 sub-agent 被告知要简洁（父 agent 会综合）。异步 sub-agent 被告知要详尽（它们是给用户的最终答案）。定时 sub-agent 就是带延迟触发的异步 sub-agent，不需要特殊处理。

我特别欣赏他们为什么使用两个工具而不是一个带有模式参数的工具的解释。模型在工具选择（从列表中选择）方面比参数优化（阅读参数描述并正确选择）更擅长。独立的工具意味着更清晰的日志、更清楚的追踪、更容易的调试。这种对细节的关注体现了经验丰富的工程师对系统可维护性的深刻理解。

在深度控制方面，Dan 的设计也很有意思。Sub-agent 获得相同的工作空间工具，但不能生成 sub-agent，实现了深度 1 的委托。没有路由逻辑，没有任务分类。模型读取工具描述，决定何时委托有意义，并编写自然语言任务描述。这种简单的设计避免了复杂的递归问题，同时保持了系统的灵活性。

通用 Agent 为什么胜过专业化 Agent

一旦你有了这三种模式，就会有一个诱人的下一步：为每个领域构建专业化的 agent。一个邮件 agent、一个数据 agent、一个编码 agent，每个都有自己的工具和提示词。Dan 明确建议不要马上跳入这个诱惑。

他的团队内部构建过专业化 agent 系统和它们之间的自定义路由器。随着模型的进步，这种专业化变得远不那么重要，在大多数设置中甚至是一个繁琐的维护层。这个观察让我深思，因为它挑战了我们在软件工程中长期以来的一个信条：专业化带来更好的性能。

Dan 指出了几个关键问题。工具重叠。通用 agent 在编码工具或模式（如工具搜索、工具发现、技能）方面表现出色，按 agent 分离的整个工具库有时可能不是你需要的。路由悖论。你需要某种东西来决定哪个专家处理每个请求。硬编码路由在模糊情况下会失败。使用 LLM 作为路由器会增加延迟和新的故障模式。如果你的路由 LLM 调用足够智能，能够选择正确的 agent，它难道不能直接完成任务吗？这看起来就像一个通用 agent 委托了一个”任务”。

“错误 agent”问题特别值得关注。当路由器将任务发送给错误的专家时，故障模式特别糟糕。错误的 agent 会用不完整的能力尝试任务，可能以微妙错误的方式部分成功。系统会信任响应，因为它来自指定的专家。这些是奇怪的故障案例，很难处理或计划。

评估表面爆炸也是一个实际问题。有 N 个 agent 就需要 N 个独立的评估套件、1 个路由评估套件、O(N²) 对成对交互测试，以及端到端集成测试。单个通用 agent 只需要一个覆盖所有能力的评估套件。

我认为这里有一个更深层的洞察：复杂性往往来自过早的优化。我们倾向于在问题还没有充分暴露之前就试图通过架构设计来解决它。专业化 agent 看起来是一个优雅的解决方案，但它引入的复杂性可能远超它解决的问题。

Dan 引用了 Anthropic 的”构建有效 Agent”论文中的观点：”一致的是，最成功的实现并没有使用复杂的框架或专业库。相反，它们使用简单、可组合的模式构建。”Cursor 团队在播客中也描述了使用”基本通用的任务接口，主 agent 可以定义进入 sub-agent 的内容”。Sub-agent 首先是上下文压缩边界，其次才是并行性。模型在运行时定义 sub-agent，而不是开发者在构建时定义。

这让我想起软件工程中的一个有趣现象：微服务的爆发然后回归到模块化单体。开销开始超过收益。通用 agent 也类似。从简单开始，只在必要时专业化，这可能是更明智的策略。

什么时候专业化确实有意义

尽管如此，Dan 也承认在某些情况下专业化确实会胜出。不同的模型要求。一个任务需要视觉能力，另一个需要快速分类，路由到不同的模型。安全边界。Agent A 访问客户数据，Agent B 只访问公共数据。监管要求。某些领域需要可审计的、独立的处理管道。经过验证的评估驱动证据。你的评估显示专业化 agent 在特定任务上始终优于通用 agent。

关键原则是：专业化应该由测量的必要性驱动，而不是架构美学。从通用开始，在有意义时再专业化。这个原则不仅适用于 AI agent 系统，也适用于几乎所有的软件设计。我们经常被”完美架构”的追求所诱惑，但真正的智慧在于认识到什么时候简单就是最好的。

在我看来，这种务实的态度是构建可持续 AI agent 系统的关键。技术进步的速度非常快，今天看起来必要的专业化，明天可能就变得多余。保持系统的灵活性和可适应性，比追求当下的完美架构更重要。

未来的探索方向

Dan 的团队目前使用的方法是通用的，适用于所有三种模式：同步、异步和定时。他们正在探索一些新的方向。自我迭代 agent。有了定时 sub-agent，为什么 agent 不能继续在自己和系统上迭代？成本和预算自然会成为考虑因素。

编排感知。异步和定时 sub-agent 返回它们的事件 ID。通过 API 和上下文，系统中的任何 agent 或 sub-agent 都可以知道什么在运行、在哪里运行，获取状态和结果。它不再只是循环加扇出，而是变成了一个网络。

回调和其他模式。当前的参考示例使用渠道作为工作完成时的回调机制，但具有不同类型回调的通用 sub-agent 系统会是什么样子？例如更新 Linear 任务、在数据库中存储研究或报告的引用。工具可以用于此，但回调提供某种程度的保证。

这些探索方向让我看到了 AI agent 系统演进的可能路径。从简单的请求-响应模式，到复杂的网络状协作，再到自主的持续优化。每一步都建立在坚实的基础之上，而不是追求华而不实的创新。

我对这个话题的一些思考

读完 Dan Farrelly 的这篇文章，我有几点深刻的感受。AI agent 系统的设计，本质上是在管理复杂性。我们倾向于通过添加更多功能、更多专业化来解决问题，但往往忽视了简单性的力量。三种 sub-agent 模式的价值不在于它们有多复杂，而在于它们多么清晰地映射了实际需求。

上下文管理是一个经常被低估的问题。我们看到 LLM 的上下文窗口越来越大，从 4K 到 8K 到 32K 甚至 100K，很容易认为上下文限制不再是问题。但 Dan 的实践表明，即使有更大的上下文窗口，有效的上下文管理仍然至关重要。一个能够在长对话中保持清晰和高效的系统，远比一个依赖巨大上下文窗口的系统更可持续。

异步思维在 AI agent 系统中特别重要。传统软件往往追求同步和可预测性，但在处理复杂任务时，接受异步性实际上能带来更好的用户体验。用户不需要等待一个长时间运行的任务完成才能继续对话，系统可以在后台处理，完成后通知用户。这种设计更符合人类的工作方式。

通用性与专业化的平衡是一个永恒的主题。软件工程的历史充满了钟摆式的摆动：从单体到微服务再回到模块化单体，从通用到专业再回到通用。Dan 的建议是从通用开始，只在有明确证据时才专业化，这是一个经过实践验证的智慧。

最后，我觉得这篇文章最有价值的地方在于它的务实性。它不是在推销某种理想化的架构或炫技性的技术，而是在分享真实的实践经验和思考。在 AI agent 这个快速发展的领域，这种脚踏实地的态度特别珍贵。

如果你正在构建 AI agent 系统，我建议你认真考虑这三种 sub-agent 模式。不要被复杂的架构诱惑，从简单开始，让实际需求驱动你的设计决策。保持系统的灵活性，因为这个领域变化太快，今天的最佳实践明天可能就过时了。最重要的是，关注真正重要的事情：上下文管理、用户体验和系统的长期可维护性。