核心框架：Build → Test → Deploy → Monitor
最好的组织已经 figured out 如何反复、安全、系统地 ship agents。他们不是把 agent 当作一次性 demo 或孤立项目，而是建立了一个Agent 开发生命周期，将实验转化为可重复的 ship、学习和改进系统。
四个阶段：
- Build（构建）：决定创建什么类型的 agent 系统，使用什么抽象层级
- Test（测试）：在 agent 到达生产环境前开始测试
- Deploy（部署）：以受控方式部署
- Monitor（监控）：观察生产环境中的行为，将学习反馈到下一轮构建
顺序是刻意的——测试应该在 agent 到达生产环境之前开始，而不是之后。
Build 阶段：三层工具栈
"构建 agent"可以意味着不同的事情。Harrison Chase 将工具栈分为三个层级：
Agent Frameworks（框架层）
聚焦抽象。帮助开发者组合模型调用、工具、prompt、检索、结构化输出和 agent 循环。
- LangChain、CrewAI：提供组合这些元素的方式
Agent Runtimes（运行时层）
聚焦执行。支持需要状态、控制流、持久性和人工干预的 agent。
- LangGraph：构建可分支、循环、暂停、恢复和持久化状态的 agentic 系统
Agent Harnesses（环境层）
聚焦做事。为长时间运行任务提供周围结构：prompts、skills、MCP 服务器、hooks、中间件，有时还有文件系统。
- Deep Agents、Claude Agent SDK
No-code / Low-code
工具如 LangSmith Fleet、Claude Cowork、n8n 允许更多人参与 agent 开发。理解工作流的人不一定是写代码的人。
但 no-code 不消除工程控制的需求。随着系统变复杂，团队需要 hooks 和中间件来扩展或覆盖行为——在工具调用、上下文处理、审批、认证或业务规则周围添加自定义逻辑，无需从头重建每个 agent。
最好的构建环境让简单的事简单，复杂的事可能。
Test 阶段：数据集、实验和模拟
数据集和指标
数据集是团队保存所学知识的方式。没有它们，同样的失败会在 prompt 变更、模型升级或工具更新后重新出现。
指标类型：
- 明确答案：agent 是否提取了正确的值？选择了正确的标签？更新了正确的字段？
- 无单一答案：agent 是否需要写回复、总结对话、决定是否升级？此时依赖基于标准的评估——回复是否有依据？是否遵循政策？是否请求澄清？是否高效完成？
实验
实验连接数据集和指标，允许团队比较 prompts、模型、检索策略、工具 schema 和编排模式。目标不是第一天创建完美的 eval 套件，而是从一个有用的开始并持续改进。
最有价值的 eval 数据集来自最难的示例：先来自开发和 dogfooding，后来自生产环境。
模拟
许多 agent 是多轮系统——它们不只是回答一个问题，而是进行对话、收集信息、调用工具、更新状态、从歧义中恢复。单轮 eval 不够，需要多轮 eval 和模拟端到端交互。
- 语音 agent
- 支持 agent：处理沮丧客户、问跟进问题、检查订单状态、决定是否升级
- 编码 agent：检查仓库、做更改、运行测试、响应反馈
- 内部运营 agent：在采取行动前收集缺失信息
Deploy 阶段：运行时、沙箱和上下文中心
运行时
生产 agent 运行时通常需要支持：
- 持久执行：agent 可以 checkpoint 进度并在失败时恢复
- 人工介入：agent 可以在需要审批、澄清或审查时暂停
现有解决方案：
- LangGraph Platform：部署和管理 Deep Agents 和 LangGraph agents
- AWS AgentCore：托管运行时
- Temporal：用于长时间运行工作流
沙箱
Agent increasingly 需要写代码、执行代码、检查文件、转换文档或与文件系统交互。沙箱提供隔离执行环境，减少错误或危险行为的爆炸半径。
- E2B、Daytona
并非每个 agent 都需要完整沙箱。有时虚拟文件系统就够了——Deep Agents 允许 agent 使用文件作为工作记忆，无需在沙箱内执行任意代码。
上下文中心（Context Hub）
部署中经常被忽视的部分：管理 prompts 和上下文。
Prompts、检索上下文、skills 和任务指令可能比应用本身更频繁变更，也可能需要非工程师编辑。这需要prompt 或上下文中心：存储、版本、审查和更新 agent 的非代码部分。
这让团队无需完整部署即可调整 agent 行为，并让领域专家拥有他们最理解的上下文。
Monitor 阶段：追踪、信号、反馈和仪表盘
追踪（Traces）
监控 agent 与传统软件不同。延迟、成本、错误率和正常运行时间仍然重要，但只是部分图景。Agent 可以返回技术上成功的响应，但仍然失败——调用了错误工具、依赖错误上下文、跳过必要审批步骤，或产生听起来合理但错误的答案。
追踪捕获 agent 的完整轨迹：输入、模型调用、工具调用、输出、最终响应或行动。这是理解 agent 实际做了什么所需的详细程度。
如果你看不到轨迹，你就无法可靠地调试行为或将失败转化为未来的 evals。
信号（Signals）
从追踪中收获信号：
- LLM-as-judge：评分 agent 是否回答了用户问题、遵循政策、使用正确语气、完成任务
- 简单信号：regex 捕获是否出现必要短语、是否调用了禁止工具、是否出现已知失败模式
这些信号不仅是质量检查，还可以成为产品分析——用户要求 agent 做什么任务、agent 在哪里卡住、用户多久纠正一次、用户在哪里感知错误。
反馈（Feedback）
仅存储追踪不够，还需要存储反馈。反馈来源：
- LLM judges
- Regex-based signals
- 人工审查员
- 通过 API 收集的直接用户反馈
在 LangSmith 中，团队可以将用户反馈直接附加到底层 run，更容易连接"用户不高兴"和"agent 三步前使用了错误工具"。
仪表盘和告警
有用的 agent 仪表盘追踪：使用量、反馈、延迟、成本、工具调用、评估器分数、重复失败模式。
告警应在重要阈值被突破时触发：延迟上升、成本增加、工具失败、用户反馈下降、政策违规激增。
好的监控不只是知道系统是否在线，而是理解 agent 是否在做正确的工作、以正确的方式、并随时间改进。
最强的监控系统直接反馈到评估中：重要追踪成为数据集示例，重复失败成为指标，生产行为成为下一轮改进的基础。
治理：成本、工具访问、可发现性
随着组织部署更多 agent，治理变得必要。否则团队很快会面临难以发现、难以监控、运行昂贵、权限不清的 agent。
成本治理
Agent 可能涉及多次模型调用、长上下文窗口、重复工具使用、重试或长时间运行。组织需要通过预算、使用监控、告警和可见性来跟踪和管理支出。
工具访问治理
Agent 能采取行动带来风险。团队需要清晰控制：
- 哪些工具 agent 可以访问
- 在什么条件下
- 代表哪些用户
审计追踪很重要：哪个 agent 做了调用、使用了什么输入、产生了什么输出、什么用户或政策授权了该行动。
人工介入（Human-in-the-loop）是另一个重要治理机制。并非每个工具调用都应完全自动化——涉及客户、财务系统、敏感数据或生产基础设施的操作应暂停等待人工审查。
可发现性和复用
随着组织构建更多 agent，会积累可复用资产：prompts、skills、工具、检索来源、政策，甚至其他 agent。没有好的发现和治理机制，团队会反复重建这些组件，导致不一致。
Skills 尤其重要。Skill 可以编码工作流、写作风格、领域特定程序或工具使用说明。如果一个团队已经构建了好的 skill，另一个团队应该能找到它，而不是从头写新版本。
好的治理不是减慢团队速度，而是让快速迭代在不失去可见性、控制或一致性的情况下成为可能。
关键要点
- 不要等待完美 agent 才 ship：构建有用的东西，足够测试理解其行为，受控部署，监控生产表现，将学习反馈到下一版本
- 可见性是关键：有数据集、实验、追踪、反馈和仪表盘的团队可以直接从真实使用中学习
- 共享基础设施：如果每个团队都必须从头构建自己的评估框架、部署基础设施、追踪系统，agent 开发会很慢
- 治理是使快速迭代不失去控制的机制：成本、工具访问、可发现性三大挑战
- 最难的示例最有价值：从开发和 dogfooding 中获取，后来自生产环境
最好的组织已经这样运作了：早 ship，但不盲目 ship。部署前评估，部署后监控，持续使用所学让下一版本更好。这就是让 agent 开发可重复、让 agent 从 demo 进入可靠生产系统的方法。