Agent Product 101｜00｜Reading Guide：如何理解 Agent 产品
这份导读帮助产品经理把 Agent Product 101 当作一张产品化地图来读：从任务入口、控制、权限、人类协作到评估、观测和治理，判断 Agent 是否真的可交付、可控制、可信任。
核心结论
Agent Product 101 讨论的不是“模型是否足够聪明”，而是 Agent 如何成为一个用户愿意委托任务、能够持续监督、可以安全授权、失败后能恢复、结果能被验收的产品系统。
对产品经理来说，Agent 的关键问题不是“能不能调用工具”，而是：
- 用户能把什么任务交给它？
- 任务边界、成功标准和交付物是否清楚？
- Agent 执行动作时，用户在哪里看见、暂停、审批、接管和回滚？
- 权限、审计、评估、观测和治理是否已经进入产品设计？
- 失败时，是让用户重新发一句 prompt，还是能从状态、日志、版本和责任记录中恢复？
如果 Agent Engineering 101 关注 loop、tool、memory、context、workflow、evaluation 等工程机制，那么 Agent Product 101 关注的是这些机制如何进入真实产品：任务如何进入，用户如何控制，权限如何授予，过程如何被解释，结果如何被验收，组织如何治理。
读者收益：读完这个系列，你应该能做什么
这套文章不是产品测评，也不是模型能力综述。它更像一套 Agent 产品审查框架。读完后，产品经理应该能够完成四类判断。
| 你要判断什么 | 读完后应该能回答的问题 |
|---|---|
| 产品边界 | 你的 AI 产品是 Chatbot、Copilot、Workflow，还是 Agent Product？ |
| 任务设计 | 用户交给 Agent 的到底是 prompt、请求、流程，还是可验收任务？ |
| 控制与信任 | Agent 在执行中哪些地方自动推进，哪些地方必须让人介入？ |
| 生产化能力 | 权限、审计、评估、观测、可靠性和治理是否足以支撑真实上线？ |
一个有用的阅读姿势是：不要把每篇文章当作概念定义，而要把它当作产品评审清单。每读完一篇，就回到自己的产品里问：我们有没有这个对象？这个对象在哪里出现？用户是否理解？出错时能否恢复？
为什么需要 Agent Product 101
很多 Agent 讨论停在两个层面。
第一层是模型能力：推理、长上下文、多模态、代码生成、浏览器操作、工具调用。
第二层是工程实现：agent loop、tool runtime、planner、memory、sandbox、trace、eval、fallback。
这些都重要，但真实用户不会直接购买一个 loop，也不会因为工具调用格式正确就信任一个 Agent。用户真正关心的是：
- 我能把什么工作交给它？
- 它会访问哪些数据、修改哪些对象、触发哪些外部动作？
- 我什么时候能看见计划和中间结果？
- 我能不能阻止它、纠正它、接管它、回滚它？
- 结果能不能进入我的工作流，而不是只停留在一段回答里？
- 团队里谁能批准、谁负责、谁审计？
这些问题就是 Agent Product 的范围。
本系列的阅读地图
建议把 Agent Product 101 看成一条从“能力”走向“产品系统”的路径。
第一组：定义用户能如何委托
| 章节 | 主题 | PM 要抓住的核心问题 |
|---|---|---|
| 01 | Agent Product | 什么情况下，一个 AI 产品才算真正进入 Agent Product？ |
| 02 | Task Surface | 用户从哪里交付任务，任务绑定什么对象，结果如何验收？ |
| 03 | Control Plane | Agent 执行时，用户如何看见、暂停、审批、接管、回滚？ |
| 04 | Human-in-the-Loop | 人类在何时、以什么角色、基于什么信息参与流程？ |
| 05 | Permission Model | Agent 能访问什么、执行什么、谁授权、谁审计？ |
第二组：定义任务如何运行
| 章节 | 主题 | PM 要抓住的核心问题 |
|---|---|---|
| 06 | Workspace | Agent 任务运行在哪里，状态、文件、日志和交付物如何承载？ |
| 07 | Long-Running Tasks | 长任务如何暂停、恢复、通知、取消、重试和交付？ |
| 08 | Trust UX | 用户如何理解 Agent 的计划、证据、风险和结果可信度？ |
第三组：定义产品如何运营
| 章节 | 主题 | PM 要抓住的核心问题 |
|---|---|---|
| 09 | Product Metrics | Agent 产品如何衡量成功，而不是只看调用量和 DAU？ |
| 10 | Evaluation | 如何把任务质量、风险和用户验收转化为评估体系？ |
| 11 | Observability | 如何追踪 Agent 做了什么、为什么做、在哪里失败？ |
| 12 | Reliability | 如何设计失败恢复、降级、重试、回滚和质量保障？ |
第四组：定义组织化和平台化
| 章节 | 主题 | PM 要抓住的核心问题 |
|---|---|---|
| 13 | Platform | Agent 如何从单点功能变成可配置、可扩展、可治理的平台资产？ |
| 14 | Autonomy Levels | 不同自主级别如何被产品化，而不是简单追求“全自动”？ |
真实产品如何作为阅读锚点
本系列会反复引用 Hermes Agent、ChatGPT Agent、v0、Replit Agent、Lovable、Claude Code、Codex、Cursor、GitHub Copilot coding agent、Copilot Studio、Agentforce、Slack AI agents 等产品。
引用这些产品的目的不是比较谁更强，而是观察它们如何回答同一组产品问题。
| 产品类型 | 代表产品 | 适合观察什么 |
|---|---|---|
| Personal Agent | Hermes Agent、ChatGPT Agent | 个人任务委托、浏览器/本地操作、敏感动作确认、接管与记忆管理 |
| AI App Builder | v0、Replit Agent、Lovable | 从产品意图到 project、preview、checkpoint、deployment 的任务路径 |
| Developer Agent | Claude Code、Codex、Cursor、GitHub Copilot coding agent | diff、branch、PR、CI、review、sandbox 和工程协作制度 |
| Workflow Agent | Slack AI agents、Copilot Studio | thread、approval、workflow、handoff、团队协作和业务流程 |
| Enterprise Agent Platform | Copilot Studio、Agentforce | 身份、权限、连接器、策略、审计、生命周期和企业治理 |
这些产品形态看起来差异很大，但它们都在解决同一个转化问题：把模型能力变成用户可委托、可控制、可验收的任务结果。
产品判断表：它是不是 Agent Product
产品经理可以先用下面这张表做初步判断。
| 判断问题 | 如果答案是否 | 产品风险 |
|---|---|---|
| 用户交付的是明确任务，而不只是问题吗？ | 还停留在问答或内容生成 | 用户不知道该委托什么 |
| 是否有任务状态？ | 长任务不可监督、不可恢复 | 用户只能等待最终回答 |
| 是否有可验收交付物？ | 输出只是文本声明 | 难以进入真实工作流 |
| 是否能执行外部动作或写回系统？ | 仍是建议型 Copilot | 价值停留在人手复制粘贴 |
| 是否有权限边界和授权机制？ | 风险不可控 | 难以处理真实数据和高价值动作 |
| 是否有控制点？ | 用户不能暂停、审批、接管或回滚 | 不敢委托复杂任务 |
| 是否有 trace、audit、eval？ | 无法复盘、评估和治理 | 团队和企业采用受阻 |
如果一个产品大多数问题答不上来，它可能仍然是 LLM App、Chatbot 或 Copilot。不是所有产品都必须成为 Agent Product，但如果目标是让用户委托真实任务，这些对象就不能缺席。
常见误区
误区一：把 Agent 等同于“会调用工具的聊天框”
工具调用只是执行能力，不是产品化能力。用户需要知道工具何时被调用、调用前是否要批准、调用后影响了什么对象、失败后如何恢复。
误区二：把“更自主”当作唯一目标
产品化自主性不是让 Agent 什么都自动做，而是根据风险选择控制强度。低风险可自动，中风险要 preview 或 diff，高风险要 approval，异常状态要 takeover。
误区三：只优化最终回答
Agent Product 的结果应该是可验收对象：PR、deployment、CRM record、ticket update、workflow result、report、file、approval result。最终回答写得漂亮，不代表任务完成。
误区四：把治理留到企业版再做
只要 Agent 能访问数据、调用工具或写回系统，权限、审计、观测、评估就不是“企业高级功能”，而是产品基本安全结构。
PM 阅读检查清单
读完整个系列时，可以持续带着这份清单审视自己的产品：
- 我们定义的核心任务是什么？它是否有成功标准？
- 用户从哪个入口交付任务？入口是否匹配任务语义？
- 任务是否绑定真实对象，例如 project、repo、thread、ticket、CRM record？
- Agent 的计划、状态、工具动作和中间结果是否对用户可见？
- 哪些动作可自动执行，哪些动作必须预览、审查或审批？
- 用户能否暂停、纠错、接管、恢复和回滚？
- 交付物是否能进入用户已有工作流继续 review、测试、发布或归档？
- 失败是否有可复盘的 trace，而不是只剩聊天记录？
- 团队和企业场景中，权限、审计、策略和生命周期是否清楚？
小结
Agent Product 101 的核心立场是：Agent 产品不是模型能力的包装，而是任务、控制、权限、人类协作、工作空间、评估、观测、可靠性和治理的组合系统。
产品经理真正要设计的不是“一个聪明的 AI”，而是一个用户敢委托、能控制、可验收、可追责的任务系统。
下一篇会进入 Agent Product：先建立 Agent Product 与 Chatbot、Copilot、Workflow 的边界，再抽象出可用于产品评审的三层结构和最小闭环。