---
title: "智能体开发生命周期（ADLC）"
sourceTitle: "The Agent Development Lifecycle (ADLC)"
sourceUrl: "https://www.langchain.com/blog/the-agent-development-lifecycle"
sourceAuthor: "Harrison Chase"
sourcePublishedAt: "2026-05-09T17:15:00.000Z"
summary: "介绍一套面向智能体的开发生命周期：从构建、测试、部署、监控到迭代和治理，帮助团队把一次性 demo 变成可重复、可评测、可运营的工程实践。"
sourceCoverImage: "https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a0572387d90e67612454cde_pic1.avif"
sourceLanguage: "en"
language: "zh-CN"
translationMethod: "baoyu-translate skill"
sourceFigureCount: 8
---

# 智能体开发生命周期（ADLC）

[![智能体开发生命周期文章首图](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a0572387d90e67612454cde_pic1.avif)](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a0572387d90e67612454cde_pic1.avif)

每个人都想发布智能体。

最优秀的组织已经弄清楚了如何反复、安全、系统地做到这一点。它们早早发布，从真实使用中学习，并快速迭代。它们不会把智能体当成一次性 demo 或孤立项目。

相反，它们构建了一套**智能体开发生命周期**：把实验转化为一套可重复的系统，用来持续发布、学习和改进，从而形成动量。

这个生命周期有四个部分：

**构建 → 测试 → 部署 → 监控**

[![智能体开发生命周期：构建、测试、部署、监控](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69ff682de4638684801c78da_99648614.png)](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69ff682de4638684801c78da_99648614.png)

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

对于单个智能体，这个过程可以保持轻量。但当智能体数量变多，它就会变成基础设施和治理挑战。团队需要共享的方式来控制成本、管理工具访问、检查工具调用、复用上下文，并决定哪些地方需要人参与。

让智能体一次跑通，和把智能体构建变成一套可重复实践，差别就在于是否有合适的开发生命周期。

## 构建

构建阶段是团队决定自己要创建哪种智能体系统，以及想使用哪一层抽象的阶段。

这里有很宽的工具谱系。有些工具是 code-first，有些是 no-code 或 low-code。有些关注抽象，有些则关注为智能体提供一个可以工作的环境，包括 prompt、工具、skills 和状态。

[![构建阶段：从 code-first 框架到 no-code 与 low-code 工具](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69ff682de4638684801c78e0_14009bc9.png)](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69ff682de4638684801c78e0_14009bc9.png)

