▶ 原文链接

领域特定代理的未来

来源： YouTube (AI Engineer) | Justin Schroeder | Jun 28, 2026 播客： AI Engineer 分类： 其他 原文发表： Jun 28, 2026 纪要生成： 2026-06-29

---

嘉宾/话题简介

Justin Schroeder 是一家处于隐身模式的初创公司 Standard Agents 的成员，也是多个知名开源项目（如 Dmux、ArrowJS）的作者。他在本演讲中系统阐述了为何领域特定代理将在AI未来扮演重要角色。他通过类比工业革命、软件开发原则以及阿波罗登月计划，批判了当前主流通过 MCP 和技能堆砌来增强通用代理的做法，并提出了一种高度模块化、高效、安全且经济的代理构建新范式。

---

分节详述

00:00 演讲者介绍与时代背景

本节重点

• 演讲者 Justin Schroeder 来自初创公司 Standard Agents，同时也是多个开源项目的作者。
• 当前AI时代可类比工业革命，核心催化剂是从“用机器驾驭能源”转向“用代理驾驭智能”。
• 目前业界对“Agent”的定义尚未统一。

详细精要

• 演讲者背景：Justin Schroeder 就职于 Standard Agents，公司目前处于隐身模式。他是开源项目的活跃贡献者，代表性作品包括：
• Dmux：一个出色的编码代理多路复用器。

• ArrowJS：类似 React 的 UI 框架，专为代理时代设计。

• 时代类比：

• 当前时刻非常类似于 工业革命，甚至可能是一个加速版的工业革命，其重要性可能更大。

• 工业革命的关键催化剂是 “用机器驾驭能源”，而当前AI时代的催化剂则是 “用代理驾驭智能”。

• 代理（Agent）的定义模糊性：

• 尽管已进入“代理时代”，但业界仍未就代理的定义达成共识。
• Justin提出的定义：代理是一种确定性软件，它利用模型产生的非确定性结果来追求某个预期目标。
• 他认为 Agent 和 Harness 之间的区别过于学究化，不重要，在本次演讲中可以互换使用。

💬 精华片段（中文）

“代理是确定性的软件，它利用模型产生的非确定性结果来追求某个预期目标。”

"Agents are deterministic software that harness the non-deterministic results produced by models in pursuit of some desired objective."

---

03:11 企业构建自定义代理的冲动与困境

本节重点

• 虽然大众对知名代理认知有限，但几乎所有企业都在尝试构建自定义代理。
• 构建自定义代理的核心驱动力是集成，即将企业数据与AI深度结合。
• 构建健壮的、可扩展的生产级代理极其困难，面临多提供商、持久化执行、遥测和可移植性等重重挑战。

详细精要

• 代理的大众认知度低与企业构建热：
• 普通大众可能只知道 Claude 或 Codex，甚至不知道它们是代理。

• 然而，从街边的房地产中介、独立的保险经纪人到 财富500强 公司，所有人都在尝试构建自己的自定义代理。

• 根本原因：集成（Integration）的需求：

• 企业普遍认为，如果能恰当地将AI与自身数据集成，业务将获得巨大飞跃。

• 构建自定义代理是他们发现的首要解决方案。

• 构建代理的现实困难：

• 代理循环（Agentic Loop）的编排：需要极其小心地确保代理循环被正确编排。
• 多提供商抽象：需要处理大量不同的模型提供商的抽象层。尽管像 Vercel AI SDK 这样的工具很有帮助。
• 持久化执行（Durable Execution）：必须确保在出现故障时能从断点恢复，这在规模上是很困难的问题。
• 缺乏构建标准：目前没有定义好的代理构建方式。近期发布的 Vercel 的 Eve 可能是最接近标准化的东西。
• 遥测与可观测性（Telemetry & Observability）：想要诊断、微调并确保代理不失控，需要在每一步、每一轮都追踪传输内容，这极其困难，尤其是在生产规模下。
• 可移植性差：在一个环境中运行良好的代理，由于环境变量、系统需求、运行时等差异，很难迁移到另一台机器上运行。
• 不可组合性：为一个场景（如大学聊天机器人）构建的代理，几乎无法被复用于其它场景。

💬 精华片段（中文）

“构建健壮的代理就是很难。如果你去找任何IT部门的人聊，他们正在为此抓狂，因为有太多不同的关注点。”

"Building robust agents is just hard. And if you go talk to anybody in an IT department, they are pulling their hair out because there are so many different concerns."

---

07:52 MCP 和 Skills 的局限性

