智能体开发生命周期

每个人都希望部署智能体（Agents）。

最优秀的组织已经找到了如何反复、安全且系统地做到这一点的方法。他们早期发布，从真实使用中学习，并快速迭代。他们不把智能体视为一次性的演示或孤立的项目。

相反，他们建立了一个智能体开发生命周期，通过将实验转化为可重复的发布、学习和改进系统，从而创造动力。

该生命周期包含四个部分：

构建 → 测试 → 部署 → 监控

这个顺序是有意为之的。测试应在智能体进入生产环境之前开始，而不是之后。团队需要在部署前测试智能体，以受控方式部署它们，监控其在生产环境中的行为，并将这些学习成果反馈到下一个构建和评估周期中。

对于单个智能体，这个过程可以保持轻量化。但在众多智能体的情况下，它就变成了一个基础设施和治理挑战。团队需要共享的方式来控制成本、管理工具访问权限、检查工具调用、重用上下文，并决定在何处需要人工介入。

让一个智能体工作一次与将构建智能体作为一种可重复的实践之间的区别，在于是否建立了正确的开发生命周期。

构建

在构建阶段，团队决定他们正在创建哪种类型的智能体系统，以及希望使用何种抽象级别。

这里的工具种类广泛。有些工具是代码优先的，而另一些则是无代码或低代码的。有些专注于抽象，而另一些则专注于为智能体提供一个包含提示词、工具、技能和状态的工作环境。

在代码优先方面，团队通常会选择开源框架和平台。在 LangChain 生态系统中，这包括 LangChain、LangGraph 和 Deep Agents。在 LangChain 之外，例子包括 CrewAI 和 Claude Agents SDK。

这些工具在堆栈的不同层面上运作。

智能体框架主要关注抽象。它们帮助开发者组合模型调用、工具、提示词、检索、结构化输出和智能体循环。LangChain 和 CrewAI 属于这一类别。

智能体运行时关注执行。它们支持需要状态、控制流、持久性和人工干预的智能体。LangGraph 是 LangChain 生态系统中最清晰的例子。它提供了一种构建智能体系统的方法，该系统可以分支、循环、暂停、恢复，并随时间持续状态。

智能体平台关注实际操作。它们为长期运行的任务提供智能体所需的周围结构：提示词、技能、MCP 服务器、钩子、中间件，有时还有文件系统。Deep Agents 和 Claude Agent SDK 是这种模式的例子。

这些区别很重要，因为“构建智能体”可能意味着不同的事情。

对于简单应用，这可能只涉及定义一个工具调用循环。对于更复杂的智能体，这可能涉及编写提示词、定义技能、连接 MCP 服务器、配置中间件，以及设置智能体可以随时间检索或更新的上下文。

无代码构建

构建阶段也有无代码和低代码的一面。像 LangSmith Fleet、Claude Cowork 和 n8n 这样的工具允许更多人参与智能体开发。这很重要，因为理解所需工作流程的人并不总是编写代码的人。

同时，无代码工具并没有消除对工程控制的需求。随着系统变得越来越复杂，团队通常需要以代码方式扩展或覆盖行为。钩子和中间件在这里特别重要，因为它们允许团队在工具调用、上下文处理、审批、认证或业务规则周围添加自定义逻辑，而无需从头重建每个智能体。

最好的构建环境让简单的事情变得简单，让复杂的事情成为可能。它们让领域专家编辑提示词、技能和上下文，同时仍然让工程师控制那些需要可靠、可测试和可治理的部分。

测试

在部署智能体之前，团队需要一种方法来确定它是否真正准备好了。

这并不意味着在任何人使用智能体之前构建一套完美的评估套件。在实践中，这很少现实。但这意味着要有足够的评估来捕捉明显的失败、比较版本，并避免盲目地发布更改。

大多数评估工作流程始于一个代表性任务的小数据集。一些例子来自预期用例，而其他例子来自手动测试、内部测试、支持工单、先前的追踪记录或已知的边缘情况。随着时间的推移，生产追踪记录会使这些数据集更加强大，但测试应在生产之前开始。

数据集和指标

数据集是团队保留所学内容的方式。没有它们，相同的失败往往会在提示词更改、模型升级或工具更新后重新出现。

正确的指标取决于任务。

在某些情况下，有明确的地面真值答案。智能体是否提取了正确的值？它是否选择了正确的标签？它是否更新了正确的字段？这些任务可以直接测量正确性。

