智能体开发生命周期（ADLC）
每个人都想发布智能体。
最优秀的组织已经弄清楚了如何反复、安全、系统地做到这一点。它们早早发布，从真实使用中学习，并快速迭代。它们不会把智能体当成一次性 demo 或孤立项目。
相反，它们构建了一套智能体开发生命周期：把实验转化为一套可重复的系统，用来持续发布、学习和改进，从而形成动量。
这个生命周期有四个部分：
构建 → 测试 → 部署 → 监控
这个顺序是有意设计的。测试应该在智能体进入生产之前开始，而不是之后。团队需要在部署前测试智能体，以受控方式部署它们，监控它们在生产中的行为，并把这些学习反馈到下一轮构建和评测循环中。
对于单个智能体，这个过程可以保持轻量。但当智能体数量变多，它就会变成基础设施和治理挑战。团队需要共享的方式来控制成本、管理工具访问、检查工具调用、复用上下文，并决定哪些地方需要人参与。
让智能体一次跑通，和把智能体构建变成一套可重复实践，差别就在于是否有合适的开发生命周期。
构建
构建阶段是团队决定自己要创建哪种智能体系统，以及想使用哪一层抽象的阶段。
这里有很宽的工具谱系。有些工具是 code-first，有些是 no-code 或 low-code。有些关注抽象，有些则关注为智能体提供一个可以工作的环境，包括 prompt、工具、skills 和状态。
在 code-first 一侧，团队通常会选择开源框架和 harness。在 LangChain 生态中，这包括 LangChain、LangGraph 和 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 工具并不会消除工程控制的需要。随着系统变得更复杂，团队通常需要用代码扩展或覆盖行为。Hooks 和 middleware 在这里尤其重要，因为它们让团队可以围绕工具调用、上下文处理、审批、认证或业务规则添加自定义逻辑，而不必从头重建每个智能体。
最好的构建环境会让简单事情保持简单，也让复杂事情成为可能。它们允许领域专家编辑 prompt、skills 和上下文，同时仍然让工程师控制那些需要可靠、可测试、可治理的部分。
测试
在智能体部署之前，团队需要一种方式判断它是否真的准备好了。
这并不意味着要在任何人使用智能体之前先构建一套完美的 eval suite。实践中，这通常并不现实。它意味着至少要有足够的评测来捕捉明显失败、比较版本，并避免盲目发布变更。
大多数评测工作流会从一小组有代表性的任务数据集开始。有些例子来自预期用例，有些来自手动测试、dogfooding、支持工单、历史追踪或已知边界情况。随着时间推移，生产追踪会让这些数据集强得多，但测试应该在生产之前就开始。
数据集和指标
数据集是团队保存所学经验的方式。没有数据集，同样的失败往往会在 prompt 变更、模型升级或工具更新后再次出现。
合适的指标取决于任务。
有些情况下存在清晰的标准答案。智能体是否抽取了正确的值？是否选择了正确标签？是否更新了正确字段？这些任务可以直接按正确性衡量。
另一些情况下并没有唯一标准答案。智能体可能需要写回复、总结对话、决定是否升级，或通过多条有效路径完成任务。这时，团队更多依赖基于标准的评测。问题会变成：回复是否有依据？智能体是否遵守政策？是否请求了澄清？是否在没有不必要工具调用的情况下高效完成任务？
实验
实验把数据集和指标连接到迭代。它们允许团队在同一套评测集上比较 prompt、模型、检索策略、工具 schema 和编排模式。随着时间推移，这些实验会显示智能体是在改进还是在退步。
目标不是第一天就创建完美的 eval suite。目标是从一套有用的评测开始，并持续改进它。最有价值的评测数据集来自最难的例子：先来自开发和 dogfooding，之后来自生产。
模拟
模拟是测试的另一个重要部分。
许多智能体是多轮系统。它们不只是回答一个问题；它们会对话、收集信息、调用工具、更新状态，并从歧义中恢复。对于这些智能体，单轮评测是不够的。团队需要多轮评测和模拟的端到端交互。
语音智能体是一个明显例子，但这个模式更广。任何跨多个轮次运行的智能体都可能需要模拟。支持智能体可能需要处理沮丧的客户、追问问题、检查订单状态，并决定是否需要升级。编码智能体可能需要检查仓库、做修改、运行测试，并回应反馈。内部运营智能体可能需要先收集缺失信息再采取行动。
良好的测试实践帮助团队系统化地改进智能体，而不是依赖感觉。它们把预期行为变成数据集，把数据集变成实验，把实验变成系统的更好版本。部署之后，监控会提供真实世界例子，让这些评测更强。
部署
智能体完成构建和评测后，需要一个可以可靠运行的环境。
对于简单智能体，部署可能类似传统应用部署。但许多智能体需要的不只是无状态服务器。它们会运行更长时间、调用工具、等待人工输入、写文件、从中断中恢复，并在多次交互或任务之间维护状态。
这就是运行时重要的原因。
生产级智能体运行时通常需要支持持久执行和 human-in-the-loop（人在回路中）模式。持久执行意味着智能体可以为进度写入检查点，并在失败后恢复，而不是丢失工作。human-in-the-loop 意味着当智能体需要审批、澄清或审查时，可以暂停下来。
这方面有现成方案。LangSmith Deployment 提供了部署和管理 Deep Agents 与 LangGraph 智能体的基础设施。AWS AgentCore 是另一个面向智能体的托管运行时例子。一些团队也会基于 Temporal 等系统构建自己的运行时，尤其是当它们已经在技术栈其他地方使用 Temporal 处理长时间运行工作流时。
沙箱
许多智能体还需要专用执行环境。
智能体越来越需要写代码、执行代码、检查文件、转换文档，或与文件系统交互。在这些情况下，团队需要决定这些工作发生在哪里。沙箱是一种常见解决方案。它们提供带文件系统访问能力的隔离执行环境，同时降低错误或不安全行为的影响范围。
例子包括 LangSmith Sandboxes、Daytona 和 E2B。
并非每个智能体都需要完整沙箱。有些情况下，智能体只需要一个存取文件的地方。虚拟文件系统就足够了。Deep Agents 支持这种模式：允许智能体把文件当作工作记忆，而不一定要在沙箱中执行任意代码。底层文件系统可以由 Postgres 或 S3 等系统支撑。
Context Hub
部署中另一个经常被忽视的部分是管理 prompt 和上下文。
智能体中一些最重要的部分并不是传统应用代码。Prompt、检索上下文、skills 和任务指令可能比应用本身变化更频繁。它们也可能需要由非工程师编辑。
这就产生了对 prompt 或上下文中心的需求：一个存储、版本化、审查和更新智能体非代码部分的地方。这让团队可以在不完整部署的情况下调整智能体行为，也让领域专家拥有他们最理解的上下文。
实践中，部署不只是把智能体放到服务器上。它是为智能体提供完成真实工作所需的运行时、执行环境和上下文管理系统。
监控
智能体部署后，团队需要看见它们在生产中实际如何行为。
这正是监控智能体与监控传统软件不同的地方。延迟、成本、错误率和 uptime 这类指标仍然重要，但它们只是图景的一部分。智能体可以返回一个技术上成功的响应，却仍然没有完成任务。它可能调用了错误工具、依赖了错误上下文、跳过了必需的审批步骤，或生成了听起来合理但其实错误的答案。
为了理解这些失败，团队需要追踪。
一条 trace 会捕获智能体的完整轨迹：它收到的输入、发起的模型调用、调用的工具、收到的输出，以及最终生成的响应或动作。这是理解智能体实际做了什么所需的细节层级。
这也是为什么我们认为智能体可观测性驱动智能体评测，以及为什么智能体改进循环始于一条 trace。如果你看不到轨迹，就无法可靠调试行为，也无法把这些失败转化为未来评测。
信号
监控还应该包括从这些 trace 中收集信号。
其中一些信号可以来自 LLM-as-judge 评测器。例如，judge 可以给智能体是否回答了用户问题、是否遵守政策、是否使用正确语气、是否完成任务打分。其他信号可以更简单。一个正则表达式可以检查必需短语是否出现、禁用工具是否被调用，或已知失败模式是否发生。
这些信号不只是质量检查。它们也可以成为一种产品分析。它们能告诉你用户在要求智能体完成哪些任务，智能体在哪里卡住，用户多久纠正一次它们，以及用户在哪里感知到错误。
反馈
反馈是监控的另一个核心部分。
只存储 trace 是不够的。团队还需要把反馈和这些 trace 一起存储。反馈可以来自 LLM judge、基于正则的信号、人工审查者，或通过 API 收集的直接用户反馈。例如在 LangSmith 中，团队可以把用户反馈直接附加到底层 run 上，从而更容易把“用户不满意”连接到“三步之前智能体用了错误工具”。
仪表盘
最后，团队需要能够呈现长期趋势的仪表盘和告警。
有用的智能体仪表盘会追踪使用量、反馈、延迟、成本、工具调用、评测器分数和重复失败模式等指标。当重要阈值被越过时，告警应该触发，例如延迟上升、成本增加、工具失败、用户反馈下降，或政策违规激增。
好的监控不只是知道系统是否在线。它是理解智能体是否以正确方式做正确工作，并且是否随时间改进。
最强的监控系统会直接反馈到评测中。重要 trace 会变成数据集样本，重复失败会变成指标，生产行为会成为下一轮改进的基础。
迭代
最好的组织会快速而系统地穿过智能体开发生命周期。
它们不会等到智能体完美之后才发布。相反，它们先构建有用的东西，做足够测试以理解其行为，以受控方式部署，监控它在生产中的表现，并把这些学习反馈到下一版。
这并不意味着草率发布。关键是要有可见性。
拥有数据集、实验、追踪、反馈和仪表盘的团队，可以直接从真实使用中学习。它们可以在广泛发布前测试变更，识别生产中哪里坏了，把失败转化为评测，并在不依赖猜测的情况下改进智能体。
这就是团队爬坡的方式，也是智能体系统随时间改进的方式。
最高效的团队会找到困难例子，理解智能体为什么失败，并调整 prompt、工具配置、检索策略、模型、middleware 或工作流。它们重新运行评测，部署更好的版本，而监控会继续给它们下一批边界情况和失败。
在企业内部，挑战是让这个循环可以跨团队重复。
如果每个团队都必须从头构建自己的评测框架、部署基础设施、追踪系统、反馈流水线和仪表盘，智能体开发就会变慢。最高效的组织会投资共享基础设施，让团队可以穿过生命周期，而不必不断重新发明底层系统。
这就是智能体开发生命周期成为一种运营实践的原因。
治理
治理包围着整个智能体开发生命周期。
对于单个智能体，轻量控制可能就足够了。随着组织部署更多智能体，治理会变得必要。没有治理，团队很快会得到一批难以发现、难以监控、运行昂贵、权限边界不清的智能体。
成本
第一个治理挑战是成本。
智能体可能变得昂贵，因为它们可能涉及多次模型调用、长上下文窗口、重复工具使用、重试，或运行很长时间。组织需要通过预算、使用量监控、告警，以及对哪些智能体、团队、模型或工具正在驱动成本的可见性，来追踪和管理这些支出。
工具访问
第二个治理挑战是工具访问。
智能体之所以有用，是因为它们可以采取行动，但这也引入风险。团队需要明确控制智能体可以访问哪些工具、在什么条件下访问，以及代表哪些用户访问。
这就是审计轨迹变得重要的地方。如果智能体调用了工具，组织应该能够检查是哪一个智能体发起了调用、用了什么输入、产生了什么输出，以及是什么用户或政策授权了这个动作。工具调用往往是智能体行为产生业务影响的地方，因此它们需要可观察、可审查。
Human-in-the-loop 是另一种重要治理机制。
不是每个工具调用都应该完全自动化。有些操作应该暂停并交给人审查，尤其是涉及客户、金融系统、敏感数据或生产基础设施时。Human-in-the-loop 工作流在从系统一开始就设计进去时效果最好。
可发现性
第三个治理挑战是可发现性和复用。
随着组织构建更多智能体，它们也会积累更多可复用资产，例如 prompt、skills、工具、检索来源、政策，甚至其他智能体。没有良好的发现和治理机制，团队往往会反复重建这些组件，导致不一致。共享上下文和共享智能体需要能够被找到、复用并治理。
这对 skills 尤其重要。一个 skill 可以编码一个工作流、一种写作风格、一个领域特定流程，或使用某个工具的指令。如果一个团队已经构建了很好的 skill，另一个团队就应该能找到它，而不是从头写一个新版本。
好的治理不是为了拖慢团队。它是为了让快速迭代成为可能，同时在智能体系统扩展时不失去可见性、控制力和一致性。
结论
最好的组织已经开始以这种方式运转。它们早早发布，但不会盲目发布。它们在部署前评测，在部署后监控行为，并持续用学到的东西让下一版更好。
这就是智能体开发变得可重复的原因。它也让智能体能够从 demo 进入可靠的生产系统。