本节重点

• 由于构建代理困难，企业转向 MCP 作为集成方案，但它本质上沦为了一个工具分发机制。
• MCP 网站显示，其所有特性中，只有“工具”功能得到了广泛支持。
• 仅靠工具或技能（Skills）不足以解决根本问题，这好比给一个人大量工具或文档，并不能保证他能完成登月这样的复杂项目。

详细精要

• 转向 MCP：

• 在构建代理短暂受挫后，人们转向 模型上下文协议（Model Context Protocol, MCP），希望借此将公司信息（如 Zillow 的数据）注入到 Claude 或 ChatGPT 等大型通用代理中。

• MCP 的实际作用：

• 根据 MCP 官方网站在全球范围内对 MCP 客户端支持情况的统计，只有“工具（Tools）”这一列是完全填满的。

• MCP 实际上已成为代理的事实工具分发机制。如果企业需要将自己的工具接入其它代理，MCP 是一个好方法，但它尚未证明能提供其他方面的价值。

• 工具和技能的类比批评：

• 仅靠工具不够：我们不可能靠给一个人一堆工具就把他送上月球。
• 技能的局限性：技能（Skills）本质上是 Markdown 文件，充当文档。研究表明，使用过多技能反而会使代理表现显著变差。给一个人大量文档，虽然有帮助，但这也不是登月成功的根本。

💬 精华片段（中文）

“我们经常开玩笑说，我们可没有靠给一个人一大堆工具就成功把人送上月球。这不是完成一个超大型项目的现实方法。”

"I like to joke that we didn't land a man on the moon by giving one guy a ton of tools. That's not a realistic way to get a really large project done."

---

09:58 继承 vs. 组合：一种架构范式的转变

本节重点

• 当前主流的代理构建方式本质上是软件工程中的继承模式，即通过不断向上下文层添加新能力来增强代理。
• 这种方式适用于少量扩展，但面临上下文窗口膨胀导致收益递减的根本问题。
• 更好的替代方案是组合，即构建多个独立的、专精的领域特定代理，由一个协调器通过自然语言进行调度。

详细精要

• 当前代理栈的解构：
• 一个基本代理的信息栈由下至上主要包括：模型 → 系统提示词 → 工具 → 技能 → MCP → 对话消息。

• 几乎所有这些层最终都变成了模型的上下文（Context），人们解决集成问题的努力都集中在上下文和模型这两个领域。

• 继承（Inheritance）模式的困境：

• 用户不断向代理添加更多能力（如安装各种 MCP 和技能），这种行为在工程上被称为继承。

• 继承模式有效但受限：少量技能（如5个）运行良好，但当数量增至100个、1000个时，必然会在某个点达到收益递减，因为上下文变得过于臃肿。

• 组合（Composition）模式的提出：

• 替代方案是组合，这与“组合优于继承”的经典工程格言相符。
• 领域特定代理的结构：设想一个 Figma 代理，其系统提示词、工具和消息历史都仅与 Figma 操作强相关。它是独立的、完整的迷你代理。
• 协调与通信：多个这样的迷你代理（如 Gmail 代理、Travel 代理）之上，有一个协调器（Coordinator）。它们之间的通信机制是自然语言（英语）。

• 工作示例：主代理需要安排旅行，它会用英语向 Gmail 代理询问相关邮件，将结果传回，然后再用英语告知 Travel 代理进行预订。

• 登月计划的类比：

• 我们登月成功正是因为采用了组合模式：阿波罗计划由多个专家团队组成，每张面孔代表一个拥有特定技能和能力的团队。
• 在发射控制台，某个专家的大脑就是他的 LLM，仪表盘上的控制就是他的 工具，他的嘴就是 消息通道。他拥有的是完成任务的恰好足够的工具，而非所有工具。这几乎是一种针对代理世界的仿生学。

💬 精华片段（中文）

“在工程领域有一个术语：‘继承’。继承的原理是，你拿一个对象，然后不断给它添加更多属性……关于继承的事实是，它确实有效。但有一句老话：‘组合优于继承’。”

"We have a term for this in engineering. It's called inheritance... And the truth about inheritance is it works... But, there's an old saying, 'Composition over inheritance'."

---

15:10 领域特定代理的核心优势

本节重点

• 与通用代理相比，领域特定代理在Token效率、小模型实用性、安全性限制和可扩展性四个方面具有显著优势。
• 尽管这些代理目前尚未大规模公开出现，但演讲者所在的 Standard Agents 已在日常使用，并获得了宝贵的内部数据。