其他时候，没有单一的地面真值答案。智能体可能需要撰写回复、总结对话、决定是否升级，或完成具有许多有效路径的任务。在这种情况下，团队更依赖于基于标准的评估。问题变成回复是否有依据，智能体是否遵循策略，是否请求澄清，或是否在不需要工具调用的情况下高效完成任务。

实验

实验是将数据集和指标与迭代连接起来的关键。它们允许团队在同一评估集上比较提示词、模型、检索策略、工具模式和编排模式。随着时间的推移，这些实验显示智能体是在改进还是退化。

目标不是在第一天的就创建完美的评估套件。目标是始于一个有用的套件并持续改进它。最有价值的评估数据集是从最难的例子构建的：首先来自开发和内部测试，然后后来来自生产环境。

模拟

模拟是测试的另一个重要部分。

许多智能体是多轮系统。它们不只是回答一个问题；它们进行对话，收集信息，调用工具，更新状态，并从歧义中恢复。对于这些智能体，单轮评估是不够的。团队需要多轮评估和模拟端到端交互。

语音智能体是一个明显的例子，但这种模式更广泛。任何在一系列回合中运行的智能体可能都需要模拟。支持智能体可能需要处理沮丧的客户，提出后续问题，检查订单状态，并决定是否有必要升级。编码智能体可能需要检查代码库，进行更改，运行测试，并对反馈做出反应。内部运营智能体可能需要采取行动前收集缺失的信息。

良好的测试实践帮助团队系统地改进智能体，而不依赖直觉。它们将预期行为转化为数据集，将数据集转化为实验，将实验转化为系统的更好版本。部署后，监控提供使这些评估更强的真实世界例子。

部署

一旦智能体被构建和评估，它需要一个可以可靠运行的环境。

对于简单智能体，部署可能看起来类似于部署传统应用程序。但许多智能体需要的不仅仅是一个无状态服务器。它们运行时间更长，调用工具，等待人工输入，写入文件，从中断中恢复，并在多次交互或任务中保持状态。

这就是为什么运行时很重要的原因。

生产智能体运行时通常需要支持持久执行和人机协作模式。持久执行意味着智能体可以检查点进度并恢复，而不是在出现问题时丢失工作。人机协作意味着智能体可以在需要审批、澄清或审查时暂停。

为此有现成的解决方案。LangSmith Deployment 提供了部署和管理 Deep Agents 和 LangGraph 智能体的基础设施。AWS AgentCore 是另一种受管运行时的例子。一些团队也在 Temporal 等系统之上构建自己的运行时，特别是当他们在堆栈的其他地方已经使用 Temporal 进行长期运行的工作流时。

沙盒

许多智能体还需要专用的执行环境。

智能体越来越多地需要编写代码、执行代码、检查文件、转换文档或与文件系统交互。在这种情况下，团队需要决定这些工作在哪里发生。沙盒是一个常见的解决方案。它们提供具有文件系统访问权限的隔离执行环境，同时减少错误或不安全行为的影响范围。

例子包括 LangSmith Sandboxes、Daytona 和 E2B。

并非每个智能体都需要完整的沙盒。在某些情况下，智能体只需要一个存储和检索文件的地方。虚拟文件系统就足够了。Deep Agents 支持这种模式，允许智能体使用文件作为工作内存，而无需在沙盒内执行任意代码。在下面，该文件系统可能由 Postgres 或 S3 等系统支持。

上下文中心

部署中另一个经常被忽视的部分是管理提示词和上下文。

智能体的一些最重要部分不是传统的应用程序代码。提示词、检索上下文、技能和任务指令可能需要比应用程序本身更频繁地更改。它们也可能需要由非工程师编辑。

这就产生了提示词或上下文中心的需求：一个存储、版本化、审查和更新智能体非代码部分的地方。这允许团队在不进行全面部署的情况下调整智能体行为，并让领域专家拥有他们最了解的上下文。

在实践中，部署不仅仅是将智能体放在服务器上。它是关于给予智能体完成实际工作所需的运行时、执行环境和上下文管理系统。

监控

一旦智能体被部署，团队需要对其在生产环境中的实际行为可见性。

这就是监控智能体与监控传统软件不同的地方。延迟、成本、错误率和正常运行时间等指标仍然重要，但它们只是画面的一部分。智能体可以返回技术上成功的响应，但仍可能失败任务本身。它可能调用错误的工具，依赖错误的上下文，跳过所需的审批步骤，或产生听起来合理但错误的回答。

