Agent 工程化落地：从 Demo 到生产的鸿沟
讲清 Agent 演示好看、上线难用的根因，掌握可观测、容错、权限、终止条件与降级这些工程骨架
- 理解 Demo 与生产系统的核心差距
- 掌握 Agent 的可观测性与全链路追踪
- 掌握工具权限、失败重试、超时与终止条件设计
- 建立人机协同与降级兜底的工程意识
能跑通一次，和能稳定跑一万次，是两件事
很多 Agent 演示的时候看着特别顺，一放到真实业务里就频繁出问题。根因很简单：演示走的是「最顺路径」，生产环境全是歧义输入、工具超时、脏数据、边界场景，还有人恶意乱用。工程化要解决的，就是让系统在这些非理想条件下，依然能做到可控、可观测、可恢复。
可靠性（出错可恢复）、可观测性（每一步可追溯）、可控性（权限与边界清晰）、可降级性（AI 不行时有人工/规则兜底）。缺任何一项，都只是“高级 Demo”。
1.1 把一次运行变成可追踪的轨迹（Trace）
Agent 跑一次任务通常要走好几步：理解意图 → 规划 → 调用工具 → 观察结果 → 再决策 → 生成。生产环境里必须把每一步都记成结构化的轨迹：输入是什么、选了哪个工具、参数是什么、工具返回了什么、耗时与 Token、最终动作。不然一旦答错，你根本分不清是「想错了、调错了、还是工具给错了」。
这跟传统后端的链路追踪（Tracing）是一个路数，只是追踪对象从微服务调用换成了“模型推理 + 工具调用”的混合链路。常见做法是给每次会话生成 trace_id，逐步落日志，再在后台做可视化回放。
线上 Agent 答错了一道题，想定位根因，最关键的基础设施是？
1.2 工具调用的工程护栏
Agent 能调用真实工具（查库、下单、发消息）才显出威力，这也是最大的风险点。必须给工具加护栏：
最小权限：工具只暴露完成任务所必需的能力，危险操作（删除、支付、外发）需要二次确认或人工审批。参数校验：模型生成的参数必须经过格式与业务规则校验，非法参数直接拒绝并把错误回喂给模型自我修正。超时与重试：工具调用设置超时；对幂等的只读操作可有限重试，写操作不能盲目重试以免重复执行。白名单与沙箱：只允许调用登记在案的工具，代码执行类工具必须在隔离沙箱中运行。
1.3 终止条件、循环与“自我纠错”的边界
自主 Agent 容易在“调用工具—发现不对—再调用”之间打转。工程上必须硬性设置：最大工具调用次数、最大总时长、最大 Token 预算、重复检测（连续出现相同动作即中止）。到达上限后优雅退出，向用户说明当前进展并给出可选下一步，而不是无限烧钱。
让模型看到报错后重试确实能修复一部分问题，但也可能在错误方向上反复尝试。稳健做法是“有限次自修复 + 到顶就升级（转人工或走规则）”，并记录每一次失败用于后续优化，而不是放任循环。
1.4 降级兜底与人机协同
再强的系统也要假设它会失败。设计时给每个关键环节留兜底方案：模型不可用 → 用缓存或规则应答；置信度低 → 转人工；工具故障 → 切只读降级，或者提示稍后再试。成熟的生产 Agent 都是人机协同的——AI 处理高频、确定的部分，人处理低频、复杂的部分，不是搞无人化全自动。
Agent 上线前自检清单
每一步是否有 trace 可回放；每个工具是否有权限、校验、超时；是否有最大步数/时长/预算的硬终止；失败是否有明确用户提示与降级路径；危险操作是否有确认或审批；会话状态在断网/刷新后是否可恢复；是否有开关能一键关闭 AI、退回传统流程。
下列哪项最能体现“可降级”的生产设计？
资深工程师加餐
底层原理 · 大厂视角 · 工程经验，点卡片展开
正文讲了两阶段、KV Cache、连续批处理与量化分别是什么，这里补上「为什么这些手段有效」的主线。关键在 Roofline 模型：decode 每生成一个 token 都要把全部权重从显存读一遍，却只做很少的运算，算术强度极低、被显存带宽卡住（memory-bound），所以单请求 decode 速度主要取决于「权重总量÷显存带宽」而非算力峰值——这正是量化（减少要读的字节）和连续批处理（读一次权重同时喂多个请求、把带宽用满）能提速的共同原因。KV Cache 占用可粗算：每 token 约 2×层数×KV头数×头维度×精度字节，7B 级模型单条长上下文就要占几百 MB，并发一高往往先于权重爆显存，于是才有 KV 量化（FP8/INT8）、PagedAttention 减碎片、MQA/GQA 减少 KV 头。正文没展开的两条路线：投机解码让小模型先起草、大模型一次并行校验多个候选 token，在不损失质量的前提下加快 decode；模型蒸馏让小模型逼近大模型，从源头减小要读的权重。工程上还要记住「单请求延迟」与「整机吞吐」此消彼长——batch 越大吞吐越高，但每个请求等得越久，要按 P95 首字延迟和每 token 速度反推合适并发，而不是一味堆吞吐。