The AI Agent Product Design Handbook

第一章　AI Agent 产品的本质与设计范式

1.1　从 Chatbot 到 Agent：一条不可逆的演进路径

2022 年 11 月 ChatGPT 发布时，大多数人把它当作一个更聪明的搜索引擎。你问它问题，它给你答案——仅此而已。但真正的转折点不在于它能回答多少问题，而在于业界开始意识到：如果 AI 不只是回答问题，而是直接帮你把事情做完呢？

这就是 Agent 的起点。

要理解 Agent 产品的本质，我们需要先划清三条边界：

Chatbot（聊天机器人）：接收输入 → 生成回复。它的价值在于信息传递，典型的例子是早期的小冰、客服机器人。用户问"营业时间几点"，它回答"早 9 点到晚 9 点"。

AI Assistant（AI 助手）：接收指令 → 执行单一任务 → 返回结果。Siri、Alexa 是这一阶段的代表。你说"设一个早上 7 点的闹钟"，它帮你设好。但它的能力边界是固定的——你没法让 Siri 帮你预约一节健身课。

AI Agent（智能体）：接收目标 → 自主分解任务 → 调用工具执行 → 根据反馈调整计划 → 完成目标。Agent 的核心特征是自主性（autonomy）——你不需要告诉它每一步该怎么做，你只需要告诉它你要什么。

这张表看起来简单，但它在产品决策中的价值极高。我见过太多团队把"加个对话界面"等同于"做了个 Agent"，结果产品上线后发现用户根本不需要跟它聊天——用户需要的是事情被搞定。

核心判断：如果你的产品去掉对话界面就无法工作，那它大概率是个 Chatbot；如果你的产品去掉对话界面依然能工作（比如通过 API 触发、定时任务触发），那它才具备 Agent 的骨架。

1.2　Agent 的五层架构模型

抛开具体的技术实现，一个 Agent 产品在产品层面需要五层架构支撑。这不是技术架构图，而是产品决策框架——每一层都对应一组产品决策。

第一层：意图层（Intent Layer）

用户想要什么？这个问题看起来简单，但在 Agent 产品中极其复杂。用户说"帮我约下周的课"，Agent 需要理解：

• "课"是什么课？健身课？线上课程？
• "下周"是哪个时间段？
• 约哪个门店的？
• 有没有偏好教练？
• 如果约满了怎么办？

意图层的核心产品决策是：你的 Agent 需要理解多深的意图？ 意图理解越深，用户体验越好，但开发成本和出错概率也越高。

第二层：规划层（Planning Layer）

Agent 拿到意图后，需要分解成可执行的步骤。以 LifeOS 的健身场景为例，用户的意图是"训练后帮我吃好恢复餐"，Agent 的规划可能是：

1. 查看今日训练记录，计算热量消耗
2. 根据用户偏好（高蛋白、控碳水）筛选菜单
3. 调用麦当劳 API 创建订单
4. 生成支付链接，等待用户确认
5. 发送通知提醒用户取餐

规划层的核心产品决策是：规划由谁来做？ 是 AI 实时规划（灵活但不可控），还是预定义模板（可控但不灵活），还是两者的结合？

第三层：执行层（Execution Layer）

规划完成后，Agent 需要调用外部工具执行。这一层的核心是 Provider 架构——每个外部服务（LeFit、麦当劳、日历、支付）都是一个独立的 Provider，通过统一接口接入。

执行层的核心产品决策是：哪些操作可以自动执行，哪些必须人工确认？ 这就是 HITL（Human-in-the-Loop）边界设计。在 LifeOS 中，预约课程可以自动执行，但支付必须由用户完成——AI 可以下单，但不能付钱。

第四层：反馈层（Feedback Layer）

执行结果需要反馈给用户，同时反馈给 Agent 自身用于学习。反馈层包括：

• 用户反馈：通知、确认、拒绝、修改
• 系统反馈：执行成功/失败日志、性能指标
• 学习反馈：用户偏好更新、执行策略优化

反馈层的核心产品决策是：反馈粒度多细？ 是只告诉用户"搞定了"，还是展示完整的执行过程让用户审查？

第五层：安全层（Safety Layer）

安全不是独立的一层，而是横跨所有层的约束。包括输入验证、权限控制、操作审计、应急停止等。我们会在第四章详细展开。

架构决策矩阵

1.3　真实案例拆解：四款 Agent 产品的设计哲学

案例一：ChatGPT——从问答到 Agent 的渐进演化

ChatGPT 的 Agent 化是一个教科书级的产品演化路径。2022 年发布时它只是对话工具；2023 年加入了 Code Interpreter 和 Browsing，开始具备工具调用能力；2024 年推出 GPTs 和 Actions，允许用户自定义工具；2025 年的 GPT-5 进一步强化了 Agent 能力。

ChatGPT 的设计哲学是渐进式赋权：先让用户习惯对话，再逐步引入工具调用，最后开放 Agent 能力。这种策略的好处是用户教育成本极低——当你开始用 ChatGPT 执行任务时，你已经跟它聊了几百轮了。

产品启示：如果你的 Agent 产品面向大众用户，不要一上来就给全部自主权。先让用户通过对话建立信任，再逐步开放执行能力。

案例二：Cursor——IDE 内嵌的 Agent 范式

Cursor 是 2025 年最火的 AI 编程工具，估值已达 90 亿美元。它的成功不在于 AI 能力本身（底层用的也是 GPT/Claude），而在于它把 Agent 能力嵌入了用户已有的工作流。

Cursor 的杀手级功能是 TAB 补全——不是简单的代码补全，而是理解你的修改意图后，帮你一次性改完所有关联位置。这个功能抓住了开发者最痛的点：重构时的机械修改。

后来 Cursor 推出了 Agent Mode 和 Background Agent，从"帮你补全代码"进化到"帮你完成任务"。关键设计决策是 Accept/Reject 按钮——每次 Agent 修改代码，用户都能逐条审查。这就是 HITL 在编程场景中的精确落地。

产品启示：Agent 产品最好的入口不是新建一个应用，而是嵌入用户已有的工作流。Cursor 没有让开发者切换工具，而是改造了他们已经在用的 VS Code。

案例三：Devin——异步 Agent 的开创者

Devin 被称为"第一个 AI 软件工程师"。它的核心创新不是代码生成能力，而是异步执行模式：你给它一个任务（比如"修复这个 GitHub Issue"），它自己在沙箱环境中规划、编码、测试、提 PR，你只需要最后审查结果。

Gumroad CEO Sahil Lavingia 公开分享过：Devin 已经写了 Gumroad 41% 的 PR，目标是年底达到 80%。他用 3.3 万美元的奖金激励工程师使用 Devin，最终有三位工程师的 PR 数超过了他本人。

Devin 的设计哲学是实习生模式：把 AI 当作一个需要指导但能独立工作的实习生。你不盯着他写每一行代码，但你审查他的产出。

产品启示：异步 Agent 的关键不是 AI 能力有多强，而是信任建立机制有多好。Devin 通过录制执行过程、提供 Follow Devin 功能、在关键决策点暂停询问，构建了一套完整的信任链。

案例四：LifeOS——从 0 到 1 的 Agent 产品设计实践

LifeOS 是一个 AI Fitness Execution Agent，核心理念是"不推荐，不记录，执行"。它的 MVP 只做两件事：自动预约 LeFit 健身课程、自动下单麦当劳恢复餐。

LifeOS 在产品设计上做了几个关键决策：

决策一：执行优先，而非推荐优先。 大多数健身 App 让用户自己选课、自己下单。LifeOS 反过来——AI 决定上什么课，自动帮你约好；AI 决定吃什么，直接帮你下单。用户只需要知道"已经搞定了"。

决策二：HITL 硬边界。 AI 可以创建订单，但不能完成支付。麦当劳订单创建后状态为 AWAITING_PAYMENT，系统只提供支付链接，绝不自动扣款。这个边界是产品设计层面的硬约束，不是技术限制。

决策三：Provider 可插拔架构。 每个外部服务（LeFit、麦当劳）作为独立 Provider 实现，遵循统一接口。这意味着未来替换麦当劳为肯德基，或者新增滴滴打车，不需要修改核心逻辑。

决策四：Documentation First。 在写任何代码之前，先定义 PROJECT_BIBLE.md（项目圣经）、产品架构、系统架构、核心理念。这个决策看起来慢，但在后续开发中节省了大量返工时间。

产品启示：Agent 产品的 MVP 不应该追求功能数量，而应该追求单个场景的完整闭环。LifeOS 只做了两个场景，但每个场景从意图理解到执行完成再到用户确认，全链路跑通。