为了理解这些失败，团队需要追踪记录。

追踪记录捕获智能体的完整轨迹：它接收的输入、它进行的模型调用、它调用的工具、它接收的输出，以及它产生的最终响应或操作。这是理解智能体实际做了什么所需详细程度的级别。

这就是为什么我们认为智能体可观测性驱动智能体评估，以及为什么智能体改进循环始于追踪记录的原因。如果你看不到轨迹，你就无法可靠地调试行为或将那些失败转化为未来的评估。

信号

监控还应包括从这些追踪记录中收集信号。

一些信号可以来自 LLM-as-judge 评估器。例如，裁判可以评分智能体是否回答了用户的问题、遵循策略、使用正确的语气或完成任务。其他信号可以更简单。正则表达式可以捕捉是否出现了必需短语、是否调用了禁止工具，或是否发生了已知失败模式。

这些信号不仅对质量检查有用。它们还可以成为一种产品分析形式。它们可以告诉您用户要求智能体执行哪些任务，智能体在哪里卡住，用户经常纠正它们，以及用户感知错误在哪里。

反馈

反馈是监控的另一个核心部分。

仅存储追踪记录是不够的。团队还需要将反馈与这些追踪记录一起存储。这些反馈可以来自 LLM 裁判、基于正则表达式的信号、人工审查者或通过 API 收集的直接用户反馈。例如，在 LangSmith 中，团队可以将用户反馈直接附加到基础运行上，从而使连接“用户不满意”与“智能体在三个步骤之前使用了错误的工具”变得更容易。

仪表板

最后，团队需要仪表板和警报，可以显示随时间变化的趋势。

有用的智能体仪表板跟踪使用量、反馈、延迟、成本、工具调用、评估器分数和重复失败模式等指标。当重要阈值被跨越时，警报应触发，例如延迟上升、成本增加、工具失败、用户反馈下降或策略违规激增。

良好的监控不仅仅是了解系统是否在线。它是关于理解智能体是否以正确的方式做正确的工作，并随时间改进。

最强的监控系统直接反馈到评估中。重要的追踪记录成为数据集例子，重复失败成为指标，生产行为成为下一轮改进的基础。

迭代

最优秀的组织快速且系统地通过智能体开发生命周期。

他们不等待完美的智能体才发布。相反，他们构建一些有用的东西，充分测试以了解其行为，以受控方式部署，监控其在生产环境中的性能，并将这些学习成果反馈到下一个版本。

这并不意味着粗心大意地发布。关键是可见性。

拥有数据集、实验、追踪记录、反馈和仪表板的团队可以直接从真实使用中学习。他们可以在广泛推出之前测试更改，识别生产中出错的内容，将失败转化为评估，并在不依赖猜测的情况下改进智能体。

这是团队如何爬坡，以及智能体系统如何随时间改进的方式。

最有效的团队找到困难的例子，理解智能体为什么失败，并调整提示词、工具配置、检索策略、模型、中间件或工作流。他们重新运行评估，部署更好的版本，监控为他们提供下一个边缘情况和失败。

在企业内部，挑战是使该循环在团队之间可重复。

如果每个团队都必须从头构建自己的评估框架、部署基础设施、追踪系统、反馈管道和仪表板，智能体开发将缓慢移动。最有效的组织投资于共享基础设施，以便团队可以通过生命周期移动，而无需不断重新发明基础系统。

这就是使智能体开发生命周期成为一种操作实践的原因。

治理

治理围绕整个智能体开发生命周期。

对于单个智能体，轻量级控制可能就够了。随着组织部署更多智能体，治理变得必要。没有它，团队很快会遇到难以发现、难以监控、运行昂贵且不清楚允许做什么的智能体。

成本

第一个治理挑战是成本。

智能体可能变得昂贵，因为它们可能涉及多次模型调用、长上下文窗口、重复工具使用、重试或长时间运行。组织需要通过预算、使用监控、警报和对哪些智能体、团队、模型或工具推动成本的可见性来跟踪和管理支出。

工具访问

第二个治理挑战是工具访问。

智能体有用，因为它们可以采取行动，但这也会引入风险。团队需要对智能体可以访问哪些工具、在什么条件下以及代表哪些用户需要明确的控制。

这就是审计轨迹变得重要的地方。如果智能体调用工具，组织应该能够检查哪个智能体进行了调用，它使用了什么输入，它产生了什么输出，以及什么用户或策略授权了该操作。工具调用通常是什