LLM 智能体 (Agent) 开发手册：工作流模式、框架选型与实战案例详解

最新推荐文章于 2025-08-12 21:32:39 发布

原创最新推荐文章于 2025-08-12 21:32:39 发布 · 1k 阅读

18 ·

CC 4.0 BY-SA版权

文章标签：

#运维 #人工智能 #transformer #大数据 #产品经理 #大模型 #自然语言处理

1 、Agent的核心定义与区分

1.1 什么是Agent？

Agent的概念具有多义性：有人将其定义为能长期自主运行、灵活调用各类工具处理复杂任务的系统；也有人用它指代固定的预定义工作流。Anthropic将这些形态统称为类Agent系统，并对其中的工作流（Workflow） 和智能体（Agent） 作出明确区分。

1.2 工作流与智能体的核心差异

对比维度	工作流（Workflow）	智能体（Agent）
定义	按预定义流程协调LLM与工具的系统	由LLM动态决定处理流程和工具使用的系统
适用场景	步骤可预测、可明确定义的问题	无法预先规划解决步骤的开放性问题
优势	稳定、准确，结果可预测	能应对无固定流程的复杂开放问题
劣势	为保证准确性可能增加解决延迟	成本较高，问题解决成功率仍有提升空间

Anthropic在附录1的“Agent实战”中，详细介绍了客户实践中发现的两类高价值应用场景，为类Agent系统的落地提供了参考。

2 、类Agent系统的适用场景

2.1 基于简单性原则的场景评估

Anthropic强调：构建LLM应用时，应优先选择最简单的解决方案，仅在必要时增加系统复杂性。

关键权衡

类Agent系统通常以更高的延迟和成本为代价换取性能提升，因此需谨慎评估这种取舍是否值得。

复杂性选择的核心原则

选工作流：任务步骤明确，需保证结果的可预测性和一致性；
选Agent：任务需灵活应对变化，依赖模型动态决策。

重要提示

对多数应用而言，优化单个LLM调用（如结合检索增强和上下文示例）已能满足需求，无需过早引入类Agent系统。

3、 Agent框架的合理使用

3.1 框架使用的潜在风险

开发框架虽能简化搭建流程，但常存在过度抽象问题，导致底层提示词和LLM调用逻辑被隐藏，引发两大风险：

基于框架开发的Agent系统难以有效调试；
简化的搭建流程可能让开发者不自觉地增加系统复杂性。

3.2 实用开发建议

Anthropic推荐渐进式开发方法：

优先直接调用LLM API：多数功能模式只需几行代码即可实现；
深入理解框架底层逻辑：若使用框架，必须清楚其内部的LLM调用和提示词设计；
避免对框架的错误假设：对底层原理的误解是项目失败的常见原因。

“我们建议开发者直接使用LLM API：许多模式可以用几行代码实现。如果你使用框架，请确保理解底层代码。对底层工作的错误假设是客户错误的常见来源。”

可参考Anthropic的cookbook获取示例实现。

https://github.com/anthropics/anthropic-cookbook/tree/main/patterns/agents

4 、类Agent系统的设计模式

类Agent系统的设计模式从基础到复杂可分为多个层级，从增强型LLM逐步扩展到自主Agent。以下为生产环境中常见的模式解析。

4.1 增强型LLM模式

定义：增强型LLM是类Agent系统的基础模块，具备检索、工具使用、记忆等扩展功能。当前Anthropic的模型已能主动生成搜索查询、选择合适工具，并判断需记忆的信息。

请添加图片描述

工程实现要点：

针对具体场景定制增强能力（如专注检索或工具调用）；
为LLM提供简洁、文档清晰的工具接口。

实现增强功能的推荐方式是采用Anthropic发布的模型上下文协议（MCP，https://www.anthropic.com/news/model-context-protocol），该协议支持开发者通过简单客户端集成第三方工具生态。

4.2 工作流模式

4.2.1 提示链

定义：提示链将任务拆解为有序步骤，每个步骤的LLM调用处理上一步的输出，还可在中间添加“门控”检查确保流程不偏离预设轨道。

请添加图片描述

适用场景：

任务可清晰拆分为固定子任务；
需通过牺牲一定延迟换取更高准确性（让每个LLM调用处理更简单的子任务）。

应用示例：

生成产品描述后，自动翻译为多语言并适配不同地区文化；
撰写报告时，先生成大纲→检查大纲合规性→基于大纲扩展内容。

4.2.2 路由

