AI Agent代理框架与直接 API 调用的选择、构建块、工作流与代理的模式

建立有效的代理

代理与工作流的概念

什么是代理？

代理可以有多种定义。一部分客户将其视为能够独立运行、利用多种工具完成复杂任务的全自主系统；而另一部分客户则认为代理是按照预定义工作流程执行任务的系统。我们将这两种实现统称为“代理系统”，但在架构上做出区分：

• 工作流 是指通过预定义代码路径协调 LLM 与工具的组合；

• 代理 则是让 LLM 自主决定流程和工具使用，保持对任务执行过程的动态控制。

何时使用代理？

在使用 LLM 构建应用时，应首先寻找最简单的解决方案，只有在必要时才增加复杂性。对于大部分应用来说，利用检索和上下文示例优化单次 LLM 调用即可满足需求；但当任务需要灵活性和模型驱动的决策时，代理系统则能更好地发挥作用。需要注意的是，代理系统往往以牺牲响应延迟和增加成本为代价，从而换取更优的任务表现。

---

框架与直接 API 调用的选择

市面上已有许多框架能简化代理系统的实现，例如：

• LangChain 的 LangGraph

• Amazon Bedrock 的 AI Agent 框架

• Rivet（拖拽式 GUI 工作流构建器）

• Vellum（另一款用于构建和测试复杂工作流程的 GUI 工具）

这些框架可以让开发者快速上手，简化诸如调用 LLM、定义和解析工具、链接调用等低级任务。但它们通常会增加额外的抽象层，可能掩盖底层提示和响应的细节，增加调试难度。因此，我们建议开发者优先直接调用 LLM API，并确保对底层代码有足够了解，以避免因错误假设而产生问题。

---

构建块、工作流与代理的模式

在实际应用中，我们总结出了一系列常见模式，从基础构建块到复杂的多步代理系统，帮助开发者根据实际需求进行组合和定制。

1. 增强型 LLM —— 基础构建块

代理系统的核心是对 LLM 进行增强，使其具备检索、调用工具和记忆等能力。这些增强功能可使模型主动生成搜索查询、选择适合的工具以及决定保留哪些信息。实现时需要根据具体用例进行定制，同时提供简洁、文档完善的接口。我们推荐使用最新的模型上下文协议，通过简单的客户端实现与第三方工具生态系统的集成。

2. 工作流模式

针对任务需求的不同，可采用以下工作流模式：

（1）提示链工作流

将任务分解为一系列子任务，每次调用 LLM 处理前一步输出。可在各步骤中加入程序性检查，确保整体流程有序。适用于任务可拆分为固定步骤的场景，如生成营销文案后再进行翻译，或撰写文档大纲后检查其是否符合要求。

（2）路由工作流

通过对输入进行分类，将不同类型的任务指向专门的后续处理流程。该模式适合处理复杂任务中存在不同类别的问题，例如将客户服务查询（常规问题、退款请求、技术支持）分别导入不同的处理路径，或针对简单问题和复杂问题分别调用不同能力的模型，以优化成本和速度。

（3）并行化工作流

允许多个 LLM 实例同时处理任务，并将输出进行程序化整合。其常见变体包括：

• 分段：将任务拆分为独立子任务并行执行，如一个实例处理用户查询，另一个实例负责内容筛查；

• 投票：对同一任务多次调用模型以获得多样输出，例如代码漏洞检测或内容不当性的多重评估。

（4）Orchestrator-workers 工作流

采用中心 LLM 动态分解任务，并将各子任务委派给多个工作 LLM，再综合各自结果。这种模式适合于难以预定义子任务数量或内容的复杂任务，如大规模代码修改或多来源信息搜索。

（5）评估器-优化器工作流

通过一个 LLM 生成初步响应，另一个 LLM 进行评价并反馈，形成迭代循环。此模式适用于具有明确评价标准的任务，如文学翻译中的细微差别处理或复杂搜索任务的多轮改进。

3. 代理系统的高级应用

随着 LLM 在理解复杂输入、推理规划、可靠使用工具以及错误恢复方面能力的提升，代理逐步走向自主。代理系统通常从与用户的命令或互动讨论开始，一旦任务明确后，便能独立规划和执行，并在必要时向用户寻求反馈。自主代理适用于无法预知任务步数且难以硬编码固定路径的开放性问题，但其自主性也意味着更高成本和潜在的复合错误风险。因此，建议在受控环境中充分测试，并设置合理的停止条件（如最大迭代次数）。

例如，代理可以在编码领域用于处理涉及多文件修改的任务，或在客户支持中结合聊天机器人界面与工具集成，自动提取客户数据、订单历史以及知识库信息，实现退款、更新工单等操作。同时，成功的代理系统往往要求每一步都获取环境反馈（如工具调用结果或代码执行反馈），以确保进度符合预期。

---

综合与定制：构建适合自己需求的系统

上述构建块和工作流模式并非硬性规定，开发者可以根据实际场景灵活组合。关键在于不断衡量系统性能，通过迭代优化仅在简单方案不足以满足需求时再增加复杂性。我们总结出三条核心原则：

• 保持简单：代理设计应尽量简洁；

• 确保透明：明确展示代理的规划和决策步骤；

• 精心设计接口：通过详尽的工具文档和充分测试，构建高效的代理–计算机交互接口（ACI）。

虽然各类框架可以帮助开发者快速启动项目，但在进入生产环境时，不妨降低抽象层次，采用基本组件构建更可靠、易维护的系统。

---

附录

附录 1：实践中的代理应用

我们的客户实践表明，AI 代理在以下两个领域具有显著价值：

• 客户支持 利用聊天机器人界面和工具集成，实现对客户数据、订单历史和知识库的调取；自动处理退款、工单更新等操作；支持交互流程清晰、成功标准明确，并可通过按成功解决计费的模式降低风险。

• 编码代理 在软件开发中，代理不仅能自动生成代码解决方案，还可利用自动化测试进行验证和反馈。比如在 SWE-bench Verified 基准中，代理能仅凭拉取请求描述处理 GitHub 问题，但最终仍需人工审核以确保整体系统要求得到满足。

附录 2：Prompt 工程与工具设计

无论构建何种代理系统，工具都是不可或缺的一部分。良好的工具定义应与整体提示设计同等重视，建议注意以下几点：

• 为模型提供足够的“思考”时间，避免陷入困境；

• 保持工具格式与模型在互联网上自然遇到的格式一致，避免额外格式化开销（如大量代码行计数或字符串转义）；

• 工具文档应详细描述示例用法、边界条件、输入格式要求和与其他工具的区别，类似于为团队初级开发人员编写优秀的文档字符串；

• 反复测试模型对工具的使用情况，优化参数和接口设计，确保工具尽量防错。

在为 SWE-bench 构建代理时，花费大量精力优化工具设计，例如将相对文件路径改为绝对路径，从而确保模型调用时不出错。