No. 23: 我为什么把一本 Agent 技术书重写了两遍

2026/7/23

这件事最开始，真的只是一次内容整理。

我把《深入理解 AI Agent：设计原理与工程实践》的中文书稿下载到 Obsidian，统一文件名，修复 Markdown 格式，准备把它当作一套系统学习 Agent 的材料。

可我越整理，心里越别扭。

书里讲模型、上下文、记忆、工具、工作流，这些都重要。但当我把自己放回产品经理的位置，仍然不知道该怎么回答工作里最常遇到的几个问题：

• 这个需求为什么要做成 Agent？
• Agent 应该替用户做到哪一步？
• 哪些动作可以自动执行，哪些必须让用户确认？
• 演示成功之后，团队拿什么证明它真的能上线？

我原本只想把一本书整理得更好读，最后却新建了一个仓库，写成了两套教程。

1️⃣ 第一次重写：我发现技术目录不是产品路径

技术书通常按照系统组件展开。Prompt、Context、Memory、Tool、Workflow，每一项都有清楚的概念和实现方式。

但产品经理做项目时，不会先收到一个“请设计 Memory”的需求。我们收到的是：“能不能帮用户自动取消订阅？”“能不能让员工直接问公司的差旅制度？”“能不能把这段人工流程交给 Agent？”

问题从用户目标开始，最后才会落到技术。

如果顺序反过来，很容易拿着新能力找场景。团队刚接入长期记忆，就开始讨论该记住用户什么；刚看到多 Agent，就想把一个流程拆成五个角色；刚能调用工具，就急着让 Agent 自动执行。技术方案越来越丰富，产品为什么存在却越来越模糊。

我决定换一条路线，从产品生命周期重新组织内容：

机会与场景
→ 用户研究与任务建模
→ Agent 产品定义
→ 交互、信任与控制
→ 能力方案
→ 评估
→ 可靠性、安全与成本
→ 上线运营
→ 路线图与组织协作

技术没有被删掉，只是被放回它应该出现的位置。只有当它会影响用户价值、产品边界、风险、成本和验证方式时，我才展开讲。

这就是后来入门篇《Agent 产品方法》的骨架。

入门篇从机会识别出发，一直写到评估、上线、运营和组织协作。

2️⃣ 写案例时，我才真正理解“对结果负责”

为了避免全书只讲抽象概念，我放进了两条虚构案例线。

一条是客户服务与事务办理 Agent。用户说“帮我取消订阅并申请退款”，系统需要查订单、判断规则、请求授权、调用外部工具，还要处理超时和异常。

另一条是企业知识与办公 Agent。员工询问差旅制度，系统要找到当前有效的文件，继承用户权限，给出来源；材料冲突时不能装作确定。

写着写着，我发现自己过去对 Agent 的理解太接近“更聪明的聊天框”。

聊天框可以给出一段看起来合理的回答，Agent 却可能改变现实世界。退款是否真的到账，审批是否真的提交，制度是否仍然有效，这些都不能靠一句“已完成”来证明。

于是，“目标、信息、行动、证据”逐渐成了整套内容的坐标：

• 目标：用户真正想完成什么结果？
• 信息：Agent 可以依据什么事实和状态判断？
• 行动：它能做什么，做到哪一步需要停下来？
• 证据：团队怎样确认结果正确，失败后又怎样恢复？

我也开始意识到，Agent 产品经理设计的不是一条更灵活的功能流程，而是一个会判断、会行动、也会犯错的新产品参与者。

页面可以改版，回答可以重试，错误行动却可能带来金钱、权限和信任上的真实损失。自主性不是越高越好，它必须和责任一起设计。

3️⃣ 第二次重写：产品方法讲完了，工程判断还是缺了一块

入门篇完成后，我原以为这件事可以告一段落。

但很多问题继续往下追，就会进入产品和工程交界的灰区：

• Tool 调用超时后，能不能直接重试？
• 用户中途修改目标，旧授权还算不算数？
• Memory、Context 和外部事实混在一起时，错误从哪里来？
• 一次成功演示，怎样变成可以重复执行的发布证据？
• Agent 执行到一半崩溃，恢复的是整段对话，还是某个具体步骤？

产品经理不需要亲手实现向量索引、调度器和分布式追踪，但不能只写“回答要准确”“失败后自动重试”“高风险操作需要确认”。

这些话方向没错，却无法直接验收。工程团队还需要知道：准确依赖哪些来源，什么状态下允许重试，确认绑定的是哪个对象和金额，系统用什么证据判断动作已经完成。

所以我又写了进阶篇《Agent 产品工程》，按工程责任重新拆成 Context、Knowledge、Memory、Tool Loop、Graph、Agent Experience、Harness、Eval、Reliability、Safety 和 Production。

进阶篇沿着 Agent 从理解目标到进入生产的工程链路展开。

这一次的目标不是把产品经理教成工程师，而是让产品要求能够变成可实现、可测试、可恢复的契约。

比如“回答必须准确”，可以继续写成：

只使用当前有效且用户有权访问的制度；关键结论返回来源与版本；来源冲突时不自行裁决；证据不足时明确停止给出确定结论。

到了这一步，产品判断才不再停留在愿望层。

4️⃣ 最难的部分不是写，而是不断删掉自以为懂了的东西

这套教程从 Obsidian 里的书稿，变成独立仓库，再从一套入门内容扩展成两篇，过程中加了目录、导航、图示、内容检查、写作规范和许可证。

这些工作都能列成清单，真正消耗时间的却是另一件事：每写完一章，都要问自己，它究竟帮助产品经理做了什么决定？

如果一段技术解释不能改变场景选择、边界、成本、风险或验收方式，它可能很正确，却不一定应该留在正文里。

如果一个图只是把名词重新摆了一遍，没有让状态、责任和失败路径更清楚，它也没有存在的必要。

如果一个案例只展示 Agent 顺利完成任务，没有等待、权限、冲突和失败，那它更像 Demo，不像产品。

我过去学习新技术时，很容易把“知道这个词”当成“理解这个问题”。写书迫使我把这种模糊感暴露出来。因为一旦要把内容讲给别人听，就不能靠术语之间的熟悉感蒙混过关。

5️⃣ 这套书最后改变的是我自己的工作方式

现在再看一个 Agent 需求，我不太会先问用哪个模型、要不要上多 Agent。

我会先看任务是否真的需要自主判断，Agent 能拿到哪些可靠信息，有权改变什么，怎样让用户理解和接管，团队又拿什么证明结果已经完成。

这套书仍在持续校订，我也不认为两篇内容已经给出了所有答案。Agent 产品变化很快，今天有效的技术选型很可能很快过时。

但有些问题不会那么快过时：用户把什么目标交给系统，系统凭什么行动，错误由谁发现，结果如何被证明。

我把一本技术书重写了两遍，最后得到的并不是一份更长的知识清单，而是一套更严格的提问方式。

产品经理不需要记住所有 Agent 术语，但必须知道，一个会行动的系统凭什么值得被用户托付。

项目：pm-ai-agent-book

标签：AI Agent · AI 产品经理 · 产品方法 · 产品工程 · 开源写作

← 返回文章列表