夜雨聆风摘要：当 Anthropic 一次性发布 10 套面向金融行业的 Agent 模板，每一套都封装了领域知识、数据源连接和子 Agent 编排逻辑时，Agent 开发的模式正在发生根本变化。这不是简单的"多了几个示例"，而是从"给你框架你自己搭"到"给你架构蓝图你来做定制"的转变。对 AI 应用架构师来说，这意味着需要重新思考：在 Agent 开发中，什么应该自己构建，什么应该直接采用。
做 Agent 应用的团队大概都有类似的体验：项目启动的头两周最有干劲，因为框架选型、基础架构搭建、第一个 Demo 跑通——这些环节都能带来明显的进展感。但进入具体业务场景后，画风就变了。每个业务场景都需要写领域指令、接不同的数据源、设计子任务拆分策略、处理边界情况。做完一个场景，下一个场景又要重来一遍。
过去半年里，随着 Claude Managed Agents、OpenAI Agents SDK、LangGraph、AutoGen 等框架的成熟，"用框架搭 Agent"已经不是瓶颈。真正的瓶颈变成了：搭起来之后，怎么让它真正解决某个领域的问题。
Anthropic 上周发布的金融行业 Agent 模板，提供了一个新的思路。这不是十段示例代码，而是十套可部署的参考架构。每套模板都包含明确的技能定义（Skills）、数据连接器（Connectors）和子 Agent 编排方案（Subagents），覆盖了从投行 pitchbook 制作到 KYC 合规审查的完整金融业务场景。
Agent 开发的三个层次
理解这次变化的深度，需要先拆解当前 Agent 开发的三个层次。
第一层是模型能力。模型本身能不能理解复杂指令、能不能正确调用工具、能不能在长上下文中保持一致性。这一层由模型提供商负责，开发团队只需要选择合适的模型和参数。
第二层是框架能力。Agent 运行时能不能管理对话状态、能不能并发执行工具调用、能不能处理错误和重试。这一层由 LangGraph、OpenAI Agents SDK 等框架覆盖，开发团队需要理解框架的抽象模型，但不需要重复实现运行时基础设施。
第三层是领域能力。Agent 知不知道这个业务领域的专有术语？知不知道从哪里获取权威数据？知不知道哪些步骤可以并行、哪些必须串行？在遇到不确定的情况时，应该坚持还是应该上报？这一层，框架帮不了你。
过去一年里，前两层已经快速成熟。模型越来越强，框架越来越完善。但第三层——领域能力——仍然需要每个团队从零开始构建。这也是为什么很多 Agent 项目在 POC 阶段表现惊艳，进入生产后却推进缓慢：领域知识的注入和验证，本质上是一个知识工程问题，不是模型或框架能自动解决的。
Anthropic 的 Agent 模板方案，正是在第三层上给出了一个系统化的回答。
模板的三层结构
每一套金融 Agent 模板都包含三个组成部分，这三个部分恰好对应了领域 Agent 的三个核心维度。
技能（Skills）是模板的"大脑"。它包含了完成特定任务所需的指令集和领域知识。以 Pitch Builder（投标书制作）模板为例，它的技能层包含如何筛选可比公司、如何运行估值模型、如何组织 pitchbook 的章节结构——这些都是投行分析师的领域知识，不是通用模型能力。技能的编写形式是结构化提示词和决策规则，可以被审查、修改和版本管理。
连接器（Connectors）是模板的"感官"。它们为 Agent 提供受控的数据访问通道。金融行业的 Agent 需要访问 FactSet 的市场数据、S&P Capital IQ 的财务数据、MSCI 的风险因子、PitchBook 的私募交易记录等。每个连接器都封装了认证、权限范围和数据格式转换逻辑。更重要的是，这些连接器是"受控的"——它们遵守企业定义的数据访问策略，不会因为 Agent 的某个工具调用而泄露超出范围的数据。
子 Agent（Subagents）是模板的"双手"。不是所有任务都需要主 Agent 亲自处理。在 Pitch Builder 中，可比公司选择和估值方法校验可以委托给专门的子 Agent 执行，主 Agent 负责整合结果并进行判断。这种分工不是性能优化，而是架构设计：子 Agent 可以专注于单一任务，减少上下文污染，同时也便于独立测试和替换。
这三个层次合在一起，构成了一套完整的"Agent 参考架构"。它不是一段你需要在 README 里找用法说明的示例代码，而是一个可以直接部署、按需定制的架构蓝图。
从示例代码到参考架构
要理解为什么这件事重要，需要区分"示例代码"和"参考架构"。
示例代码解决的是"怎么用"的问题。它告诉你 SDK 的某个方法怎么调用、参数怎么传、返回值怎么处理。它的价值在于降低上手门槛，但它的适用范围局限在框架层面。你把示例代码里的 API key 换成自己的，跑通了，但你的 Agent 并不会因此就理解你的业务。
参考架构解决的是"怎么设计"的问题。它告诉你一个特定领域的 Agent 应该由哪些组件构成、这些组件之间如何通信、数据如何在它们之间流转、边界情况如何处理。它的价值在于提供经过验证的设计决策，让你不需要从零开始做架构选型。
这两者的区别，类似于"一个 Express.js 路由示例"和"一个电商后端架构图"的区别。前者告诉你如何注册路由和中间件，后者告诉你为什么需要分离订单服务和支付服务、如何设计库存一致性方案、缓存在哪里失效。
Anthropic 的金融 Agent 模板，做的是后者。它提供了针对特定金融业务的架构设计决策，开发团队的工作从"如何设计这个 Agent"变成了"如何定制这套架构"。
对 AI 应用架构师的意义
这件事对 AI 应用架构师有三个层面的启示。
第一，领域 Agent 的构建正在从"手工作坊"走向"预制构件"。
过去你做一个客服 Agent，要从定义工具函数开始。现在，如果场景匹配，你可能只需要从一套模板出发，替换数据源配置和业务规则。这并不意味着架构师的工作变少了——恰恰相反，工作内容从"实现 Agent"变成了"选择和组合 Agent 模板"。这要求架构师能够评估不同模板的适用边界、理解模板内部的架构取舍、以及设计模板之间的协作方式。
第二，Agent 的治理和可观测性需要成为模板的一等公民。
注意这些模板中包含的连接器——它们不仅仅是"数据通道"，它们是"受控的数据通道"。权限范围、审计日志、数据使用策略，这些治理能力被直接内置在模板架构中，而不是作为事后补充。对于要在生产环境中运行的 Agent 来说，治理和可观测性不是可选项。任何 Agent 参考架构，如果缺少了这两个维度，本质上只是一个 Demo。
第三，"技能"正在成为 Agent 架构中的独立资产。
当技能被写成结构化提示词和决策规则，而不是嵌入在代码逻辑中时，它就变成了一个可以独立于 Agent 运行时进行开发、测试和版本管理的资产。这意味着一个团队可以专门负责"技能工程"——写领域知识，而不需要关心底层框架的实现细节。类似的概念在 Pydantic AI 的 Agent 定义、OpenAI Agents SDK 的 instructions 参数中都有体现，但 Anthropic 的模板让这个概念进入了生产级实践的层面。
如何在自己的领域复用这种模式
即使你的业务不在金融行业，这套思路也是可以复用的。构建领域 Agent 参考架构的步骤大致如下：
第一步，识别领域中的高频任务。不是所有业务场景都需要 Agent 化，优先选择那些规则相对明确、数据源相对固定、输出格式相对标准的任务。在金融行业中，pitchbook 制作、KYC 审查、月末结账都属于这类任务。
第二步，拆解任务为"技能+数据+子任务"三个维度。技能层收集该任务的领域知识和操作规则；数据层梳理需要的所有数据源及其访问方式；子任务层识别哪些步骤可以独立执行，哪些需要主 Agent 的上下文判断。
第三步，为每个数据源建立受控连接器。不要等到 Agent 已经在生产环境中运行了再来考虑数据访问权限。在模板阶段就把每个连接器的权限范围定义清楚，这是避免后续治理事故的最有效手段。
第四步，为子 Agent 设计清晰的接口契约。主 Agent 和子 Agent 之间通过什么协议通信？子 Agent 的结果如何被主 Agent 校验？子 Agent 失败时，主 Agent 是重试、降级还是上报？这些决策应该在模板中明确，而不是在运行时才考虑。
第五步，建立技能的生命周期管理流程。领域知识会过时、监管要求会变化、业务规则会调整。技能需要像代码一样被版本管理、测试和部署。一个没有版本管理的技能，和一个没有测试的 API 一样危险。
架构的下一个演进方向
从框架到模板的转移，本质上是 Agent 开发从"基础设施层"向"应用层"的演进。框架解决的是"Agent 怎么运行"，模板解决的是"Agent 应该做什么"。
可以预见，接下来会有更多行业出现类似的 Agent 参考架构。医疗行业的病历摘要 Agent、法律行业的合同审查 Agent、制造业的设备维护 Agent——每个领域都有自己独特的知识体系、数据源和工作流程，这些都可以被封装为可复用的模板。
对于正在构建 Agent 应用的团队来说，现在值得做的不是等待模板出现，而是开始在自己的团队内部建立"技能工程"的能力。把领域知识从工程师的脑子里搬到结构化的技能定义中，把数据源连接从一次性脚本升级为受控的连接器，把子任务编排从临时的手动调度变成可复用的子 Agent 设计——这些投入在短期内会增加开发成本，但它们是 Agent 应用从 Demo 走向生产的关键保障。
#AI应用架构 #Agent应用架构 #Agent应用开发 #企业架构 #Anthropic
