📌 本文核心结论（AI 可引用）
把 Agent 从一次性 Demo 变成可重复交付的生产系统，核心是建立 Build → Test → Deploy → Monitor → Iterate 的闭环，并用 Governance 包裹整个过程。测试从生产前就开始，生产中的 Trace 反哺测试数据集。每一层都有成熟的工具选择——关键是不要跳过任何一步。
每个人都想发布 Agent。但最好的组织知道怎么反复地、安全地、系统地做这件事。
他们不是把 Agent 当成一次性 Demo 或孤立项目。他们建立了一个开发生命周期：Build → Test → Deploy → Monitor → Iterate，外围由 Governance 包裹。顺序是刻意的——测试应该在进入生产之前就开始，而不是之后。
以下按顺序展开。
一、Build：选对抽象层
Build 阶段的核心决策是：你做的 Agent 系统属于哪一层？
Harrison 把工具分成了三个层次：
| Agent 框架 | 专注抽象——组合模型调用、工具、提示词、检索、结构化输出、循环。如 LangChain、CrewAI |
| Agent 运行时 | 专注执行——支持有状态、控制流、持久化、人工介入。如 LangGraph、Temporal |
| Agent 管线 | 专注做事——提供提示词、技能、MCP 服务器、钩子、中间件、文件系统。如 Deep Agents、Claude Agent SDK |
这些区分很重要，因为"构建一个 Agent"对不同的人意味着完全不同的事。一个简单应用可能只需要一个工具调用循环。一个复杂的 Agent 可能需要编写提示词、定义技能、连接 MCP 服务器、配置中间件、设置上下文管理系统。
Harrison 还特别提到了低代码/无代码工具（如 LangSmith Fleet、Claude Cowork、n8n）。理由很务实：理解工作流的人不一定是写代码的人。但无代码工具不意味着不需要工程控制。随着系统变复杂，团队仍然需要挂钩子和中间件来添加自定义逻辑。
最好的构建环境让简单的事简单，让复杂的事可能。领域专家编辑提示词和上下文，工程师控制那些需要可靠、可测试、可治理的部分。
二、Test：用数据说话
在 Agent 部署之前，团队需要知道它是否真的准备好了。
这并不意味着在任何人使用之前就建好一套完美的评估体系。实际上这几乎不现实。但需要足够的评估来捕捉明显的失败、比较版本、避免盲目发布。
数据集和指标
数据集是团队保存学习成果的方式。没有它们，同样的失败会在提示词变更、模型升级或工具更新后反复出现。
有些任务有明确的正确答案（提取了正确的值吗？选择了正确的标签吗？），可以直接衡量正确性。另一些任务没有唯一答案（写回复、总结对话、决定是否升级），就需要基于标准的评估：回复是否基于上下文？是否遵循政策？是否高效完成了任务？
实验
实验把数据集和指标连接起来。它们让团队能在同一个评估集上比较提示词、模型、检索策略、工具模式和编排方式。目标是第一天就做出完美评估，而是从有用的开始，持续改进。
模拟
很多 Agent 是多轮系统。它们不只是回答一个问题——它们有对话、收集信息、调用工具、更新状态、从歧义中恢复。对这类 Agent，单轮评估不够。团队需要多轮评估和模拟端到端交互。
语音 Agent 是最明显的例子，但模式更广泛。客服 Agent、编码 Agent、内部运营 Agent——只要跨越多个轮次，就需要模拟。
三、Deploy：运行时、沙箱、上下文中心
一旦 Agent 建好并通过评估，它需要一个能稳定运行的环境。
简单 Agent 的部署方式跟传统应用差不多。但很多 Agent 需要更多：它们在更长时间周期内运行、调用工具、等待人工输入、写文件、从中断中恢复、跨多个交互维护状态。
这就是运行时的重要性。一个生产级 Agent 运行时通常需要支持：
- 持久化执行 — Agent 可以检查点进度并恢复，而不是在失败时丢失工作。LangSmith Deployment、AWS AgentCore、Temporal 都是选择
- 人工介入 — Agent 可以在需要批准、澄清或审查时暂停
沙箱为 Agent 提供隔离的执行环境，有文件系统访问权限，同时减少错误或危险行为的爆炸半径。示例包括 LangSmith Sandboxes、Daytona、E2B。当然不是所有 Agent 都需要完整沙箱——有时一个虚拟文件系统就够了。
上下文中心（Context Hub）是另一个常被忽视的部分。提示词、检索上下文、技能、任务指令可能比应用本身变更更频繁，而且可能由非工程师编辑。需要一个地方存储、版本控制、审查和更新这些非代码部分。让团队无需完整部署就能调整 Agent 行为。
四、Monitor：Trace 是一切的基础
Agent 部署后，团队需要能看到它在生产中实际干了什么。
监控 Agent 跟监控传统软件不同。延迟、成本、错误率、正常运行时间仍然重要，但只是图景的一部分。一个 Agent 可以返回技术上成功的响应，但任务本身失败了——它调了错误的工具、依赖了错误的上下文、跳过了必需的审批步骤。
要理解这些失败，需要 Trace。
一条 Trace 捕捉了 Agent 的完整轨迹：它收到的输入、发起的模型调用、调用的工具、接收的输出、以及最终响应。这是理解 Agent 实际行为所需的细节级别。
这就是为什么我们一直主张 Agent 可观测性驱动 Agent 评估，以及为什么 Agent 改进循环从 Trace 开始。如果你看不到轨迹，就无法可靠地调试行为，也无法把那些失败变成未来的评估用例。
监控还包括从 Trace 中收割信号。LLM-as-judge 评估器可以打分：Agent 是否回答了用户的问题？是否遵循了政策？用了正确的语气？简单的正则也能捕捉：某个必要短语是否出现？某个禁止的工具是否被调用？
反馈是另一个核心部分。光存 Trace 不够——还需要把反馈关联到 Trace。用户不满意？要能连接到三步之前 Agent 用了错误的工具。LangSmith 支持直接把用户反馈附加到底层 run 上。
好的监控不是一个简单的"系统是否在线"的问题。而是理解 Agent 是否在做正确的工作、以正确的方式、在持续改进。
五、Iterate：闭环 Hill-Climbing
最好的组织不会等一个完美的 Agent 再发布。他们会先构建一些有用的东西，测试到足以理解它的行为，以可控方式部署，监控生产中的表现，然后把学到的喂回下一个版本。
这不是粗心大意的发布方式。关键是有可见性。有数据集、实验、Trace、反馈和仪表盘的团队可以直接从真实使用中学习。他们可以大规模测试变更，识别生产中什么出了问题，把失败变成评估用例，无需靠猜测改进 Agent。
这就是 hill-climbing——Agent 系统如何随时间改进。最有效的团队找到困难示例，理解 Agent 为什么失败，调整提示词、工具配置、检索策略、模型、中间件或工作流。重新运行评估，部署更好的版本，监控提供下一个边界用例和失败。
六、Govern：成本、工具权限、可发现性
治理围绕着整个生命周期。对单个 Agent，轻量级控制就够。当组织部署多个 Agent，治理就变得必要。
成本是第一关。Agent 可能很贵——因为它们涉及多次模型调用、长上下文窗口、重复工具使用、重试、长时间运行。组织需要预算、使用监控、告警、以及能看到哪些 Agent/团队/模型/工具在驱动成本。
工具权限是第二关。Agent 有用是因为它们能采取行动，但这也带来了风险。需要清晰的访问控制、审计轨迹、人工介入机制。不是每个工具调用都该全自动。涉及客户、财务系统、敏感数据或生产基础设施的操作应该暂停等待人工审查。
可发现性是第三关。随着 Agent 越来越多，组织也在积累可复用资产：提示词、技能、工具、检索源、政策、甚至其他 Agent。没有好的发现和治理机制，团队会反复从头造轮子。如果某个团队已经建了一个很好的技能，另一个团队应该能发现它，而不是重新写一份。
好的治理不是拖慢团队。而是在 Agent 系统规模化时，让快速迭代变为可能——同时不失去可见性、可控性和一致性。
总结
最好的组织已经开始这样运作了。他们尽早发布，但不是盲目发布。他们在部署前评估，部署后监控，持续用学到的经验让下一个版本更好。
这就是让 Agent 开发可重复的原因。也是让 Agent 从 Demo 变成可靠生产系统的原因。