定义：路由工作流先对输入进行分类，再将其引导至专门的后续任务。这种模式实现了关注点分离，可针对不同类别输入优化提示词，避免单一提示词在多场景下的性能妥协。

请添加图片描述

适用场景：

复杂任务包含明显不同的子类别，需差异化处理；
分类可通过LLM或传统算法准确完成。

应用示例：

客服系统将查询分为账单咨询、技术支持、退款请求，分别对接不同的处理流程；
按问题复杂度路由：简单问题用轻量模型（如Claude 3.5 Haiku），复杂问题用高性能模型（如Claude 3.5 Sonnet），平衡成本与速度。

4.2.3 并行化

定义：并行化工作流让LLM同时处理多个任务，再通过程序聚合结果，主要分为两种形式：

任务拆分（Sectioning）：将任务拆分为独立子任务并行处理；
投票（Voting）：多次运行同一任务获取多结果，通过投票提升可靠性。

适用场景：

子任务并行处理可提升效率；
需要多视角验证结果（如内容审核）；
复杂任务涉及多维度考量，独立处理各维度效果更佳。

应用示例：

任务拆分：生成营销内容时，同时调用“标题生成”“正文撰写”“关键词优化”三个并行分支，最后整合结果；
投票：金融报告审核中，多个LLM分支分别检查数据准确性、合规性、逻辑连贯性，通过多数一致原则确定最终结果。

4.2.4 编排者-工作者

定义：编排者（LLM）动态分解任务，委派给多个工作者（LLM）执行，最后综合结果。与并行化的核心区别是：子任务非预定义，而是由编排者根据输入动态确定。

请添加图片描述

适用场景：

任务复杂且子步骤不可预测；
需要多角色协作处理不同维度的子问题。

应用示例：

市场调研任务：编排者确定需分析的竞品维度，委派工作者分别负责价格、功能、用户评价调研，最后汇总成报告；
法律案例分析：编排者拆分“案例检索”“条款解读”“判决趋势分析”等子任务，由专业领域的工作者完成后整合。

4.2.5 评估-优化

定义：一个LLM生成初始响应，另一个LLM在循环中提供评估反馈，驱动前者迭代优化，直至达到预设标准。

请添加图片描述

适用场景：

有明确的评估标准（如翻译准确性、文案吸引力）；
迭代优化能显著提升输出质量（人类或LLM的反馈能有效指导改进）。

应用示例：

简历优化：生成初始简历→评估与岗位匹配度→针对性修改关键词和经历描述→循环至达标；
代码生成：生成代码→评估性能和可读性→优化逻辑和注释→通过自动化测试后终止。

4.3 完整Agent模式

4.3.1 Agent的核心设计要点

随着LLM在复杂输入理解、推理规划、工具使用等能力上的成熟，完整Agent已逐步应用于生产环境。其典型工作流为：

启动：接收用户指令或通过交互明确任务目标；
规划：自主制定操作步骤，必要时向人类请求补充信息；
感知：每步执行中从环境（如工具调用结果）获取“基础事实”，评估进展；
反馈：遇障碍或到达检查点时，可暂停等待人类反馈；
终止：完成任务后终止，或因达到最大迭代次数等停止条件结束。

“智能体虽能处理复杂任务，但其实现本质上是‘在循环中基于环境反馈使用工具的LLM’。因此，设计清晰的工具集及文档至关重要。”

工具集质量直接影响Agent的成功率和效率，具体体现在：

Agent对工具的选择与调用顺序的合理性；
参数填写的准确性；
对工具结果的利用效率。

请添加图片描述

4.3.2何时使用完整Agent？

Agent适用于开放性问题，这类问题的特点是：

解决步骤数量不可预测；
无法通过固定代码路径实现。

需注意，Agent的自主性可能带来更高成本和错误累积风险，部署前需在沙盒环境充分测试，并设置保护机制（如最大调用次数限制）。

应用示例：

自动化数据分析Agent：根据用户需求自主决定数据源、分析方法和可视化方式；
科研助手Agent：动态调整文献检索策略，整合多源研究结果并生成综述。

4.4 模式的组合与定制

类Agent系统的设计模式是灵活的构建块，可根据需求组合使用。成功的实现往往采用简单可组合的模式，而非复杂框架。

4.4.1 组合原则

模式可自由组合，而非绑定于固定框架；
通过量化评估确定最佳组合（如对比不同组合的成本、准确率）；
仅在能显著提升效果时，才增加组合的复杂性。

