从提示词到生产环境上线：智能体开发指南

大语言模型（LLM）能够基于已学习的概率分布生成文本。它们本身不具备在现实世界中执行动作的能力。智能体 AI 是在 LLM 之外的一个封装层，通过包含反思、工具使用、规划和多智能体协作的迭代来优化流程，成为连接 LLM 核心技术（比如，GPT‑5、Claude Opus 4.1）与现实业务价值的桥梁。因此，企业必须学会如何在生产环境中开发、上线并安全运营智能体 AI 应用。

本文是一份面向实践者的指南，描述了如何构建智能体 AI 应用并在生产环境中实现规模化部署，重点介绍帮助开发者在生产环境落地并扩展智能体的开发实践。

引言

Google Brain联合创始人、AI 领域极具影响力的专家吴恩达（Andrew Ng）在其名为 “吴恩达来信”的博客中提到，智能体 AI 将主导 AI 领域的大部分进展，因为它拥有前所未有的实用价值。正如这篇智能体设计模式文章所述，它具有驱动业务流程的潜力。

智能体 AI 建立在推理、执行和再推理的理念之上，直到 LLM 判定某次执行的目标已完成为止。在针对多种智能体方法的研究中，使用 GPT‑3.5 和 GPT‑4 的零样本方式在编码基准测试中分别达到了约 48%和 67%的准确率，而基于 GPT‑3.5 的迭代循环智能体 AI 则达到了 95.1%的准确率。

即使使用相对老旧的模型，迭代式智能体的循环机制所带来的提升也超过了从 GPT‑3.5 到 GPT‑4 的基础模型升级。这对企业来说意味着什么呢？吴恩达在 Scale Up 的采访中表示，这意味着对大多数企业而言，利用智能体 AI 构建实用应用程序应成为优先事项，而非追逐最新的基础模型。

从原型到生产的鸿沟

在传统软件开发中，会首先通过原型来验证概念，再使用类似但更大规模的流程构建应用程序并将其部署到生产环境。对智能体 AI 而言，整体概念基本一致，但存在一个本质区别：智能体不具备行为一致性，因此原型的受控环境无法代表真实的环境。智能体系统面临的是非确定性行为、涌现能力（emergent capabilities）与自主决策。例如，对非确定性系统的测试，完全与成熟的软件工程中“输入—固定的预期输出”的测试场景不同。

理解智能体开发

企业级团队在不断尝试扩大智能体 AI 的应用范围，在此过程中会面临经典的产品市场适配问题。这一切均起源于两个截然相反的问题：“目前，是否存在可通过智能体 AI 解决的问题？”

vs.“

既然我想应用智能体 AI，那么哪些现有的问题最适合作为切入点？”

有一点需要明确，几乎不涉及任何主观决策的确定性工作流，用传统方法实现效果更好。智能体 AI 的优势在于处理非确定性的决策，并基于这些决策执行现实的动作。

AI 系统的软件开发生命周期（SDLC）具有本质不同的特性。A. Gill 的敏捷研究指出了 AI 系统区别于传统软件的六个属性：自主性、自适应性、内容生成、决策能力、可预测性和推荐能力。这些属性要求“在敏捷 SDLC 框架内集成决策科学”，从功能开发转向行为编排。

同样，国际标准化组织发布了ISO/IEC 5338:2023“信息技术 — 人工智能 —AI 系统生命周期流程（Information technology – Artificial intelligence – AI system life cycle processes）”，建立了首个全面的 AI 系统开发框架。该标准强调全流程风险管理，并明确要解决自主系统行为验证所面临的挑战。

这些范式都反映出，我们构建非确定性系统软件的方式正在发生更深层次的变革。

架构与设计模式

在深入开发实践之前，我们回顾一些对智能体应用开发有帮助的架构与设计模式。开发者可使用这些通用设计模式简化智能体应用的开发。

智能体控制 LLM 的输入与输出，使 LLM 始终返回结构化的输出，这可以被解析并转换为一个或多个函数调用（称为智能体的工具）。智能体只需要在工具引用池中查找对应的工具，并使用 LLM 输出提供的参数进行调用即可。

这个过程可以仅执行一次，也可以按照各种设计模式循环执行。