在 code-first 一侧，团队通常会选择开源框架和 harness。在 LangChain 生态中，这包括 [LangChain](https://www.langchain.com/langchain)、[LangGraph](https://www.langchain.com/langgraph) 和 [Deep Agents](https://www.langchain.com/deep-agents)。在 LangChain 之外，例子包括 CrewAI 和 Claude Agents SDK。

这些工具运行在技术栈的不同层。

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

**智能体运行时（Agent runtimes）**关注执行。它们支持需要状态、控制流、持久性和人工介入的智能体。在 LangChain 生态中，LangGraph 是最清晰的例子。它让你可以构建能够分支、循环、暂停、恢复并随时间持久化状态的智能体系统。

**智能体 harness（Agent harnesses）**关注“做事”。它们提供长时间运行任务所需的周边结构：prompt、skills、MCP servers、hooks、middleware，有时还包括文件系统。Deep Agents 和 Claude Agent SDK 都是这种模式的例子。

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

对于简单应用，它可能只需要定义一个工具调用循环。对于更复杂的智能体，它可能需要写 prompt、定义 skills、连接 MCP servers、配置 middleware，并设置智能体可以随时间检索或更新的上下文。

*No-code 构建*

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

[![构建阶段中的 no-code、low-code、hooks 和 middleware](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69ff682de4638684801c78dd_5f6458d6.png)](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69ff682de4638684801c78dd_5f6458d6.png)

与此同时，no-code 工具并不会消除工程控制的需要。随着系统变得更复杂，团队通常需要用代码扩展或覆盖行为。Hooks 和 middleware 在这里尤其重要，因为它们让团队可以围绕工具调用、上下文处理、审批、认证或业务规则添加自定义逻辑，而不必从头重建每个智能体。

最好的构建环境会让简单事情保持简单，也让复杂事情成为可能。它们允许领域专家编辑 prompt、skills 和上下文，同时仍然让工程师控制那些需要可靠、可测试、可治理的部分。

## 测试

在智能体部署之前，团队需要一种方式判断它是否真的准备好了。

这并不意味着要在任何人使用智能体之前先构建一套完美的 eval suite。实践中，这通常并不现实。它意味着至少要有足够的评测来捕捉明显失败、比较版本，并避免盲目发布变更。

[![测试阶段：用代表性任务数据集构建评测](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69ff682de4638684801c78d4_4627dcc1.png)](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69ff682de4638684801c78d4_4627dcc1.png)

大多数评测工作流会从一小组有代表性的任务数据集开始。有些例子来自预期用例，有些来自手动测试、dogfooding、支持工单、历史追踪或已知边界情况。随着时间推移，生产追踪会让这些数据集强得多，但测试应该在生产之前就开始。

*数据集和指标*

数据集是团队保存所学经验的方式。没有数据集，同样的失败往往会在 prompt 变更、模型升级或工具更新后再次出现。

合适的指标取决于任务。

有些情况下存在清晰的标准答案。智能体是否抽取了正确的值？是否选择了正确标签？是否更新了正确字段？这些任务可以直接按正确性衡量。

另一些情况下并没有唯一标准答案。智能体可能需要写回复、总结对话、决定是否升级，或通过多条有效路径完成任务。这时，团队更多依赖基于标准的评测。问题会变成：回复是否有依据？智能体是否遵守政策？是否请求了澄清？是否在没有不必要工具调用的情况下高效完成任务？

*实验*

实验把数据集和指标连接到迭代。它们允许团队在同一套评测集上比较 prompt、模型、检索策略、工具 schema 和编排模式。随着时间推移，这些实验会显示智能体是在改进还是在退步。

目标不是第一天就创建完美的 eval suite。目标是从一套有用的评测开始，并持续改进它。最有价值的评测数据集来自最难的例子：先来自开发和 dogfooding，之后来自生产。

*模拟*

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

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

语音智能体是一个明显例子，但这个模式更广。任何跨多个轮次运行的智能体都可能需要模拟。支持智能体可能需要处理沮丧的客户、追问问题、检查订单状态，并决定是否需要升级。编码智能体可能需要检查仓库、做修改、运行测试，并回应反馈。内部运营智能体可能需要先收集缺失信息再采取行动。

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

## 部署

智能体完成构建和评测后，需要一个可以可靠运行的环境。

对于简单智能体，部署可能类似传统应用部署。但许多智能体需要的不只是无状态服务器。它们会运行更长时间、调用工具、等待人工输入、写文件、从中断中恢复，并在多次交互或任务之间维护状态。

[![部署阶段：运行时支持长时间运行、工具调用和状态](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69ff682de4638684801c78d1_beca6459.png)](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69ff682de4638684801c78d1_beca6459.png)

这就是运行时重要的原因。

生产级智能体运行时通常需要支持持久执行和 human-in-the-loop（人在回路中）模式。持久执行意味着智能体可以为进度写入检查点，并在失败后恢复，而不是丢失工作。human-in-the-loop 意味着当智能体需要审批、澄清或审查时，可以暂停下来。

这方面有现成方案。[LangSmith Deployment](https://docs.langchain.com/langgraph-platform) 提供了部署和管理 Deep Agents 与 LangGraph 智能体的基础设施。AWS AgentCore 是另一个面向智能体的托管运行时例子。一些团队也会基于 Temporal 等系统构建自己的运行时，尤其是当它们已经在技术栈其他地方使用 Temporal 处理长时间运行工作流时。

*沙箱*

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

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

例子包括 [LangSmith Sandboxes](https://www.langchain.com/blog/introducing-langsmith-sandboxes-secure-code-execution-for-agents/)、Daytona 和 E2B。

并非每个智能体都需要完整沙箱。有些情况下，智能体只需要一个存取文件的地方。虚拟文件系统就足够了。Deep Agents 支持这种模式：允许智能体把文件当作工作记忆，而不一定要在沙箱中执行任意代码。底层文件系统可以由 Postgres 或 S3 等系统支撑。

*Context Hub*

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

智能体中一些最重要的部分并不是传统应用代码。Prompt、检索上下文、skills 和任务指令可能比应用本身变化更频繁。它们也可能需要由非工程师编辑。

这就产生了对 prompt 或上下文中心的需求：一个存储、版本化、审查和更新智能体非代码部分的地方。这让团队可以在不完整部署的情况下调整智能体行为，也让领域专家拥有他们最理解的上下文。

实践中，部署不只是把智能体放到服务器上。它是为智能体提供完成真实工作所需的运行时、执行环境和上下文管理系统。

## 监控

智能体部署后，团队需要看见它们在生产中实际如何行为。

这正是监控智能体与监控传统软件不同的地方。延迟、成本、错误率和 uptime 这类指标仍然重要，但它们只是图景的一部分。智能体可以返回一个技术上成功的响应，却仍然没有完成任务。它可能调用了错误工具、依赖了错误上下文、跳过了必需的审批步骤，或生成了听起来合理但其实错误的答案。

[![监控阶段：用追踪理解智能体失败](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69ff682de4638684801c78d7_8e9617a3.png)](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69ff682de4638684801c78d7_8e9617a3.png)

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

一条 trace 会捕获智能体的完整轨迹：它收到的输入、发起的模型调用、调用的工具、收到的输出，以及最终生成的响应或动作。这是理解智能体实际做了什么所需的细节层级。

这也是为什么我们认为[智能体可观测性驱动智能体评测](https://www.langchain.com/blog/agent-observability-powers-agent-evaluation)，以及为什么[智能体改进循环始于一条 trace](https://www.langchain.com/blog/traces-start-agent-improvement-loop)。如果你看不到轨迹，就无法可靠调试行为，也无法把这些失败转化为未来评测。

*信号*

监控还应该包括从这些 trace 中收集信号。

其中一些信号可以来自 LLM-as-judge 评测器。例如，judge 可以给智能体是否回答了用户问题、是否遵守政策、是否使用正确语气、是否完成任务打分。其他信号可以更简单。一个正则表达式可以检查必需短语是否出现、禁用工具是否被调用，或已知失败模式是否发生。

这些信号不只是质量检查。它们也可以成为一种产品分析。它们能告诉你用户在要求智能体完成哪些任务，智能体在哪里卡住，用户多久纠正一次它们，以及用户在哪里感知到错误。

*反馈*

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

只存储 trace 是不够的。团队还需要把反馈和这些 trace 一起存储。反馈可以来自 LLM judge、基于正则的信号、人工审查者，或通过 API 收集的直接用户反馈。例如在 LangSmith 中，团队可以把用户反馈直接附加到底层 run 上，从而更容易把“用户不满意”连接到“三步之前智能体用了错误工具”。

*仪表盘*

最后，团队需要能够呈现长期趋势的仪表盘和告警。

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

好的监控不只是知道系统是否在线。它是理解智能体是否以正确方式做正确工作，并且是否随时间改进。

最强的监控系统会直接反馈到评测中。重要 trace 会变成数据集样本，重复失败会变成指标，生产行为会成为下一轮改进的基础。

## 迭代

最好的组织会快速而系统地穿过智能体开发生命周期。

它们不会等到智能体完美之后才发布。相反，它们先构建有用的东西，做足够测试以理解其行为，以受控方式部署，监控它在生产中的表现，并把这些学习反馈到下一版。

这并不意味着草率发布。关键是要有可见性。

拥有数据集、实验、追踪、反馈和仪表盘的团队，可以直接从真实使用中学习。它们可以在广泛发布前测试变更，识别生产中哪里坏了，把失败转化为评测，并在不依赖猜测的情况下改进智能体。

这就是团队爬坡的方式，也是智能体系统随时间改进的方式。

最高效的团队会找到困难例子，理解智能体为什么失败，并调整 prompt、工具配置、检索策略、模型、middleware 或工作流。它们重新运行评测，部署更好的版本，而监控会继续给它们下一批边界情况和失败。

在企业内部，挑战是让这个循环可以跨团队重复。

如果每个团队都必须从头构建自己的评测框架、部署基础设施、追踪系统、反馈流水线和仪表盘，智能体开发就会变慢。最高效的组织会投资共享基础设施，让团队可以穿过生命周期，而不必不断重新发明底层系统。

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

## 治理

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

对于单个智能体，轻量控制可能就足够了。随着组织部署更多智能体，治理会变得必要。没有治理，团队很快会得到一批难以发现、难以监控、运行昂贵、权限边界不清的智能体。

[![治理阶段：管理智能体发现、成本、权限和风险](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69ff682de4638684801c78ce_1e0b2abf.png)](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69ff682de4638684801c78ce_1e0b2abf.png)

*成本*

第一个治理挑战是成本。

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

*工具访问*

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

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

这就是审计轨迹变得重要的地方。如果智能体调用了工具，组织应该能够检查是哪一个智能体发起了调用、用了什么输入、产生了什么输出，以及是什么用户或政策授权了这个动作。工具调用往往是智能体行为产生业务影响的地方，因此它们需要可观察、可审查。

Human-in-the-loop 是另一种重要治理机制。

不是每个工具调用都应该完全自动化。有些操作应该暂停并交给人审查，尤其是涉及客户、金融系统、敏感数据或生产基础设施时。Human-in-the-loop 工作流在从系统一开始就设计进去时效果最好。

*可发现性*

第三个治理挑战是可发现性和复用。

随着组织构建更多智能体，它们也会积累更多可复用资产，例如 prompt、skills、工具、检索来源、政策，甚至其他智能体。没有良好的发现和治理机制，团队往往会反复重建这些组件，导致不一致。共享上下文和共享智能体需要能够被找到、复用并治理。

这对 skills 尤其重要。一个 skill 可以编码一个工作流、一种写作风格、一个领域特定流程，或使用某个工具的指令。如果一个团队已经构建了很好的 skill，另一个团队就应该能找到它，而不是从头写一个新版本。

好的治理不是为了拖慢团队。它是为了让快速迭代成为可能，同时在智能体系统扩展时不失去可见性、控制力和一致性。

## 结论

最好的组织已经开始以这种方式运转。它们早早发布，但不会盲目发布。它们在部署前评测，在部署后监控行为，并持续用学到的东西让下一版更好。

这就是智能体开发变得可重复的原因。它也让智能体能够从 demo 进入可靠的生产系统。