落地清单 · 完整版
Agent 落地检查清单 · 完整版
《凡人指北》订阅附赠：完整案例、示意图与可打印速查表。动手前把判断写清楚，再谈模型和工具。
《凡人指北》订阅附赠完整版。实践案例已脱敏；公开案例均标出处。不涉及真实雇主或内部系统。
动手前把判断写清楚，再谈模型和工具。公开站上的是简版；这里是完整案例、示意图与可打印速查。
- 选场景
- 数据与权限
- 设计与工具
- 评估验收
- 上线与兜底
- 成本与迭代
怎么用这份清单
- 先勾「选场景」：前三条勾不上，先别开工——多半会做成又一个聊天框。
- 一次只试点一条流程：相关组打完，再决定要不要给写权限。
- 把勾选结果留给一周后的自己：哪几条真挡过坑，标成「下轮必勾」；其余可先放宽。清单的价值不在勾满，而在回看时认出：哪一条让你少走了弯路。
共 18 条，分六组。每条是可打勾的判断题 + 一两句「为什么 / 怎么判断」。
1. 选场景
1.1 你是在改底层 workflow，还是又多装了一个问答框？
- 至少动了这三件事之一：给对的数据、跨组织边界、人何时介入审查；并清楚会碰到谁的审批，以及数据和审计责任归谁。
为什么：Agent 的上行空间不在「多一个聊天入口」，而在嵌进真实工作流。垂直场景的壁垒多半也在责任链，不在 chatbox 答题分。我倾向认为：企业侧真正烧 token 的，会是「部署进 workflow 执行任务」的 Agent，而不是常驻聊天框。
实践案例：要把多步治理与上线串成可追踪流程，别停在聊天里临时问数。做成状态机，用机器可检查条件放行，并写清「适合长流程、不适合即席分析」。坑：一套 Agent 承诺两件事，验收会打架。判断：先写「不做什么」；有机器可读成败信号才适合上线。
1.2 出事之后，它能自己起来吗？还是必须有人重新点启动？
- 触发方式是事件 / 状态变化，而不是「有人记得去点一下」。
为什么：高价值 Agent 应是 event-driven。关键不是 24 小时空转烧 token，而是「无需人工重启」——新事件自动带上状态、权限与反馈。若只是模仿员工点旧界面，那是 RPA，飞轮转不起来。Workflow 要改成事件、状态、任务、技能与证据可被机器消费的形态。
怎么判断：设想全员请假一周——若 token 用量暴跌，说明 AI 仍是工具，还不是流程参与者。
1.3 成功标准能否一句话说清，并且能被机器或脚本验收？
- 写得出「完成长什么样」；也写得出失败时该停还是升级。
为什么：无法衡量的工作也无法自动化。自动化首先考验的是你有没有定义指标与评估，而不是先堆模型。做不到这一条，后面所有「感觉挺好」都不可靠。
2. 数据与权限
2.1 知识底座就绪了吗？还是在用一堆历史查询「喂」模型？
- 口径、表/字段含义、业务规则是显式的；关键知识同时「人可读 + 机可检索」。
为什么：很多数据类 Agent 卡的不是模型，而是数据有没有被治理成可稳定检索与引用的形态。历史查询记录 ≠ 知识；被动投喂往往提升很低甚至下降。飞轮要转，知识底座必须先就绪——手工整理省不了。
实践案例：上问数 Agent 时，卡点往往不在「会不会写查询」。能跑不等于口径对；概念映射错、上下文过期、检索不稳都是知识问题。坑：历史查询整包丢给模型，提升很低甚至下降。判断：先就绪口径断言、码表与权威文档，再谈换模型。
2.2 编排 / 执行 / 外部，三个信任平面分开了吗？
- 编排层只建任务与人审门；执行层权限收在最小目录/工具集；外部输入一律当不可信。跨服务时有边界与验证入口可按需加载，而不是把整仓塞进上下文。
为什么：编排器对 worker 常被迫「全权限」才能无人值守——这是 all-or-nothing 陷阱。Solo 可用软围栏；对外部贡献者或不可信渠道必须硬沙箱。看得见全部代码 ≠ 理解服务边界；可靠上下文应来自机器可读、可验证的资产。
公开对照：EchoLeak（CVE-2025-32711）说明外源指令可零点击外泄上下文 · 出处 arXiv:2509.10540
公开案例：EchoLeak（CVE-2025-32711）：外部邮件隐藏指令可让生产 Copilot 零点击外泄内部上下文。我怎么看：外部输入一律不可信，信任平面切开；小团队收件箱 RAG 也要隔离外源、禁自动拉外链。出处：arXiv
2.3 「可以放行」的信号，是不是放在调用者能改的地方？
- 信任结果走进程内闭环（返回码 / 内存状态 / 受控产物），不依赖评论、聊天消息等可伪造信道。
为什么：常见坑——评审把「可合并」写在评论里，监控再回读评论自动合并。任何有评论权的人都能伪造放行。门禁信号绝不能放在调用者可写的信道。
3. 设计与工具
3.1 你在设计工作环境，还是还在打磨说明书？
- Prompt 变轻；工具、skill、记忆、上下文变重。固定抽取/清洗用脚本或 schema（要稳）；开放探索才交给自由 Agent（要灵）。
为什么：Agent engineering 本质是设计工作台。力气花在工具接口清晰度上，往往比再磨系统提示词更管用。交互式 Agent 的多样性，在固定管线上是毒药——先问「这步要稳还是要灵」。
实践案例：线上 Skill 职责混杂，图说不清谁决策、谁调工具、何时退出。先停迁移，按「抽取→校验→调用→验证」做出短样板，过关再铺开。坑：名词争论掩盖实现；隐式调用上限当退出。判断：样板质量先于规模化。
3.2 控制层 / 编排层 / 执行层分清了吗？
- 聊天渠道只收指令与汇报；编排层负责路由、监控、预算；真干活在隔离环境里跑。
为什么：层分清，才能做近零 token 预检门和安全审计。聊天里直接 spawn 写码/写生产，边界一定糊。
3.3 Skill 记住的是「语境」，还是只罗列操作步骤？
- Skill 会收窄用户已说过的过滤条件与边界；不是又一份流程说明书。被编排器当 skill 调用的组件，仍应是正经可测项目，不要因「只是 skill」而缩水。
为什么：同题对比里，流程步骤类断言几乎不涨分，对话语境收窄类断言提升更明显。Skill 真正增值常常是语境收窄。
实践案例：做「从订单台账按口述定位条目」的 Skill。初版只扫关键词，字面命中却是同名另一笔——用户已用工单号与时间窗收窄。补上「先读对话收窄信号再检索」才拉开差距。坑：聚合答对率两边都像对。判断：会短句承接上文时，Skill 须做语境收窄并为此出题。
4. 评估验收
4.1 闭环有没有 Owner、截止时间、验收口径？
- 谁负责、何时算完、怎样算过——三项都写死；成功标准尽量机器可读（测试、编译、业务断言），不只靠人工感觉。
为什么：同步只是广播风险。缺 Owner / 时钟 / 验收，周会变成风险收集器。Agent 任务同理：没有这三项，Trace 再漂亮也是演示。上线前写不清「完成长什么样」，就谈不上自动化（呼应 1.3）。
4.2 AI 交付物验收时，Owner 能否脱离 AI 讲清楚？
- 追问假设、权衡、失败边界与验收标准时，责任人答得上来。
为什么：AI 生成的架构图/方案会制造「理解已经发生」的错觉——材料完整，人却讲不出因果。AI-native 评审应验收：Owner 能否不看生成稿，独立解释设计取舍。
实践案例：原型链路已通，材料有概念图和细节流程图，中间却缺模块边界与外部能力落点。专项评审对照「现有 vs 应有中层」；MVP 只收最小闭环。坑：把「轻量」当成跳过架构；接口已改却未与业务方校准。判断：技术闭环≠业务闭环；Owner 须能讲清中层。
4.3 你有没有听「单条失败」，而不只看聚合分？
- 重大改动后至少人工翻过一批 Trace；把第一处失败记下来，加回回归。
为什么：聚合分可能两边都「答对」，一句真实反馈才暴露任务其实是上下文延续，而不是字面检索。Skill 与评测应以真实失败为信号。
实践案例：现场用示例表演示报告生成跑通后，要求新开会话、换另一套样本测泛化；失败用来改 Skill 本体，不靠当前对话「托着」。坑：客户端、网络与授权常吃掉大半时间；许多人停在第一套样本。判断：换会话 + 换样本，才把演示升级成工程验收。
5. 上线与兜底
5.1 默认是不是「软围栏 + 人审标签门」？对外开放才上硬沙箱？
- 不可信输入进编排前：围栏包裹、危险指令中和、人打放行标签才派活；自动合并的信任源留在编排进程内。
为什么：上线默认应偏保守。Solo 可先软围栏；对外部渠道或未知贡献者，必须硬隔离。人审标签是门，不是装饰。
实践案例：长流程不以人口头「差不多了」放行，而以机器可检查条件为门槛；先小规模试跑再接平台。坑：没有显式门槛，就会用感觉代替验收。判断：上线默认偏保守；放行信号机器可读，并留在调用者改不了的地方（呼应 2.3）。
5.2 改完配置，你有没有「校验 + 确认进程真的在听」？
- schema / 配置校验通过；服务真正 listening；删掉的 Agent 没有孤儿渠道账号。
为什么：常见踩坑——以为加了「禁用」就安全，结果 schema 报错拖垮进程；或删了 Agent 却留下孤儿 channel。改完配置务必 validate，并确认进程存活，再算上线成功。
公开对照：SaaStr × Replit Agent 生产库被删事故后，Replit 默认拆开开发/生产库 · 出处 The Register / Replit Blog
公开案例：2025 年 SaaStr 用 Replit Agent 时生产库被删，多次禁止仍被绕过（Register）；Replit 事后默认拆开开发/生产库。我怎么看：改完配置不等于上线——环境是否真隔离、进程是否听新规则要验。小团队：预览与生产库物理分开。出处：Register · Replit
5.3 人退到编排之外时，最终责任人、升级路径、机器可读成败信号还在吗？
- 写明最终责任人、何种错误必须升级、一键停用怎么做；场景尽量有编译/部署/业务断言等外部可验证结果，能喂回学习飞轮。
为什么：Agent 协作再多，不可替代的是判断与责任归属。纯聊天缺「实际做了什么」的反馈；有机器可读成败信号的场景，才容易形成飞轮。清单上必须保留责任人与升级路径，避免无人兜底。
公开案例：加航官网聊天机器人错误告知丧亲票可事后申请，审裁处认定公司对机器人说法负责，判赔约 812 加元（CBC）。我怎么看：对外 Agent 说错话责任仍在公司；写清责任人、何种错误升级给人、一键停用。别用「是 AI 说的」挡箭。出处：CBC
公开案例：Klarna 2024 称 AI 客服首月约 230 万对话、相当于约 700 全职（官网）；2025 年 CEO 承认过度抠成本伤体验，转向 AI+人工双轨（Forbes/公司回应）。我怎么看：省钱不是唯一 KPI；先写「何时必须转人」。出处：Klarna · Forbes
6. 成本与迭代
6.1 Token 是不是花在「进 workflow 真干活」，而不是常驻空转？
- 用事件唤醒；编排层能做近零 token 预检，再叫醒贵模型执行层。
为什么：聊天框往往不是成本中心；真正烧钱的是常驻空转。事件驱动 + 编排层预检，再按需触发执行层。
出处：Databricks · How we eliminated $1M+/year wasted AI agent spend。图中数字仅复述原文，非推算。
公开案例：Databricks：七个 MCP 工具小 bug，Agent 静默重试烧掉约每年 49.9 万美元 token、合计约 120 万美元损失；追踪一小时定位并修（工程博客）。我怎么看：账单涨不一定是用量，可能是工具失败空转。先打点工具错误，再谈换模型。出处：Databricks
6.2 你有没有先自己跑通一条真业务，再堆脚手架？
- 至少用一份真实输入跑通端到端；再决定抽象 skill / 多租户 / 图。
为什么：常见陷阱——半天建了一堆 skill、ADR、多租户，却还没跑通一篇真稿。基础设施过剩、实战不足。若脚手架已经堆了一桌、真输入还没压过全链路，多半是抢跑了：先端到端交付一次，再谈可复用。
6.3 见过两次的请求，有没有变成 skill，稳定后再挂定时？
- 路径是：手动跑通若干次 → 固化 skill → 值得自动再上 cron；不是无限重复一次性手工。
为什么：默认迭代路径应是：先手动跑通，再固化成 skill，值得自动再上定时——不要无限一次性手工，也不要工具挂满却从不调用。
公开案例：GitHub：Agentic Workflow 里 unused MCP 每轮白吃上下文；砍未用工具并用 CLI 预取后，Auto-Triage 等 Effective Tokens 最高降约 62%。我怎么看：工具挂满≠能力强，先审计从不调用的工具。出处：GitHub Blog
六阶段速查
| 阶段 | 关键问题 |
|---|---|
| 01 选场景 |
|
| 02 数据与权限 |
|
| 03 设计与工具 |
|
| 04 评估验收 |
|
| 05 上线与兜底 |
|
| 06 成本与迭代 |
|
参考资料
工程共识（外部）
- Anthropic · Building effective agents
- OpenAI · A practical guide to building agents
- Hamel Husain · AI Evals FAQ
- Floatboat · 单人业务如何落地 AI 工作流
- 侯惠阳 · 中小企业 Agent 架构
公开案例