智能体应用开发的核心架构模式

以下核心模式覆盖了绝大多数的生产场景，智能体应用开发者需要熟练掌握这些核心概念。

ReAct 智能体

ReAct 智能体基于该领域的奠基性论文，是通用性最强的智能体模式之一。它由智能体、LLM 和工具调用之间的循环构成，直到满足终止条件或由外部逻辑触发中断。

下图展示了在宏观层面上 ReAct 智能体循环中的单次交互流程，步骤从 1 到 8 编号，每次迭代会重复执行，直到满足终止条件。图 1：ReAct 智能体循环

图 1：ReAct 智能体循环

ReAct 模式特别适合智能体需要迭代调查问题的工作流。例如，数据库调试智能体可以执行查询、分析性能缓慢的现象、检查现有索引，并持续循环直到找到根本原因。以下是核心 ReAct 循环（推理→执行→观察）的伪代码片段：

def react_agent_loop(user_query, available_tools, max_iterations=5):    """    ReAct pattern: Iterative reasoning and action until goal achieved    """    conversation_history = []    conversation_history.append({"role": "user", "content": user_query})        for iteration in range(max_iterations):        # STEP 1: Reason - LLM decides next action        llm_response = llm_client.generate(            messages=conversation_history,            tools=available_tools,            temperature=0.7        )                # STEP 2: Act - Execute tool if LLM chose one        if llm_response.has_tool_call():            tool_name = llm_response.tool_call.name            tool_args = llm_response.tool_call.arguments                        # Execute the selected tool            tool_result = execute_tool(tool_name, tool_args, available_tools)                        # Add tool result to conversation            conversation_history.append({                "role": "assistant",                "content": None,                "tool_calls": [llm_response.tool_call]            })            conversation_history.append({                "role": "tool",                "content": tool_result,                "tool_call_id": llm_response.tool_call.id            })                        # STEP 3: Observe - Check if we should continue            if should_terminate(tool_result, user_query):                break        else:            # LLM provided final answer without tool use            return llm_response.content        # Generate final response after all iterations    final_response = llm_client.generate(        messages=conversation_history + [{            "role": "user",            "content": "Provide final answer based on above"        }]    )    return final_response.contentdef should_terminate(tool_result, original_query):    """    Breaking condition logic - could be:    - Explicit completion signal from LLM.    - Confidence threshold met.    - Error state requiring human intervention (Human in the loop)    """    if "COMPLETE" in tool_result:        return True    if "ERROR" in tool_result and "ESCALATE" in tool_result:        return True    return False

监管者智能体模式

在场景足够复杂的多智能体环境中，通常需要先进行集中式规划，再执行具体的任务。该模式包含一个用于集中规划的监管者（supervisor）智能体，它会将任务分配给多个专用的工作者智能体。监管者会在每一步决定接下来调用哪个智能体，或在目标达成时结束工作流。现实案例是 Anthropic 的多智能体研究系统，它使用多个智能体探索复杂研究主题，由中央智能体根据用户查询规划研究流程，再使用专门的并行智能体执行计划中的各个步骤。

图 2 展示了监管者智能体模式的结构：图 2：监管者智能体模式[点击查看大图]分层的智能体模式当工作者智能体数量过多，单个监管者无法高效管理时，可以采用分层的系统，也就是创建多个智能体团队，每个团队有自己的监管者，再由更高层的监管者管理团队级的监管者。

图 2：监管者智能体模式

[点击查看大图]

分层的智能体模式

当工作者智能体数量过多，单个监管者无法高效管理时，可以采用分层的系统，也就是创建多个智能体团队，每个团队有自己的监管者，再由更高层的监管者管理团队级的监管者。

例如，电商订单的履约系统可使用分层模式：总履约智能体协调区域监管者（北美、欧洲、亚洲），每个区域监管者管理专用的仓库智能体，负责库存检查、拣货、打包和发货。

下图展示了分层的智能体模式：

图 3：分层的智能体模式

[点击查看大图]

人工介入模式

许多工作流存在一些特殊的决策点，这些决策点必须要由人工监督和审批才能推进。这类场景可以结合 AI 驱动的高效率与人工的决策/审核，实现巨大的生产力提升。微软的Magentic-UI研究了专门聚焦人工介入（human-in-the-loop）的智能体系统。

