第 7 部分：交付生产智能体
前面所有内容都是关于使用智能体来构建软件。本部分讲的是当你构建的东西本身就是一个智能体时的情况——客服机器人、研究助手、内部监控工具。这些不是你运行一次的脚本；它们是服务真实用户的产品，需要更坚实的底层支撑。
首先，明确你在构建什么
在开始之前，最有用的一个问题：
- 这是脚本吗？ 一次性自动化、个人工具、原型。智能体就是终点。你终端里的普通编码智能体就够了。
- 这是产品吗？ 真实用户依赖的东西。智能体现在是产品本身，它需要一套底层基础设施：专属工具、记忆、评估和部署基础设施。
混淆两者是原型意外上线的根本原因。在写任何东西之前，明确你在构建哪一种。
生产智能体需要而脚本不需要的四件事
当真实用户依赖智能体时，四件事不再是可选项：
- 跨会话的持久化记忆，让智能体不会每次都从零开始。
- 每个工具和数据源的作用域权限，确保智能体只能访问它应该访问的内容。
- 在 CI 中运行的评估覆盖，在回退发布之前捕获到它们（这是第 3 部分，应用于智能体本身）。
- 追踪智能体实际行为的可观测性，让生产行为可被审计（这是第 5 部分，应用于智能体本身）。
对于一次性脚本，这些都不值得付出这些努力。对于产品，在上线之后而非之前构建这些，是你最终得到一个难以维护、不可信赖的系统的原因。
从原型到生产，保持一套工作流
让这一切变得可行的转变：产出原型的那套基于终端的工作流，现在可以一路延伸到已部署的产品。你不需要学习另一套技术栈才能上生产。你描述你想要的，一个技能包（第 2 部分提到的那种）就能给你现有的编码智能体完整的生命周期能力——搭建脚手架、编写代码、评估、部署、接入可观测性——而无需新的 SDK。
从头到尾的循环，看起来像一次对话：
# one-time setup of the skills bundle, then, in your coding agent:
> Build a support agent that answers questions from our docs.
> Evaluate it against the FAQ dataset.
> Deploy it to the runtime.
在背后，智能体从模板搭建项目、编写代码、生成评估集、运行评估、部署，然后汇报结果。对于偏好直接操作的人，同样的步骤也可以作为普通 CLI 命令使用。结果是：昨天在你笔记本上运行的原型，今天成为服务用户的生产智能体，无需重写。
走向多智能体
当一个智能体不够用时，协调通过三种机制实现，在不同规模下使用：
- 共享会话状态——适用于智能体只需要看到相同上下文的简单场景。
- MCP（模型上下文协议）——智能体访问工具和外部服务的标准方式。
- A2A（Agent2Agent）——用于一个智能体将工作委派给另一个智能体。
这些机制可以组合成任何适合的模式：规划者将子任务分配给专家、并行工作者处理任务的不同部分、审查智能体检查构建智能体。瓶颈从编写实现转移到了规格说明每个智能体应做什么，以及验证它是否做到了——与本指南其余部分的主题一致，只是在更高一层。
搭建你自己的工作流
- 对于你下一个智能体，写一句话："这是脚本"或"这是产品"。由此决定你需要构建多少底层基础设施。
- 如果它是产品，添加四个必备要素：持久化记忆、作用域权限、CI 评估、运行追踪。
- 使用技能包，让构建 → 评估 → 部署 → 观测保持在一个工作流中。
- 如果你需要多个智能体，从共享状态开始；只有当协调确实需要时，才引入 MCP 和 A2A。