4.4.2 高效组合示例

提示链+路由：先分类任务，再用专用提示链处理（如客服系统先区分问题类型，再调用对应领域的解决链）；
编排者-工作者+评估-优化：编排者拆分任务，工作者执行，评估者检查结果并驱动优化（如内容创作中，编排者确定章节，工作者撰写，评估者优化文风）；
混合Agent：不同任务阶段使用最适配的模式（如智能助手先路由分类查询，简单问题用提示链，复杂问题启动编排者-工作者模式）。

5、实践指南

5.1 核心开发理念

“在LLM应用领域，最成功的系统并非最复杂的，而是最适配需求的。”开发应从简单提示词起步，通过测试评估效果，仅在简单方案不足时，逐步引入类Agent系统的组件。

5.2 Agent开发的三大原则

简单性：仅在能明显改善结果时增加复杂性；
透明性：清晰展示Agent的规划步骤，增强用户信任；
工具接口设计：通过详细文档和测试，打造友好的Agent-计算机接口（ACI）。

框架可用于快速原型开发，但生产环境中应减少抽象层级，直接基于基础组件构建，以保证可维护性和可控性。

6、附录1：Agent实战落地

6.1 智能体的价值与应用条件

基于客户实践，AI智能体在同时满足以下条件的任务中能创造最大价值：

需结合对话交互与实际行动（如客服中“回答问题+处理退款”）；
有明确的成功指标（如问题解决率、任务完成时间）；
能形成有效反馈循环（如工具调用结果指导下一步行动）；
整合合理的人类监督机制（如关键决策需人工确认）。

6.2 成功案例解析

案例一：智能客服Agent

核心价值：自然对话能力与工具集成（客户数据、订单系统）结合，实现“咨询-解决”闭环；
成效：某零售企业引入后，客户问题解决率提升40%，人工转接率下降55%，采用“成功解决才收费”的模式验证了商业价值。

案例二：代码开发Agent

核心优势：输出可通过自动化测试验证，反馈驱动迭代（如测试报错后自动修改代码）；
成果：在SWE-bench Verified基准测试中，能基于需求描述修改多文件代码，解决真实GitHub问题，人类审查主要负责确保符合系统整体要求。

6.3 落地实施要点

明确任务边界：定义Agent的职责范围和权限（如不可执行的操作）；
工具集适配：提供Agent所需的全部工具，并优化文档说明；
反馈机制：确保Agent能获取执行结果并用于改进；
监督节点：在高风险步骤（如资金操作）设置人工审核；
量化指标：通过解决率、耗时、成本等指标评估效果。

7、附录2：工具提示工程

7.1 定义

工具提示工程指：像设计提示词一样优化工具定义，使LLM能清晰理解工具的用途、使用方法和结果含义。

7.2 核心原则

清晰性：用精确术语描述功能、参数要求、输出结构及使用限制；
简洁性：避免冗余信息，采用结构化格式（如列表、表格）提升可读性，聚焦核心用途。

7.3 工具形式设计指南

同一功能可采用不同实现方式，选择的核心标准是：LLM的使用准确性和难易度（是否符合模型的“使用习惯”）。

常见操作的实现方式对比

操作类型	可选形式	模型使用难度
文件编辑	diff格式 vs 整文件重写	diff需计算行数，难度更高
结构化输出	Markdown代码块 vs JSON	JSON需处理引号转义，难度更高

格式选择三原则

节省token：压缩工具描述的token消耗，为模型思考预留空间；
贴近自然语料：优先选择互联网文本中常见的格式（如Markdown）；
降低格式负担：避免需要精确计数或复杂转义的格式（如长文本的行数统计）。

7.4 Agent-计算机接口（ACI）优化

如同人机接口（HCI）设计的重要性，ACI设计直接影响Agent的效率：

从模型视角评估工具的直观性（人类觉得复杂的工具，模型也可能难以使用）；
完善文档：包含使用示例、边界情况、输入格式及与其他工具的界限；
优化命名：参数名称需清晰易懂（如同为初级开发者写文档）；
实证迭代：通过多样化输入观察模型使用模式，针对性优化工具设计。

实战经验：Anthropic在开发SWE-bench Agent时，发现智能体离开根目录后易因相对路径出错，通过强制使用绝对路径，完美解决了文件操作问题。正如团队所述：“为SWE-bench构建Agent时，我们花在工具优化上的时间甚至超过了整体提示词设计。”

8、如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】