我们以贷款审批工作流为例说明该模式。

图 4：人工介入模式

其他可参考的模式

下表列出了其他的智能体 AI 模式及链接，供进一步学习。

表 1：其他模式的参考表

规划智能体实现

第一步，通过多轮迭代回答几个简单问题，找出应用中适合智能体 AI 的组成部分。答案在多轮迭代中的演进有助于简化决策。

表 2：智能体 AI 组件的迭代评估示例

完成以上宏观层面的分析后，我们就可以开始设计各工作流的能力矩阵（参见表 3），或规划其他的开发活动了。

认真执行上述流程可以作为后续开发的指导清单。例如，上表中的第三个问题（即“是否为每个工作流准备了能力矩阵？”）可以用来为应用的每个工作流创建能力矩阵（参见下一节的表 3），这样就能将每个工作流范围拆分为智能体与非智能体部分。需要记住，智能体涉及 LLM 调用与工具调用，可能以循环方式运行。从基于LangSmith的智能体追踪图中可以看到（参见图 5），LLM 调用会引入显著延迟，因此我们不希望用智能体实现确定性或固定规则的组件。这里的指导原则是，如果代码可以基于固定规则做出清晰无歧义的决策，那么应用中的这些部分就不需要智能体推理，因为通过 LLM 实现的智能体推理会牺牲简洁性与性能。

实现智能体的功能（能力矩阵法）

智能体应用开发中最常见的一个反模式就是试图将所有内容都智能体化。基于我们上述的原则，智能体应用的需求分析必须包含一个系统化的流程，识别应用的哪些部分应利用非确定性的 LLM 推理，哪些部分应采用确定性的规则。对某些更适合确定性实现的任务，必须避免这种反模式。我们以一个智能体客服系统为例，该系统编排了端到端的客服工作流。表 3 列出了该示例工作流的每一步，并说明实现目标的正确方式。

我们将每个工作流步骤进行拆解，分析其应为确定性的（基于规则、可预测）还是非确定性的（需要 LLM 推理）。核心要点就是，大多数生产应用会同时包含确定性（固定规则）与非确定性（基于推理）的能力。

表 3：工作流能力矩阵

这种能力矩阵的方式有助于形成以下的关键结论：是否要从结构化/非结构化文本中进行非确定性推理，这是区分智能体与非智能体组件的清晰分界线。任何需要基于动态推理执行的动作（如理解用户意图、是否跟进问题）都应该实现为智能体，通常要创建函数调用工具，由智能体根据 LLM 推理进行调用。任何基于当前应用/系统状态的动作，都应该且可编码为传统非智能体规则的实现。

大多数应用即便适合采用智能体方案，仍然会有相当一部分功能应基于规则而非智能体来实现。

架构与开发应该由可靠的需求来驱动。没有模糊解释，或者会导致明确失败并阻塞功能的场景，必须要使用确定性方式的实现，例如，SLA 应基于工单类型设置为固定的值，或者，工单 ID 的生成要遵循固定逻辑。存在多种合理解释的功能可以从 LLM 推理中获益，例如，基于当前方案与用户个性化生成不同的措辞、不同的 API 调用或查询。

成本优化也应该考虑进来，因为 LLM 调用成本较高，应该仅用于真正的非确定性任务。因此，任何智能体工作流或用例都应定义如下的内容：宏观层面的确定性容器，定义工作流的边界每个工作流步骤的映射基于推理需求的工作流步骤分类开发工作流开发者工作流 — 实现智能体角色与规划逻辑智能体的编排方式没有限制，可顺序、并发或使用任意的协调策略。但大多数的应用可归入某个标准的编排模式。微软 Azure 的智能体编排研究指出了五种主要的协调模式，每种都针对不同的运营需求进行了优化：

顺序编排图片:

图 5：顺序编排（参考微软的编排模式）

智能体按照预定义的线性顺序执行，每个智能体处理上一阶段的输出。该模式最适合不同阶段间存在质量门禁，对业务至关重要的文档处理工作流。JPMorgan Chase的COiN（合同智能）系统展示了顺序文档分析的强大能力，它能每秒处理 1.2 万份商业信贷协议，错误率接近零，每年能节省 36 万小时的法务工时。

