学习笔记 | 11 月 4 日 · 从 demo 到上线

demo 和上线之间，差的不只是一个接口

前四期讲的都是「怎么让它跑对」：结构、失败、续跑、成本。

上线要回答的是另一个问题：它跑错的时候，会怎么样。

demo 不怕跑错——重来一次就行。线上的跑错有代价：发错一封邮件、删错一个文件、给客户多退一笔钱。

差距集中在三件事上：

• 它能做的事太多：工具权限没边界，等于把整个后台交出去。

• 你不知道它做了什么：出事之后翻不出记录，只能猜。

• 出问题停不下来：没有刹车，也没有回滚。

这三件事，没有一件能靠改提示词解决。

权限：读放开，写收紧，不可逆必须有人点头

把工具按后果分三层，处理方式完全不同：

• 读：查资料、看订单、读文件。风险低，放开，只做范围限制。

• 写（可逆）：建草稿、写临时文件、改状态。可以自动，但要能回滚。

• 不可逆：发消息、付款、删数据、对外提交。必须有人确认。

三条经验，按重要性排：

第一，白名单永远好过黑名单。 写「只能读 materials/ 下的文件」，而不是「不要读 /etc」。黑名单永远列不全，白名单天然收敛。

第二，凭据不要进上下文。 数据库连接串、API Key、后台口令，一旦写进提示词，模型就可能原样说出来。让它调一个已经持有凭据的服务，比把钥匙递给它安全得多。

第三，只对不可逆的动作做确认。 每一步都弹窗，用户三天就会形成肌肉记忆，闭着眼点「同意」——这比不确认更危险。确认要稀缺，才有分量。

权限设计的目标不是「它什么都能做」，而是「它做错了也收得住」。

审计：让它做的每件事都留痕

审计不是给监管看的，是给自己用的。它至少要能回答四个问题：

• 谁触发的、什么时候、为了什么目标。
• 每一步调了哪个工具、传了什么参数。
• 结果是什么（成功、失败、还是等确认）。
• 花了多少钱。

一行一步，追加到一个日志文件就够：

09:12 用户A 目标 写周报 read_file materials/10-28.md  ok 830ms write_file out/周报.md  待确认

三个容易踩的坑：

• 只记成功不记失败。失败才是最需要复盘的，尤其是「参数被拒绝」这种。

• 记了 token 没记成本。事后算账时，还得重新乘一遍单价。

• 不脱敏。手机号、身份证、地址原样落盘，日志本身就成了风险源。

日志写到「事后能重建现场」的程度就够了，再细就是负担。

灰度：先影子，再小流量，最后才是全量

上线不是「打开开关」，是三级台阶：

第一级，影子模式。 它照常算，但不执行——只输出「我打算做什么」。人照常干活，事后对比它的建议和人的做法。这一级最安全，也最容易发现它理解错的地方。

第二级，小流量。 1% 的任务真实执行，盯三个数：成功率、成本、投诉率。任何一项难看，就退回影子模式。

第三级，全量。 到这一步，考验的已经不是模型，是值班和回滚。

灰度必须配三样东西：

• 一键停：一个开关，不用发版就能关掉。

• 预算上限：单任务、单用户、单天，三层上限，防止死循环烧钱。

• 版本化：提示词和工具定义都要有版本号，出问题能退回上一版。

没有回滚能力的灰度，不叫灰度，叫赌。

上线前的十个问题

答不上来的，就先别上。

1. 它最坏能造成什么后果？写下来，别在心里过一遍。
2. 每条后果，有没有对应的拦截？
3. 不可逆的动作，是不是都要人确认？
4. 凭据在不在模型看不见的地方？
5. 能不能一键停？
6. 出事之后，能不能还原它做过的每一步？
7. 有没有单任务成本上限？
8. 它失败的时候，是安静地错，还是会报警？
9. 有没有测过「它不该做但可能做」的动作？
10. 上线后，谁值班？

第 9 条最容易被跳过。正向测试只能证明它能做对，反向测试才能证明它不会乱来——比如让它读一个不在白名单里的路径，看它是不是真的被拦住。

给周报 Agent 补上三件套

昨天那个记了账的周报 Agent，再加三层：

TOOLS = [read_materials, write_report]ontool_call(name, args):  if name not in TOOLS:  reject  if not path_ok(args):  reject  if irreversible:       ask_user  audit(name, args)

具体到它身上：

1. 权限：只开放两个工具，read_materials 限定 materials/，write_report 只写 out/。
2. 审计：每次调用追加一行到 audit.jsonl，含时间、工具、参数、结果。
3. 灰度：先跑一周影子模式，只出建议不动文件；对比之后再放开写入。

这三层加起来不到五十行代码，但它决定了这个 Agent 是「能演示」还是「能交付」。

今日三句话

1. demo 关心「它能不能做到」，上线关心「它做不到时会怎样」。
2. 权限、审计、灰度，这三件事没有一件能靠提示词解决。
3. 不可逆的动作必须有人点头，其余的都该自动化——确认疲劳比不确认更危险。

明日预告：评测集——怎么在一次改动前后，证明它没有变差。