1.4　Agent 产品设计四原则

基于以上案例分析和实践观察，我提炼了 Agent 产品设计的四条核心原则：

原则一：执行优先于推荐

传统产品的逻辑是"我推荐，你执行"。Agent 产品的逻辑应该反过来："我执行，你确认"。这不是简单的顺序调整，而是产品定位的根本转变。

判断标准很简单：如果你的产品去掉 AI 推荐功能，用户用起来没有本质区别，那你的 AI 还不够 Agent。 真正的 Agent 产品，去掉 AI 后用户会感到明显的不便——因为他们已经习惯了"事情自动被搞定"。

原则二：边界优先于能力

AI 能做什么很重要，但 AI 不能做什么更重要。在设计 Agent 产品时，你应该先定义边界，再扩展能力。

LifeOS 的做法值得参考：在 PROJECT_BIBLE.md 中明确写道"AI 可以制定计划、分析数据、推荐选项、自动化执行；AI 不可以完成支付、未经确认执行不可逆操作"。这些边界不是事后补的，而是在 Day 1 就定义好的。

原则三：反馈优先于完美

Agent 不可能一次做对。与其追求 100% 的准确率，不如建立高效的反馈循环，让用户能快速纠正错误。

Cursor 的 Accept/Reject 机制就是这一原则的完美体现——它不试图保证每次修改都正确，而是让用户能以最低成本审查和纠正。

原则四：嵌入优先于新建

最好的 Agent 产品不是让用户打开一个新应用，而是嵌入用户已有的工作流。Cursor 嵌入了 IDE，Devin 嵌入了 GitHub PR 流程，ChatGPT 的 GPTs 嵌入了用户的日常对话。

如果你的 Agent 产品需要用户改变习惯才能使用，那它的获客成本会高得吓人。

1.5　Agent 产品可行性评估 Checklist

在正式开始设计 Agent 产品之前，用以下 Checklist 评估可行性。如果任何一项答"否"，你需要认真考虑是否应该做 Agent 产品，或者是否应该降低 Agent 的自主性级别。

使用建议：这个 Checklist 不是一票否决制，而是风险提示。第 3 项和第 7 项是最关键的——如果操作不可逆且无法定义边界，这个场景目前不适合做成 Agent 产品。

1.6　本章小结与行动建议

核心观点回顾

1. Agent 的本质是自主执行，不是更聪明的对话。判断标准是：去掉对话界面，产品是否还能工作。
2. 五层架构模型（意图层、规划层、执行层、反馈层、安全层）是 Agent 产品设计的决策框架，每一层都对应一组必须做出的产品决策。
3. 四款产品的设计哲学各不相同：ChatGPT 走渐进演化路线，Cursor 走工作流嵌入路线，Devin 走异步执行路线，LifeOS 走垂直场景闭环路线。没有唯一正确答案，但有适合你的路线。
4. 四条设计原则：执行优先于推荐、边界优先于能力、反馈优先于完美、嵌入优先于新建。

行动建议

1. 画出你的五层架构图：用白板或文档，把你的产品在五层架构中的每一层决策写下来。如果某一层你写不出决策，说明你还没想清楚。
2. 完成可行性评估 Checklist：诚实回答 8 个问题。如果有 3 个以上"否"，先缩小 MVP 范围。
3. 定义你的 HITL 边界：列一张表，左边写"AI 可以做的事"，右边写"AI 不可以做的事"。这张表将成为你后续所有产品决策的基础。
4. 选择你的设计哲学：参考四个案例，确定你的产品走哪条路线。不要试图同时走四条路。

延伸思考

当 AI 能力越来越强，Agent 的边界应该扩大还是缩小？

这是一个没有标准答案的问题，但我倾向于：边界应该随信任积累而渐进扩大，而非随能力提升而自动扩大。 信任来自透明度和可控性，不是来自能力展示。一个用户能审查、能纠正、能停止的 Agent，比一个能力更强但不可控的 Agent，更容易被接受。

这一点在后续章节中会反复出现——从意图理解到安全合规，Agent 产品设计的核心始终是在自主性和可控性之间找到平衡点。

第二章　用户意图理解与多轮对话设计

2.1　意图理解：Agent 产品最难的"第一步"

如果说 Agent 产品的架构是骨架，那么意图理解就是灵魂。一个 Agent 能力再强，如果它不能准确理解用户想要什么，所有执行都是徒劳。

但意图理解在 Agent 产品中面临一个根本矛盾：用户表达意图的方式天然是模糊的，但执行需要精确的指令。

举个例子。用户对 LifeOS 说："帮我约下周的课。"

这句话在人跟人之间交流没问题——你的健身教练会追问"约哪个门店？什么时间？哪位教练？"。但在 Agent 产品中，你需要设计一套系统，让 AI 能像教练一样追问，同时不让用户觉得繁琐。

这就是多轮对话设计的核心挑战：在模糊和精确之间搭一座桥。

意图理解的三层模型

我在实践中总结了一个意图理解的三层模型，用来指导产品设计：

第一层：显式意图（Explicit Intent）——用户直接说出来的需求。"帮我约下周二的瑜伽课"是显式意图。这一层最容易理解，但也最容易被高估——因为用户的显式表达往往不完整。

第二层：隐式意图（Implicit Intent）——用户没说但可以推断的需求。用户说"帮我约下周二的瑜伽课"，隐式意图可能包括：约常去的门店、选平时上的教练、选下班后的时间段。这一层需要用户画像和历史行为数据支撑。

第三层：潜在意图（Latent Intent）——用户自己都没意识到的需求。用户约了周二瑜伽课，潜在意图可能是"这周训练量不够，需要补充一次低强度训练"。这一层最难捕捉，但如果做好了，产品体验会从"好用"升级为"懂我"。

产品决策：你的 Agent 产品应该从第一层开始，逐步向第二层和第三层演进。不要在 MVP 阶段就追求潜在意图理解——那样做会让系统过于复杂，且准确率无法保证。

2.2　多轮对话的四种模式

确定了意图理解的目标后，接下来要设计对话流程。在 Agent 产品中，多轮对话不是为了聊天，而是为了消除歧义、收集信息、确认执行。

模式一：澄清式对话（Clarification）

适用场景：用户输入模糊，需要追问细节。

设计要点：

• 每次最多追问一个问题，不要一次抛出多个问题
• 优先用选择题代替开放题
• 提供默认选项，让用户可以"一键确认"而非重新输入

案例：Gemini Deep Research 在收到用户指令后，会先进行任务拆解，然后提供"修改方案"按钮。用户可以直接在方案上编辑，而不需要重新输入指令。这种设计把开放式的追问变成了结构化的确认。

模式二：确认式对话（Confirmation）

适用场景：执行不可逆操作前，需要用户确认。

设计要点：

• 明确告知将要执行的操作、预期结果和潜在风险
• 提供"确认执行"和"修改"两个选项，而非简单的"是/否"
• 倒计时机制——如果用户长时间不确认，操作自动取消

案例：LifeOS 在创建麦当劳订单后，不会直接提交，而是生成支付链接，状态标记为 AWAITING_PAYMENT。用户看到的是"订单已创建，请点击链接完成支付"，而非"已下单成功"。这个状态设计本身就是一种确认式对话。

模式三：纠偏式对话（Correction）

适用场景：Agent 执行过程中发现偏差，需要用户介入。

设计要点：

• 及时暂停，不要等到全部执行完才告知问题
• 清晰描述偏差内容和可选的纠正方案
• 保留已完成的进度，让用户可以"从断点继续"而非"从头重来"

案例：Devin 在编程过程中遇到需要共同决策的关卡（比如 API 调用方式、数据存储方案），会主动暂停询问用户。同时它会建议把用户的回答添加为"知识"，下次遇到类似情况自动处理。

模式四：反馈式对话（Feedback）

适用场景：执行完成后，收集用户对结果的反馈。

设计要点：

• 反馈入口要轻——一个表情或一句话就够
• 不要在每次执行后都强制要求反馈
• 把反馈结果用于优化下次执行，形成闭环

案例：Cursor 的 Accept/Reject 机制本质上就是一种反馈式对话。用户拒绝某次修改，Cursor 会记录这个信号用于后续优化。关键在于反馈成本极低——一个按钮点击就完成了。

对话模式选择矩阵

2.3　上下文管理：让 Agent "记住"用户

意图理解和多轮对话都依赖一个基础能力：上下文管理。如果 Agent 每次对话都像第一次见面，用户体验会很糟糕。

上下文的三个时间尺度

短期上下文（Session Context）：当前对话会话内的信息。用户说"约下周的课"，然后说"改到周二"，Agent 需要知道"周二"指的是"下周二"。短期上下文通常由 LLM 的上下文窗口直接处理。