详细精要

• 演讲者命名并实践：

• Justin 将这类代理命名为领域特定代理，并透露其公司 Standard Agents 已经在这个生态系统中深耕了一段时间，虽然尚未公开发布产品。

• 优势一：极高的Token效率：

• 在特定任务中，Token使用效率往往能提高80%以上。

• 原因：当协调器向某个代理（如Gmail代理）下达任务时，该代理接收到的上下文极其精简，只有其系统消息、关键工具和一条来自协调器的消息，完全没有无关的对话历史。

• 优势二：与小型语言模型结合，实现巨大成本节约：

• 以 DeepSeek V4 Flash 和 Fable 5 为例，前者的单任务成本仅为后者的137分之1。

• 关键：小型模型可能在通用任务上反复失败，导致实际成本更高。但在领域特定代理中，模型只需在极简上下文中执行被专门挑选的、特定的任务，可以非常忠实地执行，从而在享受小型模型低成本的同时保证任务成功率。

• 优势三：可强制执行严格的能力限制，提升安全性：

• 当前，大型代理可以执行几乎任何操作，权限边界模糊，安全性堪忧。
• 领域特定代理本身就不能做所有事，它只能执行那些被明确批准的操作。虽然仍需要权限管理，但整个生态系统在本质上更具可控性。

• 当向企业IT人员（如"Doug"）解释时，这种区别能让他们安心。

• 优势四：卓越的可扩展性：

• 每个领域特定代理都是一个独立的小型执行环境，可以轻松地在云端被并行化。

• 它们不需要像大型单体应用那样需要巨型VPC，可以在全球不同地区同时运行数千个实例，无需地理上的共置。

• 当前状态的遗憾：

• 遗憾的是，此类代理目前尚未以公开、大规模的方式存在。

💬 精华片段（中文）

“像 DeepSeek V4 Flash 和 Fable 5 这两个模型之间的成本差距令人震惊。它每次任务比 Fable 便宜 137 倍。137倍！”

"If you look at the difference in two models like DeepSeek V4 Flash and Fable 5, the cost difference is mind-boggling. It is 137 times cheaper than Fable per task. 137 and 37 times."

---

21:00 市场预测与未来架构展望

本节重点

• 大胆预测：2026下半年到2027年将是领域特定代理和多代理编排爆发期，Vercel 的 Eve 框架的发布是早期信号。
• 经济驱动力：2026年，AI推理Token成本在历经下降后出现逆转上升，这在客观上推动了对更高效代理架构的需求。
• 描绘理想代理：一个完整的领域特定代理应由模型、系统提示、多种工具（函数/提示/子代理）、钩子、代理规则、自有文件系统和沙盒化代码执行环境共同构成。
• 多代理编排示例：展示了从顶层协调器到 Salesforce、Google Workspace、资产生成、合规等子代理如何通过递归子代理协同工作的复杂场景。

详细精要

• 公开预测：
• 随着进入2026下半年，将出现讨论构建领域特定代理及其框架的热潮。
• 2027年将基本成为"多代理编排之年"，这个词将开始被广泛讨论。

• 近日 Vercel 发布 Eve 框架，其官方描述中就明确包含了"domain-specific agent"，印证了他的预测正在变为现实。

• Token成本上升的逆趋势：

• 大多数人都认为智能成本应该持续走低，但在2026年这一趋势发生逆转。Standard Agents 追踪的数据显示：
• 不考虑智商调整时，Token成本在2026年截至目前已上涨76%。
• 考虑智商调整后，成本也上涨了29%。

• 这意味着，为大型企业寻找降低Token成本的方法变得至关重要。

• 面向客户场景的商业需求：

• 像 Fable 这样昂贵的模型无法直接面向客户部署，除非客户生命周期价值极高。

• 必须在保证高效能的同时实现高效率，而领域特定代理是实现这一目标的途径。

• 理想代理的完整构成要素：

• 模型与系统提示：基础。
• 工具层：
  • 函数：执行具体操作，如写入文件。
  • 提示：可作为工具调用的子提示或对另一个LLM的调用（例如，主模型使用 GLM 5.2，但用 Nano Banana 生成图片）。
  • 子代理：将另一个完整的领域特定代理作为其中一个工具。
• 钩子（Hooks）：用于注入或改变上下文，或执行副作用。例如，LLM无法感知时间，通过钩子在消息历史中注入一个模拟的“现在是几点？太平洋时间下午6:45”的对话，让模型知晓时间。
• 代理规则（Agent Rules）：定义代理的操作规范，例如一轮对话的最大步数、调用工具时的验证要求等。