并发编排

多个智能体并发执行任务并汇总结果。该模式能够降低独立子任务的延迟。Google Cloud 的 Agent Assist 体现了并发处理优势，客服对话处理量提升了 28%，响应速度加快了 15%。

图 6：并发编排（参考微软的编排模式）分层编排

监管者智能体需要协调专门的工作者智能体，实现复杂任务的分解。Zhang等人的最新研究表明，AgentOrchestra 的分层框架能够持续优于扁平的智能体架构，在复杂基准测试中达到了 95.3%准确率。Liu等人的独立验证显示，三层分层架构相比此前的最优方法，任务成功率绝对提升了 32%。

除以上示例外，一次性（single-shot）、循环（looped）与多智能体编排的选择取决于任务复杂度与可靠性的需求。Max Pavlov文章中描述的一次性系统适合边界清晰、成功标准明确的任务，如简单数据校验或 API 调用。循环系统（参见谷歌的智能体开发工具包）支持迭代优化，但需要成熟的终止条件以避免无限循环，如质量阈值、迭代上限或提前终止策略。多智能体编排为复杂任务提供最强的能力，但需要精细的协调机制，系统平均 Token 消耗最高可达其他方式的 15 倍（参见Anthropic对智能体的研究）。

自主级别设计

这类编排需要明确决策人工监督的集成方式。该框架定义了四种类型：Human-in-the-Loop（直接干预）、Human-on-the-Loop（有效控制）、Human-above-the-Loop（战略治理）、Human-behind-the-Loop（运营后分析），参见Pawel Rzeszucinski名为“AI, Human and Loop”的文章”的文章。同样，Amazon Bedrock的多智能体协作框架表明，将不同编排方式与内置护栏结合，可在自动化效率与运营安全之间实现最优的平衡。

开发者工作流 — 版本管理智能体系统带来了更复杂的版本管理需求。与典型非智能体后端应用的标准版本管理相比，智能体系统引入了多个新的交叉节点，从而产生了新的故障点，例如，系统提示词、工具、LLM 配置和其他资源。我们逐一评估这些组件的版本管理方式。

微软 Azure AI 平台指出了需要版本化管理的关键智能体制品的类别：提示词模板或系统提示词研究表明，在相同输入的情况下，智能体执行路径的变异系数最高可达 63%（Mark Hornbeek）。因此，提示词必须进行版本化，这不仅可以用于追踪变更，还可以在变更引入行为漂移时进行回滚。现代提示词管理平台提供基于 Git 的版本控制和性能监控（参见 PortKey 的版本指南）、生产环境中智能体运行时的提示词控制（Launch Darkly）和全面的可观测框架（比如，LangSmith）。模型上下文协议（MCP）为智能体‑工具集成提供了标准化的接口，确保智能体运维环境的版本与一致性。使用这些工具，我们还可在运行时修改提示词并保证完善的版本控制。

工具清单

使用 JSON/YAML 规范定义可用函数、参数与权限需求。工具清单（tool manifest）需要类似软件包那样的依赖管理功能，因为工具添加或修改可能从根本上改变智能体的能力。例如，如果将工具调用的输出加入下一次 LLM 调用的提示词中，这可能会影响智能体工作流下一步的 LLM 决策行为。

下图描述了通用版本管理流程中所涉及的版本化组件。图 7：智能体版本管理组件[点击查看大图]版本化控制的提示词与策略需要说明的是，提示词是控制智能体系统中 LLM 行为与决策的最直接的方式，因此需要精细管理以避免出现（有意或无意的）漂移。事实上，RisingWave 的研究将提示词漂移列为最关键的故障模式。大多数生产环境的智能体故障都可追溯到不受控制的提示词修改，这些修改与系统更新或数据变化产生了不可预测的交互。

图 7：智能体版本管理组件

[点击查看大图]

版本化控制的提示词与策略

需要说明的是，提示词是控制智能体系统中 LLM 行为与决策的最直接的方式，因此需要精细管理以避免出现（有意或无意的）漂移。事实上，RisingWave的研究将提示词漂移列为最关键的故障模式。大多数生产环境的智能体故障都可追溯到不受控制的提示词修改，这些修改与系统更新或数据变化产生了不可预测的交互。

