目标：把十个项目中反复出现的工程经验抽象出来，形成可复用的生产级 Agent 开发原则。
14.0 一个 Demo 上线的头七
先讲一个你可能很熟悉的故事。
你花了两周，把书里的客服 Agent 改吧改吧，部署上线了。第一天一切美好——演示流畅，回答惊艳，老板当场拍板扩量。你美滋滋地回家睡了一觉。
第二天，噩梦开始了。
先是财务冲进来：昨晚一个用户连问了 200 轮，每轮都带着巨长的历史，一晚上烧掉了四位数的美金。你查了日志，发现 Agent 把全部对话历史每次都原样塞进 prompt——成本从第一天就埋了雷。
紧接着是用户投诉：响应太慢，转圈 30 秒没动静，人家以为坏了直接关页面。你打开前端一看，Agent 正老老实实地串行调三个工具，一个等一个，期间什么反馈都没有。
然后是法务找上门：Agent 给一个用户回了句“我们已经为您办理了退款”，但其实根本没有这回事——它编的。用户拿着截图来要钱。
最后是安全那边发了一封措辞严厉的邮件：有人构造了一段输入，让 Agent 调用了删除接口，差点把测试库清了。
成本、延迟、幻觉、安全，轮番毒打，一周没消停。
💡 顿悟时刻：Demo 和生产之间，隔的不是“再多写点代码”，而是六道看不见的关。Demo 只要“能跑通主流程”；生产要“在异常、恶意、规模化下依然不出事”。
这一章，就把这血淋淋的一周，整理成上线前必须过的六道关：成本、延迟、安全、评估、可观测、护栏。每道关都有它独特的痛感，也都有对症的解药。
第一关：成本控制
14.1 成本控制
大模型调用按 Token 计费，Agent 又天然会多轮调用工具——这意味着成本不是“调一次模型的钱”，而是“一轮对话里所有调用的钱的累加”，而且常常是指数级地累加。成本必须从一开始就设计，事后补救往往为时已晚。
实践建议
| 策略 | 说明 |
|---|---|
| 模型分层 | 简单任务用 Haiku，复杂推理用 Sonnet/Opus |
| 上下文裁剪 | 不把所有历史都塞进 prompt |
| RAG 精准召回 | top_k 不宜过大，减少无关上下文 |
| 工具结果摘要 | 大结果先摘要，再喂给模型 |
| 缓存 | 对重复问题、固定政策、静态资料做缓存 |
心路历程：为什么流控要在调模型之前拒绝
很多新手的第一反应是：成本超了，那我事后统计一下，超了就告警。这条路走下来你会发现——告警响的时候，钱已经花出去了。
你接着想：那我设个预算，超了就拒绝。可问题是，在哪一步拒绝？
如果你在“模型已经返回结果”之后才判断预算，那这一次调用的钱已经付了，拒绝毫无意义，顶多省下一次调用。你真正想拦的是“这次调用根本别发生”。
于是结论很反直觉：流控（限流、预算熔断）必须做在调用模型之前。在请求还没发出去的那一刻，先看预算余额、看并发数、看租户配额——不够，就直接拒绝，连 HTTP 请求都不发。这才叫省钱。
⚠️ 避坑：成本控制最容易踩的坑，是“上下文无限增长”。一个长会话里，每一轮都把全部历史塞进去，第 N 轮的 prompt 长度是 O(N²) 级别的累加。你不裁剪，就是在给云厂商送钱。
第二关：延迟优化
14.2 延迟优化
用户能接受 Agent 慢一点，但不能接受完全没反馈。这是延迟这条关的核心矛盾：慢不可怕，静才可怕。
想想等电梯：你宁愿电梯显示“正在到达，约 10 秒”，也不愿意盯着一个毫无反应的按钮干等。人对“有进展”的容忍度，远远高于对“无信号”的容忍度。
实践：
- 用 SSE 推送中间状态。
- 多 Agent 可并行的节点并行执行。
- 长耗时工具设置超时和重试。
- 前端展示“正在检索/正在调用工具/正在生成报告”。
💡 顿悟时刻：延迟优化的第一性原理不是“让总时间变短”，而是“让用户感知到的等待变短”。流式输出和阶段性状态，本质是在用“可见的进展”对冲“真实的耗时”。同样是 8 秒，全程转圈和“检索中…调工具中…生成中…”的体感天差地别。
第三关：安全与权限
14.3 安全与权限
Agent 能调用工具，也就意味着它能造成真实影响。这是 Agent 区别于普通聊天机器人的本质：它有手，不只是有嘴。有嘴顶多说错话，有手能删库、能发钱、能外发数据。
所以第一条铁律：必须区分读操作和写操作。
| 操作 | 建议 |
|---|---|
| 读文件/查数据库 | 可自动执行，但需审计 |
| 发邮件/创建订单 | 默认需要人工确认 |
| 删除/付款/外发数据 | 默认禁止或强确认 |
| 修改生产数据 | 必须审批 |
工具设计原则
- 最小权限：工具只暴露必要参数。
- 幂等性：重复调用不会造成严重后果。
- 可回滚：危险操作要有撤销方案。
- 可审计：记录谁在什么时候调用了什么工具。
心路历程：为什么不能只靠 Prompt 防幻觉与越权
出事之后，很多人的第一反应是：我在 prompt 里加一句“请不要编造信息，请不要执行危险操作”，问题不就解决了吗？
你试了。当天的演示里，它确实很乖。然后一个稍微“皮”一点的用户，换了个说法绕了它一圈，它就老老实实地照办了危险操作——因为 prompt 是软约束，它请求模型“请你别做”，但模型完全可以不听，尤其在被精心构造的输入诱导时。
你这时才意识到：prompt 是建议，不是围墙。真正的围墙得是硬约束——
- 想防越权？在工具层做权限校验，模型说调就调？先过权限这关。
- 想防幻觉？让模型只能基于检索回来的事实回答，关键结论做事实校验，甚至交叉验证。
- 想防删库？危险工具默认禁用，要人工确认才能放行，模型再怎么喊也不顶用。
⚠️ 避坑：永远假设 prompt 会被绕过。把安全建立在代码和权限层，而不是模型的“听话程度”上。
第四关：评估体系
14.4 评估体系
Agent 不能只靠“看起来不错”评估。“看起来不错”是开发者的主观幻觉，用户的真实场景千奇百怪，你以为完美的回答，换个问法可能就崩。
至少要有三层评估：
- 工具单元测试：离线可运行。
- 端到端集成测试：调用真实模型验证主流程。
- 效果评估集：一组真实用户问题，定期回归。
评价指标
| 指标 | 含义 |
|---|---|
| 准确率 | 回答是否正确 |
| 工具调用率 | 该调用工具时是否调用 |
| 幻觉率 | 是否编造不存在信息 |
| 成本 | 每次任务平均 Token/费用 |
| 延迟 | 用户等待时间 |
| 成功率 | 任务最终完成比例 |
心路历程：为什么评估必须“定期回归”，而不是“上线前测一次”
你可能觉得：我上线前把评估集跑一遍，全绿了，不就行了？
行——直到你某天为了优化 prompt 改了一行系统提示，自以为是无害的小改动，结果幻觉率悄悄从 2% 飙到 15%。你却浑然不知，因为没人再跑评估集了。
模型行为是非确定性的，一点小改动可能引发连锁反应。评估集的价值不在于“上线前过一遍”，而在于“每次改动后都过一遍”——也就是回归。把它接进 CI，让任何 prompt、工具、模型的改动都自动跑一遍评估，红就拦下来。这才是评估该有的样子。
💡 顿悟时刻：评估集是 Agent 的“体检报告”。你不会体检一次就管一辈子，Agent 也是。
第五关：可观测性
14.5 可观测性
生产环境中最怕的是“Agent 不知道为什么这么做”。用户投诉“它给了我一个奇怪的答案”，你打开后台一看——啥也没有。你不知道它调了什么、读了什么、走了哪条路。你只能复述一句“我看看”，然后束手无策。
这就是没有可观测性的痛。因此要记录：
- trace_id
- project_id
- thread_id
- 模型输入/输出摘要
- 工具调用参数和结果摘要
- 错误堆栈
- 耗时、重试次数、Token 消耗
本书的 BaseProject 已内置结构化日志、指标快照和流式事件，是可观测性的基础。
💡 顿悟时刻：可观测性的本质是“事后可追溯”。你不需要预见所有问题，你只需要保证——无论发生什么，事后都能还原现场。trace_id 就是那根把一次完整执行串起来的线，丢了它，事件就是一盘散沙。
第六关：护栏与治理
前三道关（成本、延迟、安全）管的是“单次执行别出事”，中间两道（评估、可观测）管的是“出事了能发现能复盘”，而这最后一道关——护栏与治理——管的是“系统长期运行中的软约束”。它由三块组成：Prompt 治理、记忆治理、MCP/Skill 治理。
14.6 Prompt 管理
Prompt 不是随手写在代码里的字符串，而是系统行为的重要资产。一行 prompt 的改动，可能比一百行业务代码的影响还大。
建议：
- 为每个 Prompt 写清楚目的、边界、反幻觉要求。
- Prompt 版本化，重大改动写 changelog。
- 用固定评估集回归测试 Prompt 改动。
- 生产中避免让用户输入覆盖系统指令。
⚠️ 避坑：用户输入覆盖系统指令（prompt injection）是 Agent 安全的经典攻击面。永远把系统指令放在不可被用户覆盖的层级，对用户输入做隔离和转义。
14.7 记忆治理
长期记忆让 Agent 越用越好，也带来隐私风险。记忆是把双刃剑：用得好是“它越来越懂我”，用得不好是“它记住了我不该被记住的东西”。
必须支持：
- 用户查看记忆
- 用户删除记忆
- 记忆过期策略
- 敏感信息过滤
- 租户隔离
不要把所有对话都永久保存。记忆要有选择、有边界、有治理。
心路历程：为什么记忆一定要“能删”
你可能会想：记忆嘛，存得越多越好，删了多可惜。
直到你遇到一个用户，他说：“我半年前随口说过一次我有某种病，现在这个 Agent 每次都把它翻出来，我不想让它记住这个。” 你去翻代码，发现记忆是只增不删的——存进去就永远在。你删不掉，用户也删不掉。
还有更严重的：Agent 有时会记错——把幻觉当成事实存进了记忆，之后每次都基于这个错误记忆回答，越错越深。你迫切想删掉那条“毒记忆”，却发现没有删除接口。
这时你才明白：记忆能存，是能力；记忆能删，是责任。隐私法规（如 GDPR 的“被遗忘权”）要求用户能删除自己的数据；记忆出错时，你需要能手动清除污染源。一个不能删的记忆系统，在上线那一刻就埋了合规和质量的雷。
14.8 MCP 与 Skill 治理
随着 MCP Server 和 Skill 增多，治理问题会变重要：
- 谁可以安装 MCP Server？
- Server 是否可信？
- Skill 是否过期？
- 工具描述是否准确？
- 是否存在权限过大的工具？
建议建立内部 registry，对 MCP/Skill 做版本管理和安全审核。
⚠️ 避坑：每一个新接入的 MCP Server / Skill，都是一个新的攻击面和故障源。不审核就接入，等于给陌生人配了一把你家钥匙。registry + 审核流程，是规模化后的必选项。
14.9 本书十个项目的进化路径回顾
走完这六道关，回头看本书的十个项目，它们其实是一条清晰的进化路径：
%%{init: {'theme':'base','flowchart':{'useMaxWidth':true,'htmlLabels':true}}}%%
graph LR
P1["客服
Tool+Prompt"] --> P2["知识库
RAG"]
P2 --> P3["代码审查
Harness+Skill"]
P3 --> P4["数据分析
MCP"]
P4 --> P5["视频生成
多模态"]
P5 --> P6["代码开发
闭环"]
P6 --> P7["内容创作
Multi-Agent"]
P7 --> P8["研究分析
辩论综合"]
P8 --> P9["个人助理
记忆+MCP"]
P9 --> P10["自主规划
全能力"]
classDef n fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#0d47a1
class P1,P2,P3,P4,P5,P6,P7,P8,P9,P10 n
这条路径的本质，是从一个能用工具的单 Agent，逐步进化成能协作、能记忆、能规划、能反思的智能体系统。
14.10 结语：从单兵到团队
回到开头那个被毒打了一周的你。
现在你心里有数了：成本在调用前就拦，延迟用流式对冲体感，安全靠硬约束而非 prompt，评估靠定期回归而非一次性，可观测靠 trace 串起现场，护栏靠治理守住长期。这六道关，每一道都是用真金白银和血泪教训换来的。
生产级 Agent 不是“大模型 + 几个工具”这么简单。它是一套工程系统：
- 有清晰边界
- 有可靠工具
- 有测试与评估
- 有日志与观测
- 有权限与安全
- 有成本与延迟控制
如果你完整跑完本书十个项目，你得到的不只是十段代码，而是一套可以迁移到任何 AI 项目的工程方法论。
金句：这本书的主线，是从单兵到团队。第一个项目里，一个大模型加几个工具，像一个人扛起所有活；到第十个项目，多个 Agent 协作、记忆、规划、反思，已经是一支能打仗的团队。而这六道关，就是让这支团队从“能演示”走向“能上线”的必修课。单兵能赢一场 demo，团队才能赢一场战争。
如果您喜欢此博客或发现它对您有用，则欢迎对此发表评论。 也欢迎您共享此博客，以便更多人可以参与。 如果博客中使用的图像侵犯了您的版权，请与作者联系以将其删除。 谢谢 ！