Skip to main content

从"模型调用"到"Agent As a Service"

AI平台能力的再定义​

  • 1.0 时代: 平台提供模型调用能力 + 快速使用模型的基础服务
    • 举例： Chat Completions 接口集成全部模型调用 + WorkFlow提供便捷的模型调用方式
    • 用户痛点：
      • 大模型实际完成工作，依赖各种工具，需要挂载各种function call，开发function call的成本很高，且存在大量重复造轮子的情况
      • 大模型训练时的数据无法涵盖所有知识，很多场景需要外挂私有知识库
      • 大模型训练后产生的最新知识，同样需要用户提供
      • 对于有记忆的应用，需要自己实现上下文管理
      • 对于多模态场景，单一的Chat Completions接口，不足以满足需求
    • 1.0时代的解决方案：
      • 工具集市：通过工具共享的方式，期望减少工具的重复开发成本
      • RAG：通过将RAG作为工具调用的方式，实现外挂私有知识库
      • Assistants API：第一代的智能体平台能力，提供了上下文管理，以及很多内置工具的调用
      • 提供了多种语音、图像能力应对多模态场景
    • 解决方案的问题：
      • 开发者很难做出优质通用的工具，提供给多数开发者使用
      • 哪怕存在优质通用工具，也很难被发现，存在平台运营问题
      • 用户使用RAG存在理解成本以及多个系统接入的成本
      • Assistants API的内置工具与上下文管理功能互相耦合，不能使用单一能力，有状态的中心服务存在更多性能上的瓶颈
      • Assistants API的概念过多，使用步骤复杂
      • 多模态场景需要接入多个API，来完成工作
  • 2.0 时代： 平台抽象并管理了更多工程上的“脏活累活”：会话状态、RAG流程、工具编排，并且在能力迭代升级上进行更多尝试，以达到让AI成为你更强大的助手的核心目的
    • 用户痛点的再衡量：
      • 普遍需求：需要外挂私有知识库和无法获取实时知识，是使用大模型存在的普遍痛点，是由模型能力的天然不足所导致的
      • 个性化需求：完成某项特定任务所需的特定工具开发无法完全避免，但是对工具的调用只需要统一协议，即可在服务端完成
      • 用户可以自行选择是否启用上下文管理
      • 可以在单一接口上提供更多的多模态能力，减少用户使用的复杂性
    • 针对性的解决方案：
      • 核心补丁：提供文件检索的能力，支持文件输入
      • 接口集成AI网络搜索的能力，针对需要使用最新知识进行调研等场景
      • 集成MCP协议，用户实现MCP Server后，MCP Client可由平台托管
      • 用户可以在接口调用时，指定参数控制是否使用平台能力提供的上下文管理
      • 扩展语音输入以及图像生成的能力，使用多模态能力更方便
    • 能力的再升级(Beta)：
      • 可以尝试让模型自主创建一部分简单的工具，来实现某个任务
      • 尝试让模型自主操控电脑来完成复杂任务
    • 2.0 时代的愿景：
      • 更加标准化的AI使用方式，避免因为用户使用方式造成AI应用能力体验上的差异
      • 更快速地搭建应用，让使用AI的理解成本更低，需要做的工作更少
      • 覆盖更大的使用场景，让AI应用的开发可以专注于业务逻辑的实现，而非工程链路的搭建
      • 尝试性地让模型更独立地完成任务，减少人工编排

初识核心功能​

推荐阅读：为什么选择Responses API?

  • 丰富的多模态输入/输出

  • 强大的内置工具

  • 支持 有状态和无状态双模式

深度分析能力定位​

对于Responses API，我们可以将其分为：Stateless Responses API 和 Stateful Responses API。因为两者在应用定位上存在显著区别。

  • Stateless Responses API：对于无状态API无须多言，这是对Chat Completions接口的水平扩展，让用户更快速、更方便、更标准地使用AI。其价值也显而易见，只要需要外挂私域知识，那么对比使用Chat Completions接口，可以减少大量的学习成本和开发成本。

  • Stateful Responses API：有状态的API，相当于提供了通用智能体能力。

    • Stateful API + 知识库（私域知识需求）+ MCP Server（自定义工具调用）= 智能体
      • 极大简化了搭建智能体的工作，只需要维护自己的知识库，并在有特定的工具调用需求时提供对应的MCP Server
      • 一个API调用即可实现一个智能体服务，是真正意义上的“Agent As a Service”
    • 对通用智能体质疑：
      • Q：通用智能体的能力在垂直领域上，能和专业智能体相比吗？
        • A: 在单一垂直领域的能力天花板上，一个深度定制的垂直智能体永远是赢家。
        • 但是，平台的价值不在于“单一任务的极致能力”，而在于“规模化交付的效率”。
        • 类比： 定制的服务器 vs. 云厂商的统一云服务。当然自己服务器可以根据自己的服务采取最个性化的定制和优化，跑出最极致的性能，但目前多数公司都选择云服务，因为大部分场景所要的是低成本、快速、稳定、弹性的能力，而不是极致的硬件性能。
      • Q: 通用智能体的意义是什么？
        • 1. 赋能“长尾需求”： 公司的核心业务值得花费大量精力去打造一个业内领先水平的垂直智能体。但是更多存在的是“长尾”AI需求，比如很多内部工具、客服助手、文档问答...这类任务实现完全智能化，可以帮助我们节省工作上的大量边缘任务开销，聚焦核心问题
        • 2. 统一“AI基础设施”： 把智能体的核心组件（上下文管理、RAG、工具调用）变成了平台级服务。这对工程团队意味着：更少的维护、统一的SLA、统一的监控。
        • 3. 充当“孵化器”： 所有的垂直智能体在被证明价值巨大之前，可以先用Stateful API快速搭建MVP，快速落地。当它的价值被验证，且平台能力触顶时（不仅仅是效果上的能力，也包括稳定性、资源、性能等），再投入资源去“建设”。

  • 何时使用Responses API？

    • 核心思想：
      • 任何“需要Chat Completions能力，且需要挂载知识库或需要使用Responses API集成的工具、多模态能力”的场景，都适合使用Stateless Responses API
      • 任何“不需要做到业内最优解决方案，但需要快速上线、快速验证、快速使用”的场景，都应该优先使用Stateful Responses API
      • 通用智能体的意义可能不在于取代所有智能体，或许它可以作为辅助Agent开发者进行创作的万能助手，在此基础上探索出特定领域更优秀的智能体解决方案
    • 推荐阅读：我的Agent服务是否应该使用Responses API？