因此，提示词应被视为基础设施即代码（Infrastructure as Code，IaC），存储在 Git 仓库中，并遵循正式的变更审批流程。采用这种方式的组织使用渐进式的交付模式，包括提示词变更的 A/B 测试，当行为指标漂移超出可接受阈值时自动回滚（参见Open Policy Agent）。

回归测试的黄金轨迹

那么，智能体 AI 行为回归测试的基础是什么？我认为是 “黄金轨迹（golden trajectories）” 的概念。黄金轨迹指的是经过验证的智能体交互序列，本质是追踪记录，不仅捕获最终输出，还包括完整的推理链、工具调用与决策点。LangChain 和LangSmith等框架允许我们对智能体的工具函数和代码的其他部分进行埋点以实现可追踪性。这种可追踪性提供了审计智能体与工具、LLM 及其他接口交互的方法。以下系统示例展示了工作流执行期间的所有智能体交互。

图 8：使用 LangSmith 追踪平台的黄金轨迹剖析

[点击查看大图]

在图 8 的生产环境跟踪数据中，展示了一个 CVE 补丁智能体的执行过程，包含了行为回归测试所需的所有内容：跨多个 LLM 调用的完整推理链、带参数的工具调用、阻止无限循环的决策门禁以及包括 git 上下文在内的完整状态捕获。当修改这个智能体的提示词时，可以将新的执行过程与这个基线进行比较，任何明显偏离都会触发自动回滚。

智能体的自动化测试

智能体系统的测试与传统应用的测试方法有何差异呢？智能体应用（无论是否自动化）的测试必须要基于对确定性系统与非确定性系统之间架构差异的深入理解来开展。智能体应用是非确定性的，因为它们使用 LLM 进行推理，并通过工具调用采取行动。

测试方式

这里描述的多种方法借鉴了“重新思考LLM应用测试”论文中的观点：智能体系统大致可分为三层：

系统调用（System Shell）

包含确定性的组件，如 API 接口、集成组件与工具调用模块。

编排

负责使用当前应用的状态、用户输入与其他变量来构建 LLM 运行时的输入提示词。该提示词来自智能体的静态系统提示词模板，包含运行时值占位符，这些值可能来自用户输入或应用状态计算的结果。

LLM 推理核心

核心 LLM 服务被视为黑盒，但可以通过提示词操作和/或当前应用状态对其施加影响。基于这一理解，我们来看一下在全面指南中探索非确定性软件必备的测试范式。

基于属性的测试（Property-Based Testing）

基于属性的测试需要验证系统在随机生成的输入下是否满足逻辑属性（参见QuickCheck的论文）。主流的基于属性的测试框架Hypothesis显示，相比传统单元测试，它对 AI 系统的缺陷检出率要高得多。

行为测试工具（Behavioral Test Harnesses）

行为测试工具提供 mock API、模拟用户交互与受控的故障场景。

蜕变测试（Metamorphic Testing）

按照“反思测试”论文中的描述，蜕变方法关注输入与输出之间的关系，而非单个输出的正确性，这对于真实答案可能具有主观性的 AI 系统尤其有效。

测试类型、范围、检查项与工具的映射

如下的表格展示适用于所有智能体应用的各类测试方法、适用范围、相关检查项与识别的框架/工具。

表 4：智能体应用的测试类型

结论智能体 AI 应用开发在生产环境大规模铺开时会面临独特的挑战，这些挑战涵盖了识别智能体组件，以及实现、部署、测试与追踪。实际上，使用智能体 AI 的应用很少是完全智能体化的，这意味着应用程序很可能包含一部分非智能体的组件。因此，每项开发实践都会因智能体的引入而变得更加复杂，这会影响实现、测试与应用的其他方面。例如，为测试定义预期输出不再那么直观，因为相同输入在不同时机运行时，智能体可能产生不同但同样可接受的行为（这源于 LLM 输出的差异）。我们试图追踪这些影响开发实践的因素，并使用在真实生产环境部署智能体 AI 应用的过程中积累的实用解决方案来应对这些挑战。

查看英文原文：From Prompts to Production: A Playbook for Agentic Development