Agent 不是抽象存在的。 它最终都要回到具体场景。
但如果只把这些场景理解成“换了几套提示词”，那就完全没有抓住重点。
因为这几类场景虽然都叫 Agent，真正要求系统去解决的却是不同问题。也正因为如此，落地场景最值得看的，不是哪一类更炫，而是哪一类在对象、动作、验证和治理上最具代表性。
因此，第 38 章第一条结论应该是：
Agent 的场景差异，本质上不是行业差异，而是任务结构差异；不同场景真正改变的是对象模型、动作空间、验证方式和治理强度。客服场景里，重点通常是升级与责任链。
表面看，客服 Agent 很像“会回答问题的系统”，但真正决定其价值的，往往不是回答本身，而是它能否正确读取用户身份、查询后台状态、调用 CRM/工单工具、给出下一步建议，并在不确定时及时升级给人。也就是说，客服 Agent 的核心不是最大自治，而是恰到好处的有限自治。
编码场景里，重点通常是对象边界和终态验证。
代码库、文件、依赖、测试、diff、分支、PR，这些对象都相对明确；编译、测试、静态检查、review 也提供了较强终态验证器。因此，编码 Agent 之所以是今天最具代表性的落地场景之一，并不是因为代码容易，而是因为它天然适合被做成“对象清晰、动作明确、验证外部化”的系统。
检索与报告场景里，重点通常是证据链。
这类 Agent 最大的价值不在高副作用动作，而在信息搜集、来源筛选、证据组织、长文整合和结构化表达。它最常见的失败，也不是权限越界，而是来源不稳、摘要失真、引用断裂、证据和结论脱节。因此，这类场景最重要的不是动作治理，而是事实治理。
医疗场景里，重点通常是工作流嵌入与人类监督。
医疗 Agent 几乎不会允许“无限自治”成为设计目标。病历、检查、诊断、转诊、分诊、风险分层、人工复核、责任归属，都会把系统限制在高约束、高审计、高升级要求的流程里。所以，医疗类 Agent 更像“临床工作流部件”，而不是“独立医生替身”。
运维与操作场景里，重点通常是权限、止损与恢复。
日志、指标、告警、脚本、控制台、浏览器和终端都可能在一个系统里汇聚。它的价值很高，但风险也最高。一次错误诊断、一次错误脚本、一次错误重试，都可能迅速变成系统级事故。因此，这类场景对最小权限、审批、回滚、熔断、session replay 和 incident trace 的依赖，通常比其他场景都更强。
如果把这些场景放在一起看，会得到一个很清楚的认识：
客服重升级。 编码重验证。 检索与报告重证据。 医疗重监督。 运维重止损。
换句话说，场景不是在改变“模型风格”，而是在改变“系统重心”。
因此，第 38 章第二条结论应该是：
真正决定一个 Agent 场景能否落地的，不是模型表现得像不像人，而是这个场景最重要的系统重心有没有被正确抓住。也正因为如此，看落地场景时最值得问的，其实不是“这个行业能不能用 Agent”，而是四个更硬的问题：
- 这个场景里的核心对象是什么
- 哪些动作真的允许被代理
- 成功由什么外部机制验证
- 出错后由谁接管、如何止损
只要这四个问题回答不清楚，场景再热门，也很难真正做成生产级系统。
反过来说，这几个典型场景恰恰是理解 Agent 的最好教材。客服告诉我们升级链的重要性，编码告诉我们终态验证的重要性，检索与报告告诉我们证据治理的重要性，医疗告诉我们监督与责任链的重要性，运维告诉我们权限与恢复的重要性。
这些场景看起来不同，但它们都在重复同一个原则：
业务越真实、风险越高、链路越长，Agent 越需要结构化设计。所以，本章最后要留下的判断是：
Agent 的落地价值，不来自“它像一个通用智能体”，而来自“它在特定场景中被组织成一个可验证、可升级、可止损的任务系统”。