作者：望宸
几乎每个月，Agent 开发工具领域都会出现新的商业产品或开源项目，但 Agent 的应用架构相对稳定。
Agent 开发工具链日新月异
模型带来了意识和自主性，但在输出结果的确定性和一致性上降低了。无论是基础大模型厂商，还是提供开发工具链和运行保障的厂家，本质都是希望提升输出的可靠性，只是不同的团队基因和行业判断，提供了不同的实现路径。以下我们按四个阶段，通过串联一些知名的开发工具，来回顾 Agent 开发工具链的演进历程。
第一阶段：基础开发框架
2022 年底，ChatGPT 的发布，让全球首次直观感受到大语言模型的通用智能潜力，但彼时 LLM 仍是孤岛智能，无法撬动广大开发者的力量来加速行业发展。
随后出现了首批 Agent 框架，如 LangChain、LlamaIndex，通过模块化的抽象，例如模型通信、ChatClient、Prompt、格式化输出、Embedding 等，来降低开发复杂度，快速构建 Chatbot、连接上下文、调用模型。
2024 年，Spring AI Aliabab 发布，提供高层次的 AI API 抽象与云原生基础设施集成方案，帮助 Java 开发者快速构建 AI 应用。未来，其将作为 AgentScope 生态的一环，定位是做好 Spring 和 AgentScope 的连接，并计划于今年 11 月底发布 AgentScope Java 版，对齐 AgentScope Python 能力。
随着行业的快速发展，各类基础开发框架也在持续演进，逐步支持或集成了检索、检索增强生成 RAG、Memory、工具、评估、可观测、AI 网关等能力，并提供了单智能体、工作流、多智能体的开发范式，以及 DeepRearch、Jmanus 这些基于框架实现的深度研究智能体和通用智能体。
虽然在研究人员看来，开发框架做的事情没有那么性感，但对于撬动广大开发者快速融入 AI 开发生态，具有不可替代的作用。
第二阶段：协作&工具
大模型虽然智能，但是缺少工具向物理世界进行延伸，它对物理世界既不可读也不可写。同时，第一阶段的应用开发框架对非程序员群体并不友好，不利于团队间协作和领域专家的参与。于是，2023 年-2024 年期间，Dify、n8n 等这些低代码甚至零代码的开发框架推向企业生产环境，通过 workflow、添加if/else 分支来定义任务的处理流程，甚至使用自然语言来生成一些简单前端页面，提升了领域专家和程序员间的协作效率。
工具层面，2023 年 6 月，OpenAI 正式推出 Function Calling。2024 年 11 月，Anthropic 发布 MCP 协议，实现跨模型工具互通。尤其是 MCP 的出现，大幅激活了开发者生态。
于是，两者共同将 Agent 开发工具链推向了第二阶段：工具&协作。
但是仅从降低构建应用的门槛，让应用能通过工具调用外部应用或系统，并没有很好的解决输出的一致性和可靠性。于是，开发者工具链的演进进入了深水区。2024年，Andrej Karpathy 提出了上下文工程，引发业界共鸣，如何挑选上下文、组织上下文、在不同任务中动态调节上下文结构，才是提升输出稳定性的关键，于是迈入了强化学习(以下简称 RL )的阶段。
第三阶段：强化学习
系统提示词、知识库、工具、记忆是上下文工程的重要构成，机制虽已成熟，但输出仍然波动，依赖 RL 把上下文工程从静态模板变成智能的动态策略。例如：
- RAG 检索排序：RL 优化文档重排策略，使上下文更贴近任务语义，减少无关噪音。
- 多轮对话记忆：RL 优化记忆的保留与遗忘策略，让对话在长期交互中保持连贯性。
- 工具调用：RL 学习调用时机与参数构造，提高工具调用的有效率与正确率。
RL 是业内难点，既依赖算法技术，又需要具备足够的领域 Know How，还会面临通用性的挑战。但其中不乏一些优先的实践。
Jina.AI 近期被 Elastic 公司收购，其 CEO 肖涵博士曾在《搜索的未来，藏在一堆小模型里》一文中分享过 Jina.AI 研发的搜索底座模型，主要包括 Embeddings、Reranker 和 Reader：
- Embeddings 是为多语言和多模态数据设计的向量化模型，将文本或图片转化成定长向量。
- Reranker 是基于 query-documents 设计的精排模型，给定一个 query 和一堆文档，直接输入模型，然后根据 query 输出文档的相关性排序。
- Reader 主要目标是使用生成式小模型 (SLM) 实现单文档上的智能，比如数据清理过滤提取等等。
以及，阿里云 API 网关基于 RL 提供了工具优选和语义检索能力，提升批量 MCP 的调用质量、降低调用耗时。以工具精选为例，通过重排序与可选的查询改写，在请求发送至大语言模型前对工具列表进行预处理和筛选，提升大规模工具集场景下的响应速度与选择精度，并降低 Token 成本。在 Salesforce 的开源数据集上，使用 50/100/200/300/400/500 个不同规模的工具集进行评测，结果表明：
- 准确性提升：经过查询改写（Query Rewrite）和工具精排（Reranker）后，工具及参数的选择准确性最高可提升 6%。
- 响应速度提升：当工具集规模超过 50 个时，响应时间（RT）有显著下降。在 500 个工具的测试场景下，响应速度最高可提升 7 倍。
- 成本降低：Token 消耗（费用）可降低 4~6 倍。
这些 RL 做得好的企业通常会把这部分实践作为商业产品的竞争力和商业收费项，因此并不像框架、工具等能让开发者快速收益。于是演进到第四阶段，基础模型厂商亲自下场做上下文工程。
第四阶段：模型中心化
2025 年 10 月，OpenAI AgentKit 和 Apps SDK，以及 Claude Skills 相继发布，标志 Agent 工程进入模型中心化时代。
- OpenAI AgentKit 和 Apps SDK：提供官方级 Agent 开发工具链，直接在模型端托管 memory、tool registry、外部应用的调用逻辑，降低开发门槛。
- Claude Skills：允许模型自身加载和管理技能（skills），用户只需提供输入，模型在内部构建上下文与能力调用链。
尤其是 Claude Skills，Skills 构建能力，MCP 连接工具，甚至不需要 MCP，Skills 执行 py 脚本直接对接 API，再由大模型生成新的 Skills。把原本开发者负责的 Agent 上下工程，转移到了框架侧，包括构建、执行和运行。
从 Claude Skills 官方的示例看，是对输出的一致性和确定性有直接帮助，尤其是协作类场景。把经验和需求，可以是 xlsx/ppt/words/代码... 最终以 skill.md 文件给到 Claude，作为上下文输入。例如，搭建一个新系统，想复用现有系统的权限体系和视觉规范，那参照官方文档，把现有系统权限设计的相关代码、视觉规范，制作成 skill.MD 文件，就可以复用，不需要重新设计和反复调试了。
Agent 应用架构相对稳定
相比 Agent 开发工具链的日新月异，映射基础设施的 Agent 应用架构，则相对稳定。
我们在《AI 原生应用架构白皮书》中分享过，AI 原生应用架构包含了模型、开发框架、提示词、RAG、记忆、工具、AI 网关、运行时、可观测、评估、安全等 11 个关键要素。以 AI 网关、运行时、可观测、评估、安全为例。
- AI 网关： 负责模型、工具的聚合和智能调度，并提供访问鉴权，和负载均衡、限流等流量治理等能力。无论开发者使用哪种工具链，最终都需要一个具备负载均衡、限流、身份认证与调用链追踪的管控中枢。
- 运行时： 提供运行环境和算力支撑，负责任务调度、状态管理、安全隔离、超时管理、并发追踪等，让 Agent 可靠、经济运行。无论是私有化部署的 Agent，还是公有云上基于多模型的混合编排，最终都要回到 GPU 资源的分配、模型推理并发、容器化隔离与调度效率上。这些能力不会因为工具层的更新而频繁重构。
- 可观测： 由于 Agent 是由多个要素（模型、工具、RAG、记忆等）动态组成的复杂系统，缺乏统一的可观测性将直接导致工程不可控。当前业界在这一层的共识较高：都需要提供端到端的日志采集和链路追踪，对应用、网关、推理引擎提供请求吞吐量、错误率和资源使用情况，确保应用稳定、安全、高效运行。其结构演化都较为稳定。
- 安全： Agent 的安全性依旧遵循云计算架构的通用逻辑，包括身份鉴权、访问控制、数据脱敏、越权防护等。尤其在多模型、多租户运行环境中，安全策略的确定性比工具链的灵活性更重要。
工具链快速迭代和创新，提升输出可靠性；网关、算力、可观测、安全这些运行时模块，则是确保应用能稳定、经济、安全地运行。正是这种"上层快变、下层稳态"的结构，保证了 AI 应用生态既能高速创新，又不会陷入系统性混乱。
下周四北京，我们将在线下分享 AI 原生应用架构的关键要素和实践，欢迎报名。
https://www.aliyun.com/activity/middleware/2025-beijing
![]()