中期上下文（User Context）：用户的历史偏好和行为模式。用户每次都约同一个门店的课，Agent 应该把这个作为默认选项。中期上下文需要持久化存储，通常以用户画像的形式管理。

长期上下文（Knowledge Context）：领域知识和产品规则。瑜伽课需要提前 24 小时预约、恢复餐应该在训练后 30 分钟内摄入——这些是固定的领域知识。长期上下文通常以知识库或规则引擎的形式管理。

上下文管理的工程实践

在实际产品中，上下文管理面临一个核心矛盾：LLM 的上下文窗口是有限的，但用户的上下文是无限的。

解决这个矛盾的方法是分层加载：

1. 始终加载：系统 Prompt、用户核心画像（偏好门店、饮食禁忌等）、当前任务上下文
2. 按需加载：历史对话摘要、相关领域知识、用户近期行为
3. 不加载：完整的历史对话原文、不相关的用户数据

LifeOS 的做法是维护一个 UserProfile 实体，存储用户的核心偏好（健身目标、饮食类型、预算、身高体重等）。每次 Agent 执行时，UserProfile 作为系统 Prompt 的一部分注入，确保 Agent 始终"知道"用户是谁。

上下文管理的 Checklist

2.4　Agent 交互设计的七大模式

在 Agent 产品的交互层面，业界已经总结出了一套相对成熟的设计模式。这些模式来自对 Manus、Cursor、Devin、Gemini Deep Research、flowith 等产品的深入分析。

模式一：注意力引导（Attention Guidance）

核心理念：引导用户关注正在发生的、最关键的信息。

Agent 产品的界面通常包含多个模块——对话区、进度区、结果区、代码区。如果不做注意力引导，用户会被信息淹没。

设计要点：渐进式展示而非一次性呈现；非核心信息折叠隐藏；高亮正在执行的操作。

Cursor 的做法是对话记录中的分解步骤与代码用颜色对应——绿色代表新增代码，红色代表删除。用户不需要在对话和代码之间来回查找，一眼就能定位到修改位置。

模式二：就地澄清（In-Place Clarification）

核心理念：让用户在结果上直接修改，而不是回到对话框重新输入。

当用户对 Agent 的输出不满意时，最差的体验是让他们在对话框里描述"哪里不对"。最好的体验是让他们直接在结果上标注和编辑。

设计要点：提供就地编辑入口；编辑区与预览区保持一致；修改后有明确反馈。

v0 和 Cursor 支持用户在主窗口直接编辑 AI 生成的代码。v0 甚至支持用户选中界面的某一局部进行修改或局部重新运行——这种"所见即所改"的体验是 Agent 交互的标杆。

模式三：自动建议（Auto-Suggestion）

核心理念：用选择代替输入，邀请用户协作而非依赖人工。

当 Agent 需要用户决策时，提供范围适当的选项比开放式提问更高效。

设计要点：关键决策点提供 3-5 个选项；指出错误的同时给出解决方案；允许用户在选项之外自由输入。

模式四：思考外显（Think-Aloud）

核心理念：让 AI 展示思考过程、计划和决策依据。

Agent 的"黑盒"问题是用户信任的最大障碍。如果用户不知道 Agent 为什么做某个决策，他们就不敢把重要任务交给它。

设计要点：AI 工作状态和进度始终可见；用自然语言解释决策；允许用户调整推理展示的详细程度。

Grok 用纵向进度条展示分解步骤，同时作为导航菜单——用户点击某个步骤可以在右侧查看详情。GenSpark 在文字样式上区分对话内容和执行情况，用户可点击"View"查看工具调用和引用信息。

模式五：上下文/知识匹配（Context/Knowledge Match）

核心理念：主动识别相似问题，自动调取历史信息，减轻用户记忆负担。

设计要点：记录用户选择以简化未来任务；标注正在使用的上下文/知识；提供修改或移除自动引用的选项；隐私敏感场景需确认。

flowith 的"知识花园"和 Devin 的"Knowledge"功能都是这一模式的实践——把短期记忆转化为长期记忆，存储固定规则和用户偏好，加强未来行动决策的效率。

模式六：暂停-反馈-继续（Pause-Feedback-Continue）

核心理念：任务执行中允许暂停、反馈和决定后续操作，始终保证用户控制权。

设计要点：提供明显的暂停按钮；允许中止并保存已完成内容；关键决策点自动暂停；操作可撤销。

GenSpark 提供暂停按钮，用户可随时中止、继续任务。Cursor 在关键节点提供 Accept/Reject 按钮。这些设计的核心是：用户永远不是旁观者，而是方向盘的持有者。

模式七：环境/工作流适配（Environment/Workflow Adaptability）

核心理念：Agent 与现有工作环境融合，减少用户腾挪的麻烦。

设计要点：任务启动方式灵活；提供多种结果使用方式；支持跨平台同步。

Gemini 针对 Google Workspace 的设计是这一模式的标杆——当用户在 Google Docs 中工作时，Gemini 会适时主动出现，提供与当前文档相关的 AI 建议。用户不需要切换到 Gemini 首页，AI 来到用户工作的地方。

2.5　对话设计实战：从需求到流程

理论讲完了，我们来看一个完整的对话设计实战。以 LifeOS 的"自动预约课程"场景为例，展示从需求到对话流程的完整设计过程。

Step 1：定义场景边界

• 触发方式：用户主动发起 / 系统定时触发
• 执行目标：预约一节合适的健身课程
• 可逆性：课程可在开始前 2 小时取消
• HITL 边界：预约可自动执行，取消需用户确认

Step 2：绘制意图树

预约课程
├── 确定时间
│   ├── 用户指定 → 使用指定时间
│   └── 用户未指定 → 根据历史偏好推荐
├── 确定课程类型
│   ├── 用户指定 → 使用指定类型
│   └── 用户未指定 → 根据训练计划推荐
├── 确定门店
│   ├── 用户指定 → 使用指定门店
│   └── 用户未指定 → 使用常去门店
├── 执行预约
│   ├── 成功 → 通知用户
│   └── 失败 → 提供替代方案
└── 确认结果
    └── 用户确认/修改

Step 3：设计对话流程

根据意图树，设计三种对话路径：

路径 A（完整信息）：用户说"约明天晚上 7 点 LeFit 国贸店的瑜伽课" → Agent 直接执行 → 通知结果

路径 B（部分信息）：用户说"帮我约下周的课" → Agent 根据画像填充默认值 → 确认式对话"下周二晚 7 点国贸店瑜伽课，确认预约？" → 用户确认 → 执行

路径 C（信息缺失）：新用户说"帮我约课" → 澄清式对话"你想约哪个门店？" → "什么时间？" → "有偏好的课程类型吗？" → 执行

Step 4：设计异常处理

• 约满：Agent 自动查找同时段替代课程，提供选择
• 时间冲突：Agent 检查用户日历，提示冲突并提供调整选项
• 网络错误：自动重试 3 次，仍失败则通知用户手动处理
• 门店关闭：推荐最近可用门店

Step 5：设计反馈闭环

• 执行成功 → 推送通知"已预约周二 19:00 国贸店瑜伽课"
• 用户可查看详情、取消、修改
• 记录用户是否取消/修改，用于优化下次推荐

2.6　本章小结与行动建议

核心观点回顾

1. 意图理解有三层：显式意图、隐式意图、潜在意图。MVP 从第一层开始，逐步演进。
2. 多轮对话有四种模式：澄清式、确认式、纠偏式、反馈式。根据输入明确度和操作可逆性选择。
3. 上下文管理是基础：分三层（短期/中期/长期），按需加载，控制 token 预算。
4. 七大交互设计模式：注意力引导、就地澄清、自动建议、思考外显、上下文匹配、暂停-反馈-继续、环境适配。不必全部实现，但每一条都值得考虑。
5. 对话设计的五步法：定义边界 → 绘制意图树 → 设计对话流程 → 设计异常处理 → 设计反馈闭环。

行动建议

1. 画一张意图树：选择你的 Agent 的核心场景，画出完整的意图分解树。每个分支标注"用户指定"和"默认推断"两种路径。
2. 设计三种对话路径：完整信息、部分信息、信息缺失。确保三种路径都能在 3 轮对话内完成核心任务。
3. 定义用户画像字段：列出你的 Agent 需要知道的用户信息，按"必须知道"和"最好知道"分级。MVP 阶段只收集"必须知道"的信息。
4. 审查七大交互模式：逐一对照你的产品设计，标注"已实现"、"计划实现"和"暂不需要"。重点关注模式一（注意力引导）和模式四（思考外显）——这两个对用户信任影响最大。