• 必须的原语：

  • 自有文件系统：每个代理都应有一个沙盒化的文件系统，用于存储生成的文件。
  • 沙盒化代码执行：每个代理都应有一个安全的代码执行环境，可以读写文件、运行代码，但不会与宿主操作系统发生越权交互。

• 递归子代理编排的蓝图：

• 顶层协调器代理统筹全局，其下可挂载：
• Salesforce 代理：精通所有 API，拥有公司实例的全部凭证。其下可挂载：
  • 资产生成代理：精通图像、SVG 等资产生成，并能进行自我反思和质量保障。
• Google Workspace 代理：处理电子表格等办公套件任务。
• 法务团队代理：审查其他代理的输出。其下可挂载：
  • GDPR 合规代理：用于处理面向欧洲客户的合规问题，避免主代理上下文膨胀。
  • OSHA 合规代理：用于应对其他复杂的法规要求。
• 整个体系通过高效、小型的独立代理协同完成任务，同时始终保持最小化的上下文窗口。

💬 精华片段（中文）

“这就是领域特定代理背后的理念。你可以拥有各种各样高效的小型代理协同工作，但全程都维持着最小化的上下文窗口。”

"That's the idea behind domain-specific agents. You can end up with all kinds of highly efficient, small little agents that are all working together, but maintaining small minimal context windows all the way through."

---

专业术语注释

术语	解释
Domain-Specific Agent	领域特定代理。Justin Schroeder 提出的核心理念，指针对特定垂直领域（如Figma、Gmail、Salesforce）构建的小型、独立、高效的AI代理。
Agent / Harness	代理/束缚具。在演讲中，Justin认为这两个词的区别过于学究，可以互换使用，均指利用模型非确定性结果来完成任务的确定性软件系统。
Model Context Protocol (MCP)	模型上下文协议。最初旨在提供通用集成方案，但现实中已主要沦为代理的工具分发机制。
Inheritance / Composition	继承 / 组合。源自面向对象编程的设计原则。Justin 用来类比构建代理的两种方式：继承是堆叠技能和工具来增强一个代理，组合是用多个独立专精的代理协同工作。
Agentic Loop	代理循环。代理执行任务时的核心编排逻辑，包括思考、调用工具、观察结果、再思考的循环过程。
Durable Execution	持久化执行。一种软件工程保证，确保程序在发生故障后，能够从断点准确恢复执行，不丢失状态，对生产级代理至关重要。
Telemetry & Observability	遥测与可观测性。指对代理运行的每一步、每一轮进行数据采集和监控的能力，是诊断、调试和优化代理的基础。
Skills	技能。特指在代理语境下，作为一种向代理提供知识的 Markdown 文档。研究发现，过多技能会损害代理性能。
Hooks	钩子。理想代理架构的一个组件，用于在运行时改变上下文或触发副作用，如为没有时间感知能力的LLM注入当前时间。
Token Efficiency	Token效率。衡量代理执行任务时消耗Token数量的指标。领域特定代理通过精简上下文，在此指标上远超通用代理。
Multi-Agent Orchestration	多代理编排。指对多个独立、专业化的AI代理进行协调和管理，使其作为一个整体协同完成复杂任务。

---

延伸思考

1. 范式的可行性：Justin 提出的组合式多代理架构高度依赖于一个强大的“协调器”代理，这个协调器本身是否也会面临上下文和推理的瓶颈？如何避免协调器成为新的单点故障和性能瓶颈？
2. 代理间的通信协议：演讲中提到子代理之间用“英语”通信。这是否足够可靠？未来是否需要为多代理编排设计一种比自然语言更结构化、歧义更少的中间通信协议？
3. 开发生态的建设：Vercel 的 Eve 可能是第一个主流框架。如果要让这种范式普及，我们需要何种类型的开发者工具、调试器（用于跨多个子代理的追踪）以及代理市场的标准？
4. 经济假设的验证：Justin 声称 2026 年 Token 成本在上涨。这一趋势会持续吗？如果未来更高效的新模型或硬件使大模型推理成本暴跌，那么迁移到小型领域特定代理的主要经济驱动力是否会减弱？
5. 安全性责任的转移：虽然单个领域特定代理的能力受限会更安全，但当许多这样的代理组合成一个系统时，整体的安全边界变得更加复杂。攻击面是否从单一模型转移到了代理间的通信和编排层？

原文发表：Jun 28, 2026  ·  纪要生成：2026-06-29