Agent Product 101｜01｜Agent Product：从能力到产品
给产品经理的一套判断框架：一个 AI 产品什么时候不再只是聊天框、Copilot 或 workflow，而开始成为可委托、可控制、可验收、可治理的 Agent Product。
核心结论
Agent Product 不是“更聪明的聊天框”，也不是“接了工具调用的 LLM App”。
对产品经理来说，更实用的定义是：用户能把一件真实任务交给系统，系统能在明确边界内推进任务，并让用户在过程中看见状态、控制风险、验收结果、追溯责任。
如果产品只能回答问题，它更接近 Chatbot。
如果产品能给建议，但执行仍靠人复制粘贴，它更接近 Copilot。
如果产品只能跑固定流程，它更接近 Workflow。
如果产品能围绕任务组织上下文、调用工具、维护状态、交付结果，并在关键节点让人确认、接管或回滚，它才开始接近 Agent Product。
这篇文章要回答四个 PM 问题：
- 如何判断一个 AI 产品是否已经进入 Agent Product？
- 一个 Agent Product 至少要有哪些产品对象？
- 不同类型 Agent 的入口、交付物、控制点和风险边界分别是什么？
- 从 Chatbot / Copilot 升级到 Agent Product，产品路线应该怎么走？
第一张判断表：不要先问“够不够自主”
很多团队一开始会问：我们的 Agent 能不能自主执行更多步骤？
更好的起点是下面这张表。
| 判断问题 | 如果答案是否 | 产品含义 |
|---|---|---|
| 用户交付的是不是一个真实任务？ | 否 | 还只是问答、生成或建议 |
| 是否有任务对象和任务状态？ | 否 | 长任务不可恢复，用户无法监督 |
| 是否有明确交付物？ | 否 | 输出仍停留在“回答”，不容易验收 |
| 是否能调用工具或写回系统？ | 否 | 还没有进入真实工作流 |
| 是否有权限边界？ | 否 | 无法安全处理数据和外部动作 |
| 用户是否能看见计划、进度和中间结果？ | 否 | 不敢委托，只能等待最终答案 |
| 用户是否能暂停、审批、接管、回滚？ | 否 | 失控风险高，难以进入高价值任务 |
| 过程是否能被追踪、评估和审计？ | 否 | 团队和企业难以采用 |
这张表比“模型有多强”更重要。模型能力决定上限，产品对象决定用户是否敢用。
一个工作定义
Agent Product 是围绕用户任务构建的 AI 产品系统。它通过 Runtime 执行任务，通过 Product Surface 让用户委托、监督和控制任务，通过 Governed Platform 管理权限、工具、数据、审计、评估和生命周期。
这个定义故意不绑定某一种 UI。Agent Product 可以是聊天窗口、CLI、IDE、项目工作区、GitHub PR、Slack thread、CRM console、低代码 builder 或后台任务系统。
关键不是界面长什么样，而是三个问题：
- 它是否承接真实任务？
- 它是否能在明确边界内执行动作？
- 它是否让人类能够控制、审计和验收结果？
三层模型：Runtime、Product Surface、Governed Platform
分析一个 Agent 产品，可以先拆成三层。
| 层 | 关注问题 | PM 应该看什么 |
|---|---|---|
| Runtime | Agent 如何执行任务 | 工具、上下文、状态、计划、错误处理、后台运行是否足够支撑任务 |
| Product Surface | 用户如何委托、监督、纠正、验收 | 入口、计划、状态、preview、diff、approval、handoff 是否清楚 |
| Governed Platform | 组织如何配置、扩展、监控、审计 | 身份、权限、策略、连接器、日志、评估、成本、生命周期是否可管理 |
Runtime：执行能力，但不是完整产品
Runtime 决定 Agent 有没有行动能力。它可能包括模型调用、工具运行、上下文构建、记忆与状态、规划、沙箱、后台任务、错误处理和重试机制。
对 Claude Code、Codex、Cursor 来说，Runtime 要能读代码、改文件、运行测试、处理终端输出、生成 diff。
对 v0、Replit、Lovable 来说，Runtime 要能生成应用、维护项目状态、运行 preview、连接部署系统。
对 Copilot Studio、Agentforce 来说，Runtime 要能编排知识、动作、业务流程和人类审批。
但 Runtime 本身还不是产品。用户仍然需要知道：它准备做什么、是否可以停下、结果如何验收、谁批准它访问数据、出错后如何恢复。
Product Surface：信任、控制和交付发生的地方
Product Surface 是用户遇到 Agent 的地方。它可以是 Chat、CLI、IDE、Project workspace、Preview panel、Diff viewer、PR page、Slack thread、CRM console、Approval card、Task dashboard。
很多 Agent 产品失败，不是因为 Runtime 不够强，而是 Product Surface 没有让用户形成正确心理模型。
用户看不见计划，就无法判断 Agent 是否跑偏。
用户看不见中间状态，就不知道什么时候该介入。
用户看不见 diff、preview、logs 和权限请求，就只能在最终结果里猜风险。
所以 Product Surface 不只是包装层，它是 Agent 的控制界面、信任界面和交付界面。
Governed Platform：从 demo 到生产的分水岭
Governed Platform 回答：这个 Agent 如何被配置、扩展、监控、审计和管理？
对个人产品来说，它可能是权限提示、本地沙箱、技能目录、记忆管理和任务历史。
对企业产品来说，它会变成身份、RBAC、OAuth scope、连接器管理、DLP、audit log、admin control、eval、成本控制和生命周期管理。
这也是很多 Agent 产品从 demo 走向生产时最容易低估的一层。模型能力可以很快接入，工具调用也可以很快做出来；但如果没有治理层，产品很难进入团队、企业和高风险工作流。
Agent Product 的最小闭环
一个 Agent 产品至少需要七个产品对象。它们不一定都要独立成页面，但产品内部必须有清晰表达。
| 对象 | 解决的问题 | 缺失后的后果 |
|---|---|---|
| Task | 用户到底委托了什么工作 | Prompt 很散，任务边界不清 |
| Context | Agent 依据什么信息行动 | 信息不足或暴露过多数据 |
| Tools | Agent 如何影响外部世界 | 只能回答，不能进入工作流 |
| State | 任务当前推进到哪里 | 长任务不可恢复，用户看不见进度 |
| Control | 用户如何暂停、批准、接管、回滚 | 用户不敢委托高价值任务 |
| Output | 最终交付什么可验收对象 | 结果只是“我完成了”的文本声明 |
| Trace | 为什么这么做、做过什么、谁批准 | 无法调试、审计、评估和追责 |
最小闭环是：用户提交 Task，系统选择 Context，调用 Tools，更新 State，通过 Control 暴露关键节点，产出 Output，并留下 Trace。
任何一环缺失，都会形成产品缺口：没有 Task，Agent 只能聊天；没有 State，长任务无法恢复；没有 Control，用户不敢授权；没有 Output，结果无法验收；没有 Trace，团队和企业无法上线。
与 Chatbot、Copilot、Workflow 的区别
| 形态 | 核心 | 主要产物 | PM 关注点 | 典型缺口 |
|---|---|---|---|---|
| Chatbot | 回答 | 文本回复 | 答得准不准、清不清楚 | 不承接任务，不负责结果 |
| Copilot | 辅助 | 建议、草稿、代码片段 | 用户是否采纳、如何修改 | 执行仍靠人复制粘贴 |
| Workflow | 流程 | 流程状态变化 | 触发、审批、写回、通知 | 缺少上下文判断和异常处理 |
| Agent Product | 委托 | 可验收任务结果 | 状态、权限、控制、交付、审计 | 难点是边界和治理 |
Agent Product 的主要产物不是一段回答，而是一个可验收的任务结果：报告、app、deployment、PR、CRM record、ticket update、approval result、workflow result。
真正有价值的结果，应该能进入用户已有工作流继续被 review、测试、部署、归档、审批或追踪。
真实产品地图：按产品对象看
| 类型 | 任务入口 | 任务对象 | 交付物 | 关键控制点 | 风险边界 |
|---|---|---|---|---|---|
| Personal Agent | Chat、本地工具、浏览器 | 个人多步任务 | 文件、摘要、消息、自动化结果 | 权限确认、暂停、接管、记忆管理 | 私人数据、账号登录态、外部发送 |
| AI App Builder | Prompt、Project、Visual edit | 应用构建任务 | Preview、deployment、live URL | preview、checkpoint、rollback、deploy decision | 真实用户、数据库、支付、域名 |
| Developer Agent | CLI、IDE、issue、PR comment | 代码修改或工程任务 | Diff、branch、PR、test result | diff review、test、branch protection、CI | 主分支、生产环境、数据迁移 |
| Workflow Agent | Slack、Teams、表单、业务系统 | 团队流程任务 | 审批、通知、ticket update、流程状态 | approval、handoff、notification | 错误写回、流程中断、责任不清 |
| Enterprise Platform | Builder、admin console、connector | Agent 生命周期 | Agent、policy、connector、audit、monitoring | RBAC、DLP、audit、admin control | 合规、权限继承、跨系统副作用 |
这说明：Agent 不是一种 UI，而是一组围绕任务委托建立的产品对象。
从 Chatbot 到 Agent Product 的演进路径
已有 AI 产品不需要一开始就做成完整 Agent Product。更常见的路线是分阶段补齐产品对象。
| 阶段 | 产品形态 | 用户输入 | 系统输出 | 需要新增的产品对象 |
|---|---|---|---|---|
| 1 | Chatbot | 问题 | 回答 | 引用、反馈、历史记录 |
| 2 | Copilot | 请求建议 | 草稿、代码片段、方案 | 采纳、编辑、版本、上下文入口 |
| 3 | Task Assistant | 具体任务 | 结构化结果 | Task、Output、成功标准 |
| 4 | Supervised Agent | 目标 + 授权 | 工具执行 + 中间状态 | Tools、State、Control、Permission |
| 5 | Governed Agent Product | 可委托业务任务 | 可验收工作流结果 | Trace、Audit、Policy、Eval、Lifecycle |
这个演进路径的核心不是“让模型越来越自主”，而是逐步补齐产品对象。跳过中间对象直接追求“全自动”，通常会得到一个看似智能但用户不敢委托的系统。
反例与误区
带工具调用的客服机器人不一定是 Agent Product
它可以查询订单，也能回答物流状态。但如果没有任务状态、权限边界、人工升级、audit log，也不能处理退款、投诉、补偿等有后果的动作，它仍然只是带工具的客服 Bot。
能生成代码的聊天框不一定是 Developer Agent
如果没有 project、diff、preview、test、branch、rollback 和 deployment，用户得到的是代码建议，不是可交付工程对象。
企业知识库问答不一定是 Workflow Agent
它能查文档、总结制度、回答员工问题。但如果不能生成 ticket、发起审批、写回系统、记录处理状态，它更接近知识助手。
这些反例不是贬低产品价值，而是帮助 PM 选择正确路线。不是所有 AI 产品都必须成为 Agent Product。只有当用户真的想把任务委托给系统时，Agent Product 的设计问题才会出现。
PM 检查清单
设计或改造 AI 产品时，可以按下面顺序审查：
- 写清楚任务：用户把什么任务交给系统？成功标准是什么？
- 定义交付物：结果是回答、文件、PR、deployment、ticket、CRM record，还是 workflow state？
- 外部化状态：计划、进度、工具调用、中间结果、错误、审批、成本和输出是否可见？
- 设计控制点：用户在哪里暂停、修改计划、审批、拒绝、接管、回滚？
- 补治理能力：权限、审计、评估、监控和生命周期是否进入产品基础设施？
小结
Agent Product 不是某一种界面，也不是某一个技术组件。它是一种可委托的任务系统：用户把目标交给它，它在边界内执行动作，并把过程和结果暴露给人类监督、控制、评估和治理。
如果你的产品还只是在优化模型回答质量，你做的是 LLM App。
如果你开始定义任务对象、状态、权限、控制点、交付物和审计，你才开始做 Agent Product。
下一篇进入 Task Surface：Agent 产品首先要定义的，不是模型能力，而是用户到底能把什么任务交给它。