延伸思考

Agent 产品的对话设计，最终目标是让对话越来越少。

这听起来矛盾，但逻辑很清晰：好的 Agent 产品应该随着使用时间增长，越来越少地需要用户说话。 第一周，用户可能需要 5 轮对话才能完成一次预约。第一个月后，应该只需要 1 轮——Agent 已经学会了用户的偏好。第三个月，可能 0 轮——Agent 主动在合适的时间预约合适的课程，用户只需要收到一通知："已为您预约明天的瑜伽课，如需修改请点击这里。"

对话是手段，不是目的。当 Agent 足够了解用户时，对话应该消失。

第三章　Skill 生态与插件化架构设计

3.1　为什么 Agent 需要 Skill 生态

2025 年 11 月，Anthropic 发布了 MCP（Model Context Protocol），这是一个让 AI 模型安全连接外部工具和数据源的开放协议。几个月内，OpenAI、Google 纷纷宣布支持类似机制。这不是巧合——整个行业意识到：Agent 的能力上限不取决于模型有多聪明，而取决于它能调用多少工具。

一个不接入任何外部系统的 Agent，不管底层模型多强大，都只是一个更聪明的聊天机器人。真正的 Agent 需要能预约课程、下单外卖、同步日历、查询数据——这些能力来自 Skill 生态。

Skill、Plugin、Provider：三个概念的辨析

在开始架构设计之前，我们需要先理清三个经常被混淆的概念：

Skill（技能）：Agent 可以调用的原子能力单元。比如"搜索网页"、"读取文件"、"调用某个 API"。Skill 是最细粒度的能力封装。

Plugin（插件）：一组相关 Skill 的集合，通常对应一个外部服务。比如"麦当劳插件"包含"查询菜单"、"创建订单"、"查询订单状态"等 Skill。

Provider（供应方）：产品层面的抽象，代表一个外部服务接入方。Provider 封装了认证、重试、降级等逻辑，内部可能包含一个或多个 Plugin。

产品决策：在 MVP 阶段，不需要严格区分三者。但随着产品演进，这三层分离是必然的——因为不同外部服务的接入复杂度、认证方式、可靠性都不同，需要不同层次的抽象来管理。

3.2　插件化架构的设计原则

原则一：接口统一，实现各异

所有 Provider 必须遵循同一接口，但内部实现可以完全不同。这是软件工程的基本原则，在 Agent 产品中尤为重要——因为你需要频繁替换和新增外部服务。

LifeOS 的 Provider 架构是这一原则的典型实践。所有 Provider 遵循统一接口：

BookingProvider
├── LeFitProvider     # 通过 API 预约
├── KeepProvider      # 通过 Skill 预约
└── SuperMonkeyProvider # 通过浏览器自动化预约

三个 Provider 的实现方式完全不同——LeFit 用 API，Keep 用 Skill，超级猩猩可能需要浏览器自动化。但对 Agent 来说，调用方式完全一致：booking_provider.book(course_id, session_id)。

这意味着，当你要把 LeFit 换成另一个健身房品牌时，只需要实现新的 Provider，不需要修改 Agent 核心逻辑。

原则二：优先级链，逐级降级

外部服务不可能 100% 可用。当 API 挂了、Skill 过期了、浏览器自动化被反爬了，Agent 需要有备选方案。

LifeOS 在 PROJECT_BIBLE.md 中定义了明确的优先级：官方 API > Skill/MCP > 浏览器自动化。浏览器自动化始终是兜底方案（fallback），而不是首选。

这个优先级链不仅影响技术实现，还影响产品设计——你需要告诉用户"这个操作可能需要更长时间"或"这个服务暂时不可用，已为您切换到替代方案"。

原则三：认证隔离，最小权限

每个 Provider 使用独立的认证凭证，凭证之间完全隔离。一个 Provider 的 token 泄露不应该影响其他 Provider。

在工程实现上，LifeOS 使用 AES-256-GCM 加密存储 Provider 的 access token，每个 Provider 的密钥独立管理。这意味着即使数据库被攻破，攻击者也无法直接获取明文凭证。

产品决策：认证隔离不仅是安全要求，也是用户体验要求。用户可能愿意把美团账号授权给你的 Agent，但不愿意把支付宝账号也授权。逐个授权、逐个撤销的体验，比一次性全量授权更让用户安心。

原则四：能力声明，动态发现

Agent 不应该硬编码知道哪些 Skill 可用，而应该通过能力声明动态发现。这意味着：

• 新增一个 Provider 时，Agent 自动发现它提供的能力
• 某个 Provider 不可用时，Agent 自动从能力列表中移除
• Agent 根据当前可用能力动态调整执行计划

MCP 协议的设计就体现了这一原则——工具以标准格式声明自己的能力（名称、描述、参数 schema），Agent 通过读取这些声明来决定何时调用哪个工具。

3.3　Skill 生态的分层架构

一个成熟的 Agent 产品，Skill 生态通常分为三层：

第一层：核心 Skill（Core Skills）

产品自带的、不可卸载的基础能力。这些 Skill 定义了产品的核心价值主张。

以 LifeOS 为例，核心 Skill 包括：

• 课程预约：查询课表、预约课程、取消预约
• 餐饮下单：查询菜单、创建订单、查询订单状态
• 通知推送：向用户发送执行结果通知
• 日历同步：将计划同步到用户日历

核心 Skill 的设计原则是少而精——每个 Skill 必须支撑一个完整的用户场景，而不是半个。

第二层：扩展 Skill（Extension Skills）

由产品团队或第三方开发的、可按需启用的能力。这些 Skill 拓展了产品的适用场景，但不是核心价值主张。

LifeOS 的扩展 Skill 可能包括：

• 天气查询：根据天气调整训练计划
• 交通查询：提醒用户出发时间
• 健康数据同步：从 Apple Health 读取运动数据
• 社交分享：将训练成果分享到朋友圈

扩展 Skill 的设计原则是松耦合——每个扩展 Skill 独立安装、独立配置、独立卸载，不影响核心功能。

第三层：用户自定义 Skill（Custom Skills）

由用户自己创建的能力。这是 Skill 生态的终极形态——当用户可以自定义 Skill 时，产品的场景边界就不再由产品团队定义，而是由用户需求定义。

ChatGPT 的 GPTs 和 Custom Actions 就是这一层的实践。用户可以定义自己的 Action（Skill），让 ChatGPT 调用自己公司的内部 API。

Skill 生态成熟度模型

产品决策：MVP 阶段应该处于 L0-L1 之间——核心能力可插拔，但不需要建市场。当核心场景验证成功后，再逐步向 L2-L3 演进。

3.4　框架选择：LangChain vs CrewAI vs 自研

在构建 Agent 的技术框架上，开发者社区有三个主流选择。产品经理虽然不需要写代码，但需要理解框架选择对产品设计的影响。

LangChain / LangGraph：灵活但复杂

LangChain 是目前生态最大的 Agent 开发框架，GitHub 星标超过 10 万。它的核心价值是可组合性——你可以把 Prompt、模型、工具、记忆像乐高积木一样拼在一起。

LangGraph 是 LangChain 的进化版，用有向图来定义 Agent 的执行流程，支持状态管理和人在环路检查点。

对产品设计的影响：

• 优点：最大灵活性，700+ 集成，可以根据产品需求精确控制每一步
• 缺点：学习曲线陡峭，简单任务也需要大量样板代码，API 变动频繁
• 适合：需要精细控制 Agent 行为的复杂产品

CrewAI：角色驱动的多 Agent 协作

CrewAI 用"团队"的隐喻来组织多个 Agent——你定义一个"研究员"、"分析师"、"写作者"，让他们协作完成任务。2025 年获得 1800 万美元 A 轮融资，被 PwC、IBM、Oracle 等企业采用。

对产品设计的影响：

• 优点：直觉化的角色抽象，50 行代码就能跑起多 Agent 系统，原型速度快
• 缺点：灵活性不如 LangGraph，多 Agent 通信成本高（更多 LLM 调用 = 更高成本），错误处理不够成熟
• 适合：任务可以自然分解为角色的场景（研究→分析→写作）

自研框架：最大控制权

很多成功的 Agent 产品选择了自研框架——Devin、Cursor、Manus 都没有用现成的框架，而是自建了 Agent 运行时。

对产品设计的影响：

• 优点：完全控制，没有框架依赖，可以针对特定场景深度优化
• 缺点：开发成本高，需要自己解决记忆管理、工具调用、错误恢复等问题
• 适合：有工程实力、产品场景独特、需要极致性能的团队

框架选择决策矩阵

我的建议：如果你是 1-3 人的小团队做 MVP，用 CrewAI 快速验证场景。如果验证成功需要上生产，迁移到 LangGraph 或自研。如果你是有工程实力的大团队，直接自研——长期来看控制权带来的收益远大于短期的时间节省。

3.5　LifeOS 的 Provider 架构实战拆解

让我们深入看一个真实的插件化架构设计案例。LifeOS 的 Provider 架构经历了从概念到实现的完整过程，其中的设计决策对其他 Agent 产品有直接参考价值。

架构全貌

Planner Agent
      ↓
Provider Router（路由层）
      ↓
┌──────────────┬──────────────┐
│BookingProvider│ MealProvider │
│  ↓            │  ↓           │
│ LeFit API     │ McDonald's   │
│ Keep Skill    │ API          │
│ 浏览器兜底     │ 浏览器兜底    │
└──────────────┴──────────────┘
      ↓
Notification Provider
      ↓
用户

关键设计决策

决策一：Provider Router 作为唯一入口

Agent 不直接调用 Provider，而是通过 Router 路由。Router 负责：

• 根据 task 类型选择合适的 Provider
• 处理 Provider 不可用时的降级逻辑
• 统一计费和日志

这个设计的好处是 Agent 逻辑与 Provider 实现完全解耦。Agent 只说"预约一节课"，Router 决定用 LeFit 还是 Keep。

决策二：模拟模式与真实模式双轨运行

LifeOS 的执行层支持 ?mode=simulated|real 切换。在 simulated 模式下，Provider 返回模拟数据，不调用真实 API。

这个设计对开发和测试极其重要——你不需要真的预约一节课才能测试预约流程。同时，它也是 MVP 演示的安全网——在真实模式下不可控的因素，在模拟模式下完全可控。

决策三：Provider 凭证校验

在用户连接 Provider 账号时，系统会立即验证凭证有效性。如果 LeFit 的 token 过期了，系统会在连接阶段就告知用户"凭证无效"，而不是等到用户要预约时才失败。

这个设计减少了用户的挫败感——没有什么比"我要用的时候告诉我不能用"更让人恼火的了。

决策四：执行日志全量记录

每次 Provider 调用的输入、输出、耗时、结果都记录在 ExecutionLog 中。ExecutionLog 有一个 source 字段标记来源：AI（Agent 自动执行）、USER（用户手动操作）、SYSTEM（系统定时任务）、PROVIDER（Provider 主动回调）。

这个设计为后续的产品分析提供了基础——你可以知道哪些 Provider 调用最频繁、哪些最容易失败、用户最常手动干预哪些环节。

架构设计的 Checklist

3.6　Skill 生态的冷启动策略

Skill 生态有一个鸡生蛋蛋生鸡的问题：用户因为 Skill 少而不来，Skill 开发者因为用户少而不做。这个问题在 Agent 产品中尤其严重——因为 Agent 的价值直接取决于 Skill 数量。

策略一：自建核心 Skill，验证价值

不要等第三方来做 Skill。产品团队自己把核心场景的 Skill 全部做了，确保用户开箱即用。ChatGPT 最初也是自建了 Code Interpreter、Browsing 等核心 Skill，验证了 Agent 价值后才开放第三方生态。

策略二：降低 Skill 开发门槛

Skill 开发的门槛越低，第三方越愿意做。MCP 协议的价值就在于此——开发者只需要写一个 JSON Schema 描述自己的能力，不需要学习复杂的框架。

LifeOS 的做法是让每个 Provider 只需要实现一个标准接口，接口内部怎么实现完全自由。这意味着第三方可以用任何语言、任何方式来实现 Provider——只要接口对齐就行。

策略三：内测优先，逐步开放

不要一上来就开放 Skill 市场给所有人。先邀请少量合作伙伴内测，打磨 Skill 审核流程和开发文档，再逐步开放。

ChatGPT 的 GPTs Store 就是这个路径——先让 Plus 用户创建 GPTs，验证了创建流程和审核机制后，才开放给所有用户。

策略四：收益分成，激励开发

Skill 生态需要经济激励。最直接的方式是收益分成——Skill 开发者可以从调用费用中获取分成。这需要产品设计层面就考虑计费架构，确保每次 Skill 调用都能追踪到调用者和提供者。

3.7　本章小结与行动建议

核心观点回顾

1. Skill 生态决定 Agent 能力上限。模型再强，没有工具就是聊天机器人。
2. 三层架构：Skill（原子能力）→ Plugin（能力集合）→ Provider（服务接入）。MVP 不必严格区分，但长期必须分层。
3. 四条设计原则：接口统一、优先级链降级、认证隔离最小权限、能力声明动态发现。
4. Skill 生态四阶段：L0 单体 → L1 插件化 → L2 生态化 → L3 平台化。MVP 在 L0-L1，验证后向 L2-L3 演进。
5. 框架选择：CrewAI 快速原型，LangGraph 灵活生产，自研极致控制。没有银弹，看阶段和团队。
6. 冷启动策略：自建核心 Skill → 降低开发门槛 → 内测优先 → 收益分成。

行动建议

1. 列出你的核心 Skill 清单：你的 Agent MVP 需要哪些原子能力？每个 Skill 对应一个用户场景，不能对应场景的 Skill 砍掉。
2. 设计 Provider 接口：定义一个所有外部服务都遵循的接口。接口要简单——输入是结构化参数，输出是标准化结果。
3. 实现模拟模式：在写真实 API 集成之前，先实现模拟模式。这让你的开发和测试效率提升 10 倍。
4. 画出你的 Skill 生态路线图：标注当前处于哪个阶段，以及达到下一阶段需要什么条件。

延伸思考

MCP 协议的出现，会不会让 Skill 生态标准化，从而让 Agent 产品的差异化消失？

我的判断是：MCP 会让工具接入标准化，但不会让 Agent 产品同质化。 就像 HTTP 协议标准化了 Web 通信，但 Google 和 Facebook 的产品依然截然不同。Agent 产品的差异化将来自三个方面：意图理解的深度、执行策略的智能度、以及用户信任的积累——这些都不是协议能标准化的。

协议解决的是"能不能连"的问题，产品解决的是"该不该做"的问题。后者永远是产品经理的主场。

第四章　安全合规与边界设计

4.1　为什么 Agent 产品的安全比传统软件更难

传统软件的安全问题，通常是"数据泄露"或"权限越界"。这些问题很严重，但影响范围可控——一个漏洞被利用，修复一个漏洞。

Agent 产品的安全问题复杂得多。因为 Agent 不只是处理数据，它执行操作。一个被 Prompt Injection 攻击的 Agent，可能不是泄露几条数据，而是给你的客户发了一堆垃圾邮件、删了生产数据库、或者帮你下了一堆你根本不需要的外卖。

LLM 出错，你得到一个错误答案。Agent 出错，你可能得到一笔未经授权的交易。

这就是为什么 Agent 产品的安全不能是"上线后加的安全功能"，而必须是"Day 1 就设计好的架构约束"。

Agent 安全新攻击面

OWASP 在 2025 年发布了 LLM 应用十大安全风险（Top 10 for LLM Applications），其中与 Agent 直接相关的包括：

LLM01 Prompt Injection（提示注入）：攻击者通过恶意输入覆盖系统指令，让 Agent 执行非授权操作。在 Agent 场景中，这不只是生成有害文本——可能触发未授权的工具调用。

LLM02 Sensitive Information Disclosure（敏感信息泄露）：Agent 在执行过程中可能意外暴露 PII（个人身份信息）、API 密钥或其他敏感数据。

LLM06 Excessive Agency（过度自主）：Agent 被授予了超出必要的权限，导致它可以执行高风险操作。这是 Agent 产品特有的风险——传统软件不会"自作主张"。

LLM08 Vector and Embedding Weaknesses（向量与嵌入弱点）：RAG 系统中的知识库可能被注入恶意内容，影响 Agent 的决策。

行业数据显示：2025 年，39% 的企业报告 AI Agent 访问了不该访问的系统，32% 的企业发现 Agent 允许了不当的数据下载。这些数字在传统软件中是不可接受的，但在 Agent 领域，很多团队还没有意识到问题的严重性。

4.2　四层防护体系

Agent 产品的安全不能靠单一手段，需要多层防御（defense in depth）。就像银行的保险库不会只有一把锁——你需要层层设防，即使一层被突破，下一层仍然能挡住。

第一层：输入防护（Input Guardrails）

目标：在恶意输入到达 Agent 推理引擎之前拦截它。

关键措施：

• Prompt Injection 检测：识别已知的注入模式（如"忽略之前的指令"、"你现在是..."）
• 输入清洗：移除可能的恶意 payload（代码注入、SQL 注入）
• 长度限制：防止超长输入导致上下文窗口溢出
• 内容过滤：拦截违禁内容

工程实现：使用独立的输入检测模块，在用户输入进入 LLM 之前先过一遍。这个模块应该是确定性的（基于规则），而非概率性的（基于 LLM）——因为你不能用一个可能被注入的 LLM 来检测注入。

第二层：行为防护（Behavioral Guardrails）

目标：在 Agent 执行操作之前验证操作的合理性。

关键措施：

• 操作白名单：Agent 只能调用预定义的工具集合
• 参数校验：每个工具调用的参数必须在合法范围内
• 频率限制：防止 Agent 在短时间内发起大量调用
• 行为基线：建立 Agent 正常行为模式，偏离时告警

案例：LifeOS 的 Provider Router 在调用任何 Provider 之前，都会检查：这个 Provider 是否在当前用户的已授权列表中？这个操作是否在用户设置的允许范围内？如果用户只授权了"查询菜单"，Agent 不能执行"创建订单"。

第三层：输出防护（Output Guardrails）

目标：在 Agent 的输出到达用户或外部系统之前过滤危险内容。

关键措施：

• PII 检测：扫描输出中的个人身份信息（身份证号、手机号等）
• 内容审核：过滤有害、不当内容
• 操作确认：高风险操作在执行前需要用户确认
• 输出格式校验：确保输出符合预期格式，防止注入下游系统

第四层：执行防护（Action Guardrails）

目标：在 Agent 真正执行操作时设置最后一道防线。

关键措施：

• 沙箱执行：Agent 在隔离环境中运行，限制系统访问
• 最小权限：每个工具只授予完成其功能所需的最小权限
• 操作审计：所有操作记录日志，可追溯
• 紧急停止：一键暂停或关闭 Agent

四层防护对照表

4.3　HITL 边界设计：Agent 安全的核心

在所有安全措施中，HITL（Human-in-the-Loop，人在环路）是最重要的。因为不管你的防护有多强，Agent 总有可能做出你没想到的事情。HITL 是最后一道、也是最可靠的一道防线。

HITL 的三个级别

级别一：通知后执行（Notify-after）

Agent 自主执行操作，执行后通知用户。适用于低风险、可逆操作。

例子：LifeOS 自动预约课程后，推送通知"已为您预约明天的瑜伽课"。如果用户不满意，可以在课程开始前 2 小时取消。

级别二：确认后执行（Confirm-before）

Agent 准备好操作，但需要用户确认后才执行。适用于中风险或不可逆操作。

例子：LifeOS 创建麦当劳订单后，状态为 AWAITING_PAYMENT，系统提供支付链接。用户必须主动点击链接完成支付，系统绝不自动扣款。

级别三：人工执行（Human-only）

Agent 不执行操作，只提供信息或建议，由用户自己完成操作。适用于高风险或敏感操作。

例子：Agent 可以查询银行卡余额并分析消费趋势，但不能发起转账。转账操作必须由用户在银行 App 中完成。

HITL 边界设计矩阵

LifeOS 的 HITL 硬边界实践

LifeOS 在 PROJECT_BIBLE.md 中明确规定了 HITL 边界：

AI 可以：制定计划、分析数据、推荐选项、自动化执行 AI 不可以：完成支付、未经确认执行不可逆操作 用户始终拥有最终决定权。

这个边界不是写在文档里的建议，而是代码层面的硬约束。麦当劳订单的执行流程是：

1. Agent 调用 McDonald's API 创建订单 → 订单状态 CREATED
2. Agent 生成支付链接 → 订单状态 AWAITING_PAYMENT
3. 系统通知用户"订单已创建，请点击链接完成支付"
4. 用户点击链接，在麦当劳 App/小程序中完成支付 → 订单状态 PAID

在第 2 步和第 3 步之间，Agent 的所有操作都停止了。它不会自动跳转到支付页面，不会自动填入支付信息，不会自动点击支付按钮。这个"停顿"是产品设计层面的硬约束，不是技术限制。

为什么这个设计很重要？ 因为如果 AI 可以自动支付，用户的信任成本会急剧上升。用户会想："它今天帮我付了一顿麦当劳，明天会不会帮我付一套房？"信任一旦打破，几乎无法恢复。

HITL 设计的 Checklist

4.4　权限模型设计

Agent 产品的权限模型比传统软件复杂，因为 Agent 不仅是"用户"的角色，它还可能同时扮演"操作者"、"调用者"、"决策者"等多重角色。

三种权限模型

RBAC（Role-Based Access Control，基于角色的访问控制）

最简单也最常见。为 Agent 分配角色，每个角色有预定义的权限集合。

适用场景：Agent 的职责固定且明确。比如客服 Agent 只能查询订单和发送消息，不能修改订单。

ABAC（Attribute-Based Access Control，基于属性的访问控制）

更灵活，根据 Agent 的状态、用户身份、数据敏感度等属性动态决定权限。

适用场景：Agent 的职责动态变化。比如同一个 Agent，在工作时间可以执行自动预约，在非工作时间只能查询。

IBAC（Intent-Based Access Control，基于意图的访问控制）

最前沿，不只看 Agent 要做什么操作，还看它为什么做这个操作。

适用场景：高风险领域。比如 Agent 要查询用户银行卡余额——RBAC 和 ABAC 只看"是否有权限查询"，IBAC 还看"查询的意图是什么"。如果是为了分析消费趋势，允许；如果是为了转账准备，需要额外确认。

权限设计实践建议

建议一：短期凭证优于长期凭证

不要给 Agent 长期有效的 API Key。使用短期 Token（如 OAuth 2.0 的 access_token，通常 1 小时过期），每次需要时重新获取。这样即使 Token 泄露，攻击窗口也很短。

建议二：分级授权

不要一次性授权所有能力。用户应该能逐个授权——"我允许 Agent 查询我的课表"和"我允许 Agent 预约课程"应该是两个独立的授权。

建议三：可撤销

用户应该能随时撤销 Agent 的任何权限。撤销后，Agent 立即失去对应能力，不需要等待 Token 过期。

建议四：操作留痕

每一次工具调用、每一次权限使用，都应该记录在审计日志中。日志应包含：谁（哪个 Agent/用户）、什么时候、调用了什么工具、传了什么参数、返回了什么结果。

4.5　合规框架与监管趋势

Agent 产品不仅面临技术安全挑战，还面临日益严格的合规要求。产品经理不需要成为法律专家，但需要了解基本的合规框架。

主要合规框架

NIST AI Risk Management Framework（美国国家标准与技术研究院 AI 风险管理框架）

美国主导的 AI 风险管理框架，覆盖 AI 系统的全生命周期。核心原则：可测量、可评估、可追溯。

ISO/IEC 42001（AI 管理体系标准）

国际标准化组织发布的 AI 管理体系标准，类似于 ISO 9001 但针对 AI。企业可以获得 ISO/IEC 42001 认证，证明其 AI 管理体系符合国际标准。

EU AI Act（欧盟人工智能法案）

全球第一部全面的 AI 监管法律。将 AI 系统分为四个风险等级：不可接受风险（禁止）、高风险（严格监管）、有限风险（透明度要求）、最小风险（无特殊要求）。

大部分 Agent 产品属于"高风险"或"有限风险"类别。如果你的 Agent 涉及招聘、信用评估、执法等领域，属于"高风险"，需要满足严格的合规要求。

中国《生成式人工智能服务管理暂行办法》

中国对生成式 AI 的监管办法，要求服务提供者承担内容管理责任、保护用户隐私、进行安全评估。

合规设计 Checklist

监管趋势预判

Gartner 预测，到 2027 年底，超过 40% 的 Agent AI 项目将被取消——原因不是技术不行，而是成本失控、ROI 不清晰和风险管控不足。这个预测说明：合规不是产品的负担，而是产品的护城河。

当监管趋严时，提前做好合规的团队会获得巨大的先发优势。而那些"先上线再说"的团队，将在监管来临时面临被迫下线的风险。

4.6　安全事件响应：当 Agent 出错时

不管你的防护有多强，Agent 总有出错的时候。关键不在于"不出错"，而在于"出错后怎么办"。

事件分级

响应流程

P0/P1 紧急响应：

1. 一键停止：立即暂停所有 Agent 活动
2. 影响评估：确定受影响的用户和数据范围
3. 损害控制：撤销未完成的操作，通知受影响用户
4. 根因分析：定位是哪一层防护被突破
5. 修复与加固：修复漏洞，加强对应防护层
6. 事后复盘：记录事件全过程，更新安全策略

预防性措施