探索应用场景​

由于 Stateless Responses API 本质上是Chat Completions的增强，可以水平迁移。因此应用场景的介绍只针对Stateful Responses API。

  • 场景一：内部提效

    • 场景： 内部工具、企业知识库。
    • 案例1： 新员工入职助手。对接各种公司政策制度、基础设施平台手册、各团队自己的文档。新员工不需要打扰任何人，直接向AI提问。
    • 案例2： 技术文档/代码库问答。对接服务文档，工程师直接问“XX服务的XX接口怎么用？”，无需人工解答。
    • 价值： 这些场景对“智能”的天花板要求不高，但对“有状态”（解答不清晰时的多轮询问）和“私有知识库”是刚需。且此类场景可以减少工作中大量问答类工作的消耗。

  • 场景二：任务自动化

    • 场景： 连接内部、外部系统，自动完成多步任务。
    • 案例1： 运营助手。在群里@机器人：“帮我写一篇关于XX的推文，风格活泼一点，发到小红书”。
    • 案例2： 异常分析。根据服务调用异常，分析可能的原因，并在群里@对应的工程师。
    • 价值： 这类场景通常是我们的工作任务，可以分担给AI完成。对比场景一，需要自定义工具的参与，对特定场景实现相应的MCP Server即可实现。而这类MCP Server的功能也是可泛化的，比如小红书发布、代码拉取、工作群@成员，可以一次搭建，多处应用。

  • 场景三：快速原型验证

    • 场景： 快速落地应用、快速验证想法
    • 价值： 传统的智能体应用落地，速度慢，成本高。在立项初期只能探讨其理论逻辑上的可行性。而用Stateful API + 知识库，短时间搭个Demo，可以帮助我们基于事实分析。我们可以借此快速落地一个应用，如果效果好，再立项投入资源做“垂直智能体”。

展望AI能力平台的未来​

  • 2.0 时代依然存在的痛点：
    • 私有知识库的维护是一项极其繁重的工作，需要随时更新，长此以往，运营成本较高
    • 集成MCP协议只是让工具调用变得更方便，MCP Server依然需要开发，并没有解决“1.0时代”工具集市的全部问题
    • 请求携带大量MCP工具或者Function Call时，会占用请求上下文，每次请求都携带会浪费token，且可能会影响模型推理结果
    • LocalShellTool需要客户端支持，工具的自动生成更偏向于实验性的探索，还无法在没有用户提供工具时，完成一项相对复杂的任务
    • 缺乏长期记忆的可靠解决方案，暂时无法达到越使用越聪明的效果
  • 对3.0时代平台能力的展望：
    • 提供更智能化的知识管理能力：提供高度自动化的发现知识，更新知识、变更审核、知识版本管理的全流程SOP方案，并且提供可视化的知识操作记录
    • 让AI拥有一台真正的PC：我们发现想要AI真正解决复杂任务，需要为AI准备一套真正的可执行系统，这可以让AI更像一个人在工作，自主地使用“电脑”解决复杂任务
    • 充分挖掘AI自主创造工具的能力：深度探索如何更好地引导AI创建工具，来解决复杂任务。哪怕不能完全由AI自主决策完成，也会尽量让“3.0时代”的用户创建工具更简单，比如只需要一个指令或一段描述
    • 用的越多越智能：相信以上能力会让AI平台更具生产力，在此基础上，我们将持续探索如何真正做到“用得越多越智能”
  • 总结：
    • 目前的“2.0时代”更多的还是能力上的集成，更像是“1.0时代”到“智能化”的过渡，核心价值是让AI能力的调用更便捷更收敛更规范
    • “3.0时代”已在进行中，我们对“3.0AI平台能力”的定位是一个真正的“私人智能助手平台”，而不仅仅是“AI能力平台”