构建高效的 AI 智能体
过去一年，我们与数十个团队合作，帮助他们在各行各业构建大语言模型（LLM）智能体（Agent）。我们发现了一个一致的规律：最成功的实现往往不依赖复杂的框架或专业的库，而是采用简单、可组合的模式（composable patterns）来构建。
在这篇文章中，我们将分享与客户合作以及自己构建智能体过程中积累的经验，并为开发者提供构建高效智能体的实用建议。
什么是智能体？
"智能体"可以从多个角度来定义。有些客户将其定义为完全自主的系统——能够长时间独立运行，使用各种工具完成复杂任务。也有人用这个词来描述更具规范性的实现——遵循预定义的工作流运行。在 Anthropic，我们将所有这些变体统称为智能体系统（agentic systems），但在架构层面做了一个重要区分：工作流（workflows）与智能体（agents）。
- •工作流是通过预定义的代码路径来编排 LLM 和工具的系统。
- •智能体则是由 LLM 动态主导自身流程和工具使用的系统，对如何完成任务拥有自主控制权。
接下来，我们将深入探讨这两类智能体系统。在附录 1（“智能体的实践应用”）中，我们会介绍客户在两个领域中使用这些系统获得显著价值的案例。
何时该用（何时不该用）智能体
在使用 LLM 构建应用时，我们建议尽可能寻找最简单的方案，只在确有必要时才增加复杂度。这可能意味着根本不需要构建智能体系统。智能体系统通常是用延迟和成本来换取更好的任务表现，你需要认真考虑这种取舍是否值得。
当确实需要更高复杂度时，工作流适合那些定义明确的任务，能提供可预测性和一致性；而智能体更适合需要灵活性和模型驱动决策的大规模场景。不过对于很多应用来说，优化单次 LLM 调用——配合检索和上下文示例（in-context examples）——通常就足够了。
何时以及如何使用框架
有很多框架可以让智能体系统的实现变得更容易，包括：
- • Claude Agent SDK[1]；
- • Strands Agents SDK by AWS[2]；
- • Rivet[3]，一个拖拽式的 LLM 工作流可视化构建工具；以及
- • Vellum[4]，另一个用于构建和测试复杂工作流的可视化工具。
这些框架简化了调用 LLM、定义和解析工具、串联调用等底层任务，让上手变得更容易。然而，它们往往会引入额外的抽象层，遮蔽了底层的提示词和响应，让调试变得更困难。它们还可能诱使你在简单方案就够用的情况下引入不必要的复杂度。
我们建议开发者从直接调用 LLM API 开始：许多模式只需几行代码就能实现。如果你确实要用框架，请务必理解其底层代码。对内部机制的错误假设是客户常犯的错误。
可以参考我们的 cookbook[5] 获取一些示例实现。
构建模块、工作流与智能体
在这一节中，我们将介绍在生产环境中常见的智能体系统模式。我们从基础构建模块——增强型 LLM（augmented LLM）开始，逐步提升复杂度，从简单的组合式工作流到自主智能体。
构建模块：增强型 LLM
智能体系统的基础构建模块是经过增强的 LLM——具备检索、工具和记忆等扩展能力。当前的模型已经能主动使用这些能力：自主生成搜索查询、选择合适的工具、决定保留哪些信息。
增强型 LLM
在实现时，我们建议重点关注两个方面：一是根据你的具体场景定制这些能力，二是确保它们为 LLM 提供简洁、文档完善的接口。虽然有很多方式可以实现这些增强能力，但其中一种途径是通过我们最近发布的模型上下文协议[6]（Model Context Protocol，MCP），它允许开发者通过简单的客户端实现[7]接入不断壮大的第三方工具生态。
在本文的后续部分，我们假设每次 LLM 调用都具备这些增强能力。
工作流：提示链
提示链（Prompt chaining）将一个任务分解为一系列步骤，每次 LLM 调用处理上一步的输出。你可以在任何中间步骤上添加程序化检查（参见下图中的"gate"），以确保流程仍在正确轨道上。
提示链工作流
适用场景：当任务可以清晰地分解为固定的子任务时，这种工作流最为理想。核心目标是用延迟换取更高的准确性——让每次 LLM 调用处理更简单的任务。
提示链的应用示例：
- • 先生成营销文案，再将其翻译成其他语言。
- • 先写文档大纲，检查大纲是否符合特定标准，再根据大纲撰写完整文档。
工作流：路由
路由（Routing）对输入进行分类，并将其导向专门的后续任务。这种工作流实现了关注点分离，可以构建更专业化的提示词。如果不采用路由，针对某一类输入的优化可能会损害对其他类型输入的处理效果。
路由工作流
适用场景：路由适用于复杂任务中存在明确分类的情况，且各类别最好分别处理，同时分类本身可以被准确完成——无论是通过 LLM 还是传统的分类模型/算法。
路由的应用示例：
- • 将不同类型的客服查询（常见问题、退款请求、技术支持）导向不同的下游流程、提示词和工具。
- • 将简单/常见问题路由到更小、更经济的模型（如 Claude Haiku 4.5），将困难/罕见问题路由到更强大的模型（如 Claude Sonnet 4.5），以优化整体性能。
工作流：并行化
LLM 有时可以同时处理一个任务的多个部分，再通过程序化方式聚合输出。这种并行化（Parallelization）工作流主要有两种变体：
- •分段处理（Sectioning）：将任务拆分为独立的子任务并行执行。
- •投票机制（Voting）：对同一任务运行多次以获得多样化的输出。
并行化工作流
适用场景：当子任务可以并行以提高速度，或需要多个视角/多次尝试来获得更高置信度的结果时，并行化非常有效。对于涉及多个考量维度的复杂任务，让每个维度由单独的 LLM 调用处理，通常比一次性处理所有维度效果更好——这样可以让模型对每个方面给予专注的关注。
并行化的应用示例：
- •
- 分段处理
- ：
- • 实现护栏（guardrails）机制：一个模型实例处理用户查询，另一个筛查不当内容或请求。这通常比让同一次 LLM 调用同时处理护栏和核心响应效果更好。
- • 自动化评测（evals）：每次 LLM 调用评估模型在给定提示词上不同方面的表现。
- •
- 投票机制
- ：
- • 代码漏洞审查：多个不同的提示词分别审查代码，发现问题即标记。
- • 内容合规性判定：多个提示词评估不同方面，或设置不同的投票阈值以平衡误报和漏报。
工作流：编排者-执行者
在编排者-执行者（Orchestrator-workers）工作流中，一个中央 LLM 动态分解任务，将子任务分派给执行者 LLM，再综合它们的结果。
编排者-执行者工作流
适用场景：这种工作流适合那些无法预先确定子任务的复杂场景（比如在编码中，需要修改的文件数量和每个文件的修改内容往往取决于具体任务）。虽然在结构上与并行化相似，但关键区别在于灵活性——子任务不是预先定义的，而是由编排者根据具体输入动态决定的。
编排者-执行者的应用示例：
- • 每次需要对多个文件进行复杂修改的编码产品。
- • 需要从多个来源收集和分析信息以寻找相关内容的搜索任务。
工作流：评估者-优化者
在评估者-优化者（Evaluator-optimizer）工作流中，一个 LLM 调用生成响应，另一个提供评估和反馈，形成循环。
评估者-优化者工作流
适用场景：当我们有明确的评估标准，且迭代改进能带来可衡量的价值时，这种工作流特别有效。判断是否适用有两个信号：第一，当人类明确指出反馈意见时，LLM 的响应确实能得到改善；第二，LLM 本身也能够提供这样的反馈。这类似于人类作者在打磨一篇文章时经历的反复修改过程。
评估者-优化者的应用示例：
- • 文学翻译：译者 LLM 可能无法一次捕捉所有细微之处，但评估者 LLM 可以提供有价值的改进意见。
- • 复杂搜索任务：需要多轮搜索和分析才能收集全面的信息，由评估者决定是否需要继续搜索。
智能体
随着 LLM 在关键能力上日趋成熟——理解复杂输入、进行推理和规划、可靠地使用工具、从错误中恢复——智能体（Agents）正在生产环境中崭露头角。智能体的工作始于人类用户的指令或与用户的交互讨论。一旦任务明确，智能体就会独立规划和执行，必要时返回向人类获取更多信息或判断。在执行过程中，智能体在每一步都从环境中获取真实反馈（ground truth）至关重要——比如工具调用结果或代码执行输出——以此评估自身进展。智能体可以在检查点或遇到阻碍时暂停，等待人类反馈。任务通常在完成时终止，但也常会设置终止条件（如最大迭代次数）来保持控制。
智能体能够处理复杂的任务，但其实现往往并不复杂。它们本质上就是 LLM 在循环中根据环境反馈使用工具。因此，精心设计工具集及其文档至关重要。我们在附录 2（“为你的工具做提示工程”）中详细阐述了工具开发的最佳实践。
自主智能体
适用场景：智能体适用于开放式问题——很难或无法预测所需的步骤数量，也无法硬编码固定路径。LLM 可能需要运行很多轮，你必须对其决策能力有一定程度的信任。智能体的自主性使其非常适合在可信环境中扩展任务规模。
智能体的自主特性意味着更高的成本，以及错误累积的风险。我们建议在沙箱环境中进行充分测试，并配备适当的护栏机制。
智能体的应用示例：
以下示例来自我们自己的实现：
- • 用于解决 SWE-bench 任务[8]（一个评估 AI 编码能力的基准测试）的编码智能体，根据任务描述对多个文件进行编辑；
- • 我们的"计算机使用"参考实现[9]，让 Claude 使用计算机来完成任务。
编码智能体的高层流程
模式的组合与定制
这些构建模块并非刚性的规范，而是开发者可以根据不同场景自由塑造和组合的通用模式。成功的关键——和所有 LLM 功能一样——在于衡量性能并不断迭代。再次强调：只有当增加复杂度能明确改善结果时，才应该这样做。
总结
在 LLM 领域取得成功，靠的不是构建最精巧的系统，而是构建最合适的系统。从简单的提示词开始，通过全面的评测来优化，只有在简单方案力不从心时才引入多步骤的智能体系统。
在实现智能体时，我们遵循三个核心原则：
- 保持设计的简洁性。
- 优先考虑透明度——明确展示智能体的规划步骤。
- 通过充分的工具文档和测试，精心打造智能体-计算机接口（ACI）。
框架可以帮助你快速起步，但在迈向生产环境时，不要犹豫去减少抽象层，回归基础组件来构建。遵循这些原则，你可以打造出不仅强大，而且可靠、易维护、值得用户信赖的智能体。
01
什么是AI大模型应用开发工程师？
如果说AI大模型是蕴藏着巨大能量的“后台超级能力”，那么AI大模型应用开发工程师就是将这种能量转化为实用工具的执行者。
AI大模型应用开发工程师是基于AI大模型，设计开发落地业务的应用工程师。
这个职业的核心价值，在于打破技术与用户之间的壁垒，把普通人难以理解的算法逻辑、模型参数，转化为人人都能轻松操作的产品形态。
无论是日常写作时用到的AI文案生成器、修图软件里的智能美化功能，还是办公场景中的自动记账工具、会议记录用的语音转文字APP，这些看似简单的应用背后，都是应用开发工程师在默默搭建技术与需求之间的桥梁。
他们不追求创造全新的大模型，而是专注于让已有的大模型“听懂”业务需求，“学会”解决具体问题，最终形成可落地、可使用的产品。
CSDN粉丝独家福利
给大家整理了一份AI大模型全套学习资料，这份完整版的 AI 大模型学习资料已经上传CSDN，朋友们如果需要可以扫描下方二维码&点击下方CSDN官方认证链接免费领取【保证100%免费】
02
AI大模型应用开发工程师的核心职责
需求分析与拆解是工作的起点，也是确保开发不偏离方向的关键。
应用开发工程师需要直接对接业务方，深入理解其核心诉求——不仅要明确“要做什么”，更要厘清“为什么要做”以及“做到什么程度算合格”。
在此基础上，他们会将模糊的业务需求拆解为具体的技术任务，明确每个环节的执行标准，并评估技术实现的可行性，同时定义清晰的核心指标，为后续开发、测试提供依据。
这一步就像建筑前的图纸设计，若出现偏差，后续所有工作都可能白费。
技术选型与适配是衔接需求与开发的核心环节。
工程师需要根据业务场景的特点，选择合适的基础大模型、开发框架和工具——不同的业务对模型的响应速度、精度、成本要求不同，选型的合理性直接影响最终产品的表现。
同时，他们还要对行业相关数据进行预处理，通过提示词工程优化模型输出，或在必要时进行轻量化微调，让基础模型更好地适配具体业务。
此外，设计合理的上下文管理规则确保模型理解连贯需求，建立敏感信息过滤机制保障数据安全，也是这一环节的重要内容。
应用开发与对接则是将方案转化为产品的实操阶段。
工程师会利用选定的开发框架构建应用的核心功能，同时联动各类外部系统——比如将AI模型与企业现有的客户管理系统、数据存储系统打通，确保数据流转顺畅。
在这一过程中，他们还需要配合设计团队打磨前端交互界面，让技术功能以简洁易懂的方式呈现给用户，实现从技术方案到产品形态的转化。
测试与优化是保障产品质量的关键步骤。
工程师会开展全面的功能测试，找出并修复开发过程中出现的漏洞，同时针对模型的响应速度、稳定性等性能指标进行优化。
安全合规性也是测试的重点，需要确保应用符合数据保护、隐私安全等相关规定。
此外，他们还会收集用户反馈，通过调整模型参数、优化提示词等方式持续提升产品体验，让应用更贴合用户实际使用需求。
部署运维与迭代则贯穿产品的整个生命周期。
工程师会通过云服务器或私有服务器将应用部署上线，并实时监控运行状态，及时处理突发故障，确保应用稳定运行。
随着业务需求的变化，他们还需要对应用功能进行迭代更新，同时编写完善的开发文档和使用手册，为后续的维护和交接提供支持。
03
薪资情况与职业价值
市场对这一职业的高度认可，直接体现在薪资待遇上。
据猎聘最新在招岗位数据显示，AI大模型应用开发工程师的月薪最高可达60k。
在AI技术加速落地的当下，这种“技术+业务”的复合型能力尤为稀缺，让该职业成为当下极具吸引力的就业选择。
AI大模型应用开发工程师是AI技术落地的关键桥梁。
他们用专业能力将抽象的技术转化为具体的产品，让大模型的价值真正渗透到各行各业。
随着AI场景化应用的不断深化，这一职业的重要性将更加凸显，也必将吸引更多人才投身其中，推动AI技术更好地服务于社会发展。
CSDN粉丝独家福利
给大家整理了一份AI大模型全套学习资料，这份完整版的 AI 大模型学习资料已经上传CSDN，朋友们如果需要可以扫描下方二维码&点击下方CSDN官方认证链接免费领取【保证100%免费】