• 红队测试：定期模拟攻击，测试防护体系有效性
• 混沌工程：故意注入故障，测试系统容错能力
• 渐进发布：新功能先灰度 1% 用户，观察异常率
• 异常监控：实时监控 Agent 行为指标，偏离基线时告警

4.7　本章小结与行动建议

核心观点回顾

1. Agent 安全比传统软件更难，因为 Agent 不只处理数据，它执行操作。LLM 出错是错误答案，Agent 出错是未经授权的交易。
2. 四层防护体系：输入防护、行为防护、输出防护、执行防护。多层防御，不依赖单一手段。
3. HITL 是核心：三个级别——通知后执行、确认后执行、人工执行。按操作风险等级选择。
4. 权限模型：RBAC 简单、ABAC 灵活、IBAC 前沿。使用短期凭证、分级授权、可撤销、操作留痕。
5. 合规是护城河：NIST AI RMF、ISO/IEC 42001、EU AI Act、中国 AIGC 管理办法。提前合规的团队将在监管趋严时获得先发优势。
6. 安全事件响应：分级响应、一键停止、根因分析、事后复盘。预防胜于治疗。

行动建议

1. 定义你的 HITL 边界表：列出你的 Agent 所有的操作，按可逆性和风险等级分级，标注每个操作的 HITL 级别。这个表格应该成为团队共识。
2. 实现四层防护中的至少两层：MVP 阶段至少实现输入防护和行为防护。输出防护和执行防护可以在生产化阶段补齐。
3. 建立安全审计日志：从 Day 1 开始记录所有 Agent 操作。不要等出事了才想加日志——那时候已经没有数据可查了。
4. 做一次红队测试：模拟攻击者视角，尝试让你的 Agent 做不该做的事。你会惊讶于发现了多少漏洞。
5. 检查合规要求：确定你的产品需要满足哪些合规框架，列出待办清单。

延伸思考

安全和体验是一对永恒的矛盾。每加一道防护，用户体验就降一分。怎么平衡？

我的经验是：用风险等级来决定平衡点，而不是一刀切。 低风险操作零摩擦（通知后执行），中风险操作轻摩擦（一键确认），高风险操作重摩擦（人工执行）。用户可以接受为了安全而多按一个按钮，但不能接受每次操作都要确认三个弹窗。

好的安全设计是隐形的——用户感觉不到它的存在，但它在默默守护。就像 LifeOS 的支付边界：用户只看到"请点击链接完成支付"，看不到背后"Agent 无法自动扣款"的硬约束。但这个约束，是整个产品信任关系的基石。

第五章　从 MVP 到规模化运营

5.1　Agent 产品的 MVP 定义

传统 SaaS 产品的 MVP 逻辑是：做最小功能集，验证用户愿不愿意用。Agent 产品的 MVP 逻辑不同：做最窄场景的完整闭环，验证用户愿不愿意把事情交给 AI。

区别在于"用"和"交"。

用户用你的产品，意味着他们是操作者；用户把事情交给你的产品，意味着他们放弃了对过程的控制权。这是两种完全不同的信任级别。传统 SaaS 只需要用户觉得"好用"，Agent 产品需要用户觉得"放心"。

因此，Agent 产品的 MVP 不是功能的最小子集，而是信任的最小闭环。

MVP 的三个定义标准

标准一：单场景全链路跑通

从用户触发到最终完成，每一个环节都要真实运行。不能用 mock 数据演示，不能用人工兜底——如果你的 MVP 在演示时需要人手动操作某一步，那它不是一个真正的 MVP。

LifeOS 的 MVP 只做两件事——预约 LeFit 课程和下单麦当劳恢复餐。但这两件事，从意图理解到执行完成到用户确认，全链路真实跑通。包括真实的 API 调用、真实的订单创建、真实的支付链接生成。

标准二：失败可感知、可恢复

MVP 不需要 100% 成功率，但失败时用户必须知道发生了什么，且能采取行动。如果 Agent 预约失败了，用户应该看到"预约失败，原因是课程已满，已为您推荐替代课程"，而不是一个 500 错误页面。

标准三：可测量

MVP 必须有埋点，能回答以下问题：

• 用户触发了多少次任务？
• 任务成功率是多少？
• 用户需要干预的比例是多少？
• 从触发到完成的平均耗时是多少？

如果这些问题回答不了，你的 MVP 还没有准备好上线。

MVP 范围控制

Agent 产品最容易犯的错误是 MVP 范围过大。因为 Agent 的想象空间太大了——你总觉得"如果它还能做 X 就好了"。但每多一个场景，开发和测试成本就翻倍。

控制范围的方法：用"场景×能力"矩阵来定义 MVP 边界。

这个矩阵让你一眼看清 MVP 做什么、不做什么。任何不在"✅ MVP"格子里的功能，不管看起来多有价值，MVP 阶段都不做。

5.2　Agent 产品的核心指标体系

传统产品的指标体系（AARRR、HEART 等）在 Agent 产品中需要调整。因为 Agent 产品的用户行为模式与传统产品不同——用户不是"使用"产品，而是"委托"产品。

三层指标体系

第一层：业务指标（用户价值验证）

第二层：技术指标（系统健康度）

第三层：Agent 行为指标（AI 质量度）

指标优先级

MVP 阶段不需要追踪所有指标。按以下优先级分阶段实施：

P0（MVP 上线即需要）：任务完成率、用户干预率、工具调用成功率、错误率

P1（上线 1 个月后）：用户留存率、任务完成时长、Token 消耗、平均对话轮次

P2（准备规模化时）：NPS、再生率、意图理解准确率、规划合理率

指标埋点清单

事件：task_triggered
属性：task_type, trigger_source(user/system), user_id, timestamp

事件：task_planned
属性：task_id, plan_steps, planning_time, timestamp

事件：tool_called
属性：tool_name, provider, input_params, success, latency, error_message

事件：task_completed
属性：task_id, duration, success, user_intervention, timestamp

事件：user_feedback
属性：task_id, feedback_type(accept/reject/modify), timestamp

5.3　从 MVP 到 PMF 的路径

PMF（Product-Market Fit，产品市场契合）是每个产品从 0 到 1 的关键里程碑。Agent 产品的 PMF 判断标准与传统产品不同。

Agent PMF 的三个信号

信号一：用户开始"委托"而非"使用"

传统产品的 PMF 信号是用户频繁使用。Agent 产品的 PMF 信号是用户开始减少主动操作——他们不再每天打开 App 检查课程表，而是等 Agent 通知他们"已经约好了"。

可量化指标：触发来源中，系统自动触发的占比逐渐上升，用户手动触发的占比逐渐下降。

信号二：用户开始扩展使用场景

用户从 MVP 的核心场景出发，主动问"你还能帮我做 X 吗？"这是极强的 PMF 信号——用户已经信任了 Agent 在一个场景的能力，想要扩展到更多场景。

可量化指标：用户主动提出的场景扩展请求数量。

信号三：用户离开后感到"不便"

最好的 PMF 验证方法：让一批用户一周不用你的产品。如果他们回来时说"没有它我上周过得很痛苦"，PMF 达到了。如果他们说"还行，我手动约了课"，PMF 还没到。

可量化指标：暂停使用后的回归率 + 用户反馈中的"不便"提及率。

PMF 验证实验

实验一：去除实验

选择一批活跃用户，暂时关闭 Agent 的自动执行功能（改为只推荐不执行）。观察他们的行为变化——如果他们大量流失或投诉，说明他们已经依赖 Agent 的执行能力，PMF 达到了。

实验二：付费实验

向早期用户收费。不是问卷问"你愿意付费吗"——那不靠谱。直接收费，看留存。愿意付费且留存的用户比例，是 PMF 最真实的度量。

实验三：推荐实验

看用户是否主动向他人推荐你的产品。Agent 产品的推荐往往伴随着场景描述——"我用它自动约课，特别方便"。如果用户只是说"这个产品不错"但说不清用它做什么，PMF 还没到。

5.4　规模化阶段的核心挑战

PMF 验证后，产品进入规模化阶段。这个阶段的挑战与 MVP 阶段完全不同。

挑战一：成本控制

Agent 产品的成本结构与传统 SaaS 截然不同。传统 SaaS 的边际成本主要是服务器和带宽，相对可控。Agent 产品的边际成本包括：

• LLM 调用成本：每次任务至少一次 LLM 调用，复杂任务可能十几次
• 工具调用成本：外部 API 的调用费用
• 存储成本：上下文和执行日志的存储

成本优化策略：

1. 缓存结果：相同意图的重复请求，直接返回缓存结果
2. 模型分级：简单任务用小模型，复杂任务才用大模型
3. 批处理：多个用户请求合并处理，减少 LLM 调用次数
4. 预计算：低峰期预先计算可能需要的推荐，高峰期直接返回

Gumroad CEO 分享的数据很有参考意义：Devin 一个任务跑下来随随便便就是 5-10 美元。如果你的产品定价不能覆盖这个成本，规模化越多亏越多。

挑战二：质量保障

MVP 阶段你可以手工检查每个用户的任务执行情况。规模化后，每天成千上万次任务，手工检查不可能了。

质量保障策略：

1. 自动评分：用另一个 LLM 对 Agent 的输出打分，低于阈值的标记人工审查
2. 用户反馈闭环：用户的 Accept/Reject/Modify 行为作为质量信号
3. A/B 测试：新版本 Agent 与旧版本并行运行，对比关键指标
4. 回归测试：每次模型更新后，用历史案例跑回归测试

挑战三：多场景扩展

MVP 验证了一个场景，但扩展到第二个、第三个场景时，往往会遇到意想不到的问题。

扩展策略：

1. 场景相似性评估：新场景与已验证场景的相似度有多高？相似度高的场景扩展风险低
2. 能力复用率：新场景能复用多少已有 Skill？复用率高于 60% 的场景优先扩展
3. 渐进式开放：新场景先灰度 10% 用户，观察 2 周后再全量
4. 场景隔离：不同场景之间的问题不相互影响——一个场景的 Agent 出错，不能影响其他场景

挑战四：用户教育

Agent 产品需要用户改变行为习惯——从"自己做"变成"让 AI 做"。这个转变不是自然发生的，需要产品设计引导。

用户教育策略：

1. 首次引导：新用户首次使用时，用一个低风险任务演示 Agent 能力
2. 渐进赋权：初始只开放低风险操作，用户使用一段时间后自动解锁高风险操作
3. 透明度递减：初期展示完整执行过程，用户信任建立后逐渐简化展示
4. 失败兜底：Agent 失败时提供手动操作入口，让用户有退路

5.5　运营体系搭建

规模化阶段需要建立系统化的运营体系。以下是一个 Agent 产品运营体系的框架：

用户运营

分层运营：

数据运营

日报/周报/月报体系：

日报（自动化）：

• 任务总量、成功率、错误率
• 活跃用户数、新增用户数
• 异常告警

周报（半自动化）：

• 上述指标的趋势变化
• 用户反馈热点
• Top 10 失败任务

月报（人工分析）：

• PMF 信号追踪
• 成本分析
• 场景扩展优先级评估
• 下月计划

内容运营

Agent 产品的内容运营不是写公众号文章，而是帮助用户理解 Agent 能做什么、不能做什么。

• 能力清单：清晰列出 Agent 的能力边界，定期更新
• 最佳实践：分享高效使用 Agent 的技巧
• 案例故事：真实用户如何用 Agent 解决问题的故事
• 变更日志：每次 Agent 能力更新都通知用户

5.6　商业模型设计

Agent 产品的商业化比传统 SaaS 更复杂，因为成本结构与价值交付方式不同。

四种主流商业模型

模型一：订阅制（Subscription）

用户按月/年付费，获得 Agent 服务。最常见也最稳定。

适合：高频使用场景，用户每月使用次数可预测。

定价参考：ChatGPT Plus $20/月，Cursor $20/月。Agent 产品的订阅价需要覆盖 LLM 调用成本，通常不低于 $15/月。

模型二：按量计费（Usage-based）

用户按任务次数或 Token 消耗付费。

适合：使用频率不稳定的场景，或 B2B 场景。

定价参考：按任务计费，每次 $0.5-$5 不等。关键是要让用户能预估月度支出。

模型三：免费+增值（Freemium）

基础功能免费，高级功能或更多用量收费。

适合：需要快速获取用户的 C 端产品。

关键设计：免费额度要让用户能体验核心价值，但不够满足全部需求。ChatGPT 免费版每天有限次数的 GPT-5 调用，就是这个逻辑。

模型四：企业定制（Enterprise）

为大客户提供定制化 Agent 解决方案。

适合：B2B 场景，客户需求差异大。

定价参考：通常按年签约，$10K-$100K+/年，包含定制开发、SLA 保障、专属支持。

商业模型选择矩阵

成本结构分析

Agent 产品的单位经济模型（Unit Economics）：

收入 = 订阅费 / 按量费
成本 = LLM 调用 + 工具调用 + 存储 + 基础设施 + 获客成本
利润 = 收入 - 成本

关键指标：

• 毛利率：Agent 产品的毛利率通常低于传统 SaaS（LLM 成本高），目标 ≥ 60%
• LTV/CAC：生命周期价值 / 获客成本，目标 ≥ 3
• 回收期：获客成本回收时间，目标 ≤ 12 个月

如果毛利率低于 40%，说明你的成本结构有问题——要么定价太低，要么 LLM 调用太频繁，要么任务太复杂导致每次任务消耗过多 Token。

5.7　规模化检查清单

在从 MVP 向规模化过渡时，用以下清单检查准备度：

5.8　本章小结与行动建议

核心观点回顾

1. Agent MVP = 信任的最小闭环，不是功能的最小子集。三个标准：全链路跑通、失败可感知可恢复、可测量。
2. 三层指标体系：业务指标（用户价值）、技术指标（系统健康）、Agent 行为指标（AI 质量）。P0 指标上线即需要。
3. PMF 三个信号：用户从"使用"变为"委托"、用户主动扩展场景、用户离开后感到不便。用去除实验、付费实验、推荐实验验证。
4. 规模化四大挑战：成本控制（LLM 成本是主要变量）、质量保障（自动评分+回归测试）、多场景扩展（相似性评估+能力复用）、用户教育（渐进赋权+透明度递减）。
5. 四种商业模型：订阅制、按量计费、免费增值、企业定制。关键看用户类型和使用频率。
6. 单位经济模型：毛利率 ≥ 60%、LTV/CAC ≥ 3、回收期 ≤ 12 个月。达不到就调整定价或优化成本。

行动建议

1. 画出你的场景×能力矩阵：明确 MVP 做什么、不做什么。坚持只做 ✅ 格子里的功能。
2. 定义 P0 指标和埋点方案：在写代码之前定义好要追踪什么。不要等上线了才发现没有埋点。
3. 做一次 PMF 验证实验：选择去除实验或付费实验，用数据而非直觉判断 PMF 是否达到。
4. 建立成本模型：计算每次任务的平均 LLM 成本、工具调用成本，倒推定价。如果算不过来账，趁早调整方案。
5. 完成规模化检查清单：10 项中 P0 全部通过才能开始规模化。P1 项不通过可以边推进边补齐。

延伸思考

Agent 产品的终局是什么？

我认为 Agent 产品的终局不是"一个什么都能做的超级 Agent"，而是"一组各司其职的专业 Agent，通过协议协同"。就像人类社会不是一个人什么都干，而是有厨师、司机、医生、教师——每个人专业做一件事，通过社会协议协作。

Agent 产品也会走向这个方向：健身 Agent、饮食 Agent、日程 Agent、财务 Agent，各自在自己的领域做到极致，通过 MCP 等协议互联互通。产品经理的角色，就是定义每个 Agent 的专业边界、设计它们之间的协作协议、确保用户体验的无缝衔接。

这不是未来——LifeOS 已经在做这件事了。Planner Agent 负责决策，Booking Provider 负责预约，Meal Provider 负责下单，Notification Provider 负责通知。每个组件各司其职，通过统一接口协作。

从 MVP 到规模化，最终到平台化，Agent 产品的演进路径清晰而漫长。但核心始终不变：不是让 AI 更聪明，而是让用户更省心。

结语

写完这五章，回到本书的出发点：AI Agent 产品设计的核心不是让 AI 更聪明，而是让 AI 在正确的边界内可靠地执行。

这不是一本技术手册——市面上不缺 LangChain 教程和 Prompt 工程指南。这本书想传递的是产品思维：在 AI 能力飞速进化的时代，产品经理的价值不在于追技术潮流，而在于定义场景、设计边界、建立信任。

从第一章的本质定义，到第二章的意图理解，到第三章的 Skill 生态，到第四章的安全边界，到第五章的规模化运营——这五章构成了一套从 0 到 1 再到 N 的完整方法论。

但方法论终究是方法论。真正做好 Agent 产品，需要你下场实践，在真实用户、真实场景、真实失败中迭代认知。

不要构建一个告诉用户该做什么的应用。构建一个把事情搞定的 Agent。

这句话来自 LifeOS 的 PROJECT_BIBLE.md，也是我对所有 Agent 产品设计者的最终建议。

Go build.