从“回答问题”到“完成任务”
AI Agent 产品的交互、工作流与控制权设计
From Answers to Outcomes: Interaction, Workflow and Control Design for AI Agent Products
当 AI 从“生成答案”走向“持续执行任务”，产品设计的核心也从回答质量扩展到目标理解、任务规划、工具调用、权限控制、过程可见、失败恢复与结果验证。本文结合 2026 年 7—8 月 Agent 产品变化、Codex 实际使用观察与 Personal Work Agent MVP，讨论什么任务值得 Agent 化，以及如何在自主性与用户控制之间建立可用的产品机制。
展开本文目录
00｜执行摘要
大模型产品正在经历一个关键变化：用户不再只希望 AI “告诉我怎么做”，而是越来越期待 AI “替我把事情做完”。这意味着产品形态从以生成内容为中心的 Chatbot，逐步扩展到能够理解目标、拆解任务、调用工具、读取环境反馈，并根据结果持续调整下一步的 Agent。能力边界的扩大，也同步放大了错误、权限、信任和责任问题。
因此，Agent 产品的核心并不是让模型拥有更多工具，而是让模型在恰当的任务、恰当的权限和恰当的检查点上采取行动。对产品经理而言，真正需要设计的是一套“自主性与控制权的分配机制”：哪些步骤可以自动完成，哪些步骤必须用户确认；出现失败时如何恢复；用户如何理解当前进度；以及最终如何验证任务是否真正完成。
五个核心结论
- **Agent 的终点正在从 Answer 转向 Outcome。**关键不是工具数量，而是系统能否围绕目标持续行动，并根据环境反馈动态调整，直到满足完成条件或主动把决策权交还给用户。
- **不是所有任务都值得 Agent 化。**路径稳定、规则明确、结果可预期的任务通常更适合 Workflow；只有当多步骤、路径不确定、工具依赖、中间判断和自动化收益同时存在时，Agent 才更有价值。
- **Agent 产品的核心矛盾是 Autonomy × Control。**自主性越强，潜在效率越高，但错误影响范围也越大。权限、确认、状态可见、恢复和验证必须与执行能力同步增长。
- **Human-in-the-loop 应发生在关键节点，而不是每一步。**高风险、不可逆、对外沟通、意图不清、异常成本或证据不足时暂停，其余低风险步骤在授权范围内自动执行。
- **Agent Evaluation 应从 Tool Success 转向 Verified Task Completion。**工具返回成功不等于用户目标完成，评测必须同时覆盖结果、过程与权限边界。
一张表理解 Agent 产品闭环
| 阶段 | 产品要回答的问题 | 主要机制 |
|---|---|---|
| Goal / Intent | 用户真正想完成什么？ | 意图识别、参数补全、约束识别、必要澄清 |
| Plan | 应该怎么做？路径是否需要动态调整？ | 任务拆解、计划预览、协作式规划 |
| Permission | AI 被允许做到什么程度？ | 最小权限、即时授权、风险分级 |
| Action / Tool | 如何读取或影响外部世界？ | 工具调用、环境反馈、状态更新 |
| Observe / Evaluate | 中间结果是否正确？ | 结果读取、证据检查、进度追踪 |
| Re-plan / Recovery | 失败后下一步是什么？ | 重试、换路径、回滚、升级给用户 |
| Checkpoint | 何时必须让用户回来？ | 人工确认、审批、暂停与继续 |
| Verification | 用户目标真的完成了吗？ | 结果核验、交付物检查、完成条件 |
为什么是现在：2026.07—08 Agent 产品演进
- 2026.07.09｜ChatGPT Work
Goal → Finished Work、Long-running Task、Progress 与 Approval 开始成为同一产品流程的一部分。AI 产品从单轮回答进一步进入跨应用、多步骤、长时间完成工作的形态。
- 2026.07.28｜MCP 2026-07-28
Stateless Core、Multi Round-Trip Requests、Tasks 与 Authorization 进入新规范，基础设施开始显式处理长任务、Tool 交互和执行中重新请求用户输入的问题。
- 2026.07.31｜Gemini Enterprise Agent Evaluation GA
评测覆盖 Tool Use、Trajectory、Grounding、Safety 与 Online Evaluation，Agent 评测开始从最终回答扩展到完整执行过程。
- 2026.08.12｜From Assistance to Execution
OpenAI 企业使用研究呈现从 Assistance 向 Execution 转移的信号。该数据反映 OpenAI 企业客户使用情况，不代表整个 AI 市场。
这些变化共同指向同一个产品趋势：AI 的基本单位正从 Question / Prompt 向 Goal / Finished Work 移动。产品经理需要设计的不再只是“如何得到更好的回答”，而是“如何让一个长任务在现实约束中安全、可见、可恢复地完成”。
01｜从“回答”到“行动”：Agent 的产品定义
Chatbot 解决信息问题，Agent 试图解决任务问题
传统 Chatbot 的典型交互链路是“用户输入—模型理解—生成回答—用户继续操作”。即使回答质量很高，AI 的主要输出仍停留在信息层：它可以写邮件、给建议、生成计划，但真正发送邮件、创建日程、修改文件、提交申请，通常仍由用户完成。
Agent 的变化在于，模型不再只产出文本，而是被置于“目标—行动—观察—调整”的循环中。用户给出目标后，系统需要先理解目标和约束，再决定步骤与工具；每次行动后读取环境反馈，根据结果继续、重试、改道，直至满足完成条件或遇到必须由人判断的节点。
| Chatbot | Agent |
|---|---|
| “帮我写一封催进度的邮件。” | “根据最近沟通记录起草邮件，确认收件人与附件后交给我审核。” |
| “告诉我明天有哪些会议。” | “检查明天会议冲突，提出方案；获得确认后更新日历。” |
| “给我一个竞品研究框架。” | “搜索资料、读取证据、比较差异并形成可交付研究稿。” |
从产品视角定义 AI Agent
AI Agent 是一种围绕用户目标，在明确权限与约束范围内，能够持续进行任务理解、规划、工具调用、环境观察与策略调整，直至满足任务完成条件或主动将决策权交还给用户的 AI 产品形态。
这个定义强调 Goal-driven + Closed-loop Action + Dynamic Decision。改变外部状态是 Agent 的重要能力之一，但不是判断 Agent 的唯一标准。
例如 Research Agent 即使没有修改邮箱、数据库或日历，也可以形成 Agentic Loop：
从实现上看，Agent 往往由大模型、工具、上下文或记忆、运行时、Guardrails 与评测系统共同构成。OpenAI Agents SDK 将工具、handoff、guardrails、sessions 与 tracing 等作为运行时能力；Anthropic 则区分预定义代码路径的 workflow 与由模型动态决定过程和工具使用的 agent。共同点是：Agent 的价值来自对任务路径的动态决策，而不是“多调用几个 API”。
Agent 的最小能力模型
| 能力 | 产品含义 | 缺失后的典型问题 |
|---|---|---|
| Goal | 理解用户真正要完成的结果 | 把模糊要求误当作具体指令 |
| Planning | 把目标转化为可执行步骤 | 只能做单步工具调用 |
| Tool / Action | 读取或影响外部环境 | 仍停留在“告诉用户怎么做” |
| State / Context | 知道任务进度与已有证据 | 重复执行、遗忘约束、长任务失控 |
| Observation | 读取工具与环境的真实反馈 | 工具调用成功就误以为任务成功 |
| Evaluation | 判断结果是否满足目标 | 无法识别“做了但没做对” |
| Recovery | 失败后重试、改道或请求人工介入 | 任何异常都退化为 “Something went wrong” |
Agent 产品的核心矛盾：Autonomy × Control
Agent 的效率来自“少打断用户”，风险则来自“替用户做错事”。如果所有步骤都需要确认，Agent 会退化成不断弹窗的 Workflow；如果几乎不做确认，错误范围又可能从一条错误回答扩展为错误发送、错误修改、错误删除甚至资金损失。
因此自主性不是越高越好，而应与任务风险、可逆性、证据充分度、用户授权范围和组织政策共同决定。产品目标不是追求最高自治等级，而是在可接受风险下尽可能减少用户操作成本。
02｜Chatbot、Workflow 与 Agent：先判断是否真的需要 Agent
三种形态的边界
| 维度 | Chatbot | AI Workflow | AI Agent |
|---|---|---|---|
| 主要目标 | 回答、生成、解释 | 稳定自动化固定流程 | 完成路径不固定的复杂目标 |
| 路径 | 单轮或短对话 | 代码预先定义 | 由模型根据环境反馈动态决定 |
| 工具 | 可有可无 | 节点绑定工具 | 按需要选择与组合工具 |
| 状态 | 对话上下文为主 | 流程节点状态 | 任务状态 + 环境状态 + 用户约束 |
| 可控性 | 高 | 较高 | 相对较低，需要额外治理 |
| 成本 / 延迟 | 低到中 | 中 | 通常更高 |
| 典型任务 | 翻译、总结、写作 | 审核、分类、结构化报表 | 研究、编程、跨应用办公、动态问题解决 |
最重要的产品判断：优先使用最简单的可行方案
“Agent 化”本身不是产品价值。更复杂的架构会增加延迟、成本、错误传播路径和测试难度。只有固定流程无法覆盖现实路径、且动态决策能显著提高任务价值时，才应增加 Agent 自主性。
01 一个 Prompt 能解决？能则保持 Chatbot。
02 固定 Workflow 能解决？能则保持可预测流程。
03 动态决策能显著提高任务价值？只有答案为 Yes 时才考虑 Agent。
Agent Suitability Matrix：什么任务值得 Agent 化
**框架属性：本文分析框架（Author’s Framework），不是 OpenAI、Anthropic 或其他公司的官方模型。**每个维度按 0（低）、1（中）、2（高）计分。总分不是绝对门槛，而是把“想做 Agent”转化为可以讨论的产品判断。
| 维度 | 0 分 | 1 分 | 2 分 |
|---|---|---|---|
| 多步骤程度 | 单步即可完成 | 2–3 个连续步骤 | 长链路、多阶段任务 |
| 路径不确定性 | 路径固定 | 少量分支 | 必须根据中间结果动态改道 |
| 工具依赖 | 无需外部工具 | 单一工具 | 跨多个系统与工具 |
| 中间判断需求 | 几乎无判断 | 局部判断 | 每一步结果都会影响后续决策 |
| 持续状态需求 | 无需记忆 | 短期上下文 | 跨多轮、长时间保持任务状态 |
| 行动价值 | 只需信息 | 生成可执行草稿 | 产生可执行结果或影响外部环境 |
| 自动化收益 | 人工成本很低 | 有一定节省 | 人工重复、耗时且结果导向明显 |
“把一句中文翻译成英文”使用 Chatbot 即可；“上传简历—解析 JD—匹配—评分—输出建议”路径稳定，更适合 Workflow；“持续搜索岗位、根据每个 JD 判断匹配并追踪申请状态”存在动态搜索、工具组合和状态维护，更接近 Agent。
不适合 Agent 的典型情况
- 高确定性、固定流程且对稳定性要求远高于灵活性的任务。
- 每一步都属于高风险或不可逆动作，且不存在有效回滚与审核机制的任务。
- 单次任务价值很低，但模型、搜索与工具成本很高的任务。
- 缺乏可验证环境反馈，系统只能“自我感觉完成”的任务。
- 数据权限、合规和身份边界尚未明确，却要求 Agent 跨系统行动的任务。
03｜从模糊意图到可执行目标
Intent → Goal → Inputs → Constraints → Output → Completion Criteria
真实用户往往不会用结构化方式描述任务。“帮我准备一下明天的会议”“把这个报告弄好”“帮我看看有哪些适合的岗位”都包含大量未显式说明的信息。Agent 如果把自然语言直接映射成动作，很容易把缺失信息当作默认值，导致后续整条任务链建立在错误假设上。
| 层级 | 需要回答的问题 | 示例：准备产品评审会 |
|---|---|---|
| Intent | 用户大致想做什么？ | 准备明天下午的产品评审 |
| Goal | 什么结果才算完成？ | 会议前获得一份可直接使用的 Brief 与待讨论清单 |
| Inputs | 需要哪些信息？ | 历史会议、项目文档、当前指标、最近沟通记录 |
| Constraints | 哪些边界不能越过？ | 不能自动发送对外邮件；仅使用指定项目资料 |
| Output | 最终交付物是什么？ | 1 页 Brief + 风险清单 + 议程草稿 |
| Completion Criteria | 如何判断真的完成？ | 核心材料齐全、引用可追溯、未决事项已列出 |
Progressive Clarification：什么时候追问，什么时候直接执行
追问不是越多越安全。过度澄清会把 Agent 变成“问卷生成器”；澄清不足则容易出现高成本误操作。产品需要比较 Clarification Cost 与 Wrong Action Cost。
| 情况 | 推荐策略 | 示例 |
|---|---|---|
| 低风险 + 可逆 + 默认值明确 | 直接执行，必要时提供撤销 | 把文件按主题建立分类草稿 |
| 低风险 + 信息可从上下文推断 | 先推断并说明假设 | 根据历史格式生成周报草稿 |
| 关键参数缺失 | 只追问阻塞任务的最小信息 | “发给谁？”“截止时间？” |
| 高风险或不可逆 | 执行前必须确认 | 删除、付款、提交、对外发布 |
| 多个合理策略且偏好影响明显 | 给 2–3 个方案让用户选择 | 旅行预算与路线取舍 |
产品原则是：**能推断的尽量推断；低风险使用可撤销默认；真正阻塞任务的才追问；高风险动作在执行前确认。**目标是用最少打断换取足够确定性。
把隐含假设显性化
对复杂 Agent，一个有价值的交互不是展示完整内部推理，而是展示会影响执行结果的关键假设。例如：“我将默认使用最近 30 天数据”“我会把价格优先级放在距离之后”“我只会生成邮件草稿，不会发送”。用户不需要看到模型内部 Chain-of-Thought，但需要知道影响结果的前提。
04｜规划与执行：用户需要看到多少过程
Planning 的目标不是把步骤写得越细越好
复杂任务需要计划，但“计划”不是为了向用户证明 AI 很聪明，而是为了让系统拥有可检查的执行结构。有效计划至少应包含阶段目标、输入、工具、完成条件和潜在阻塞点。过细的计划会造成视觉噪声，也会让模型在现实变化后频繁违背预先写下的步骤。
更合理的是分层计划：对用户展示 3–6 个稳定的高层阶段，对系统内部保留更细的执行动作；当环境反馈改变时，可以局部重规划，而不需要整份计划从头生成。
| 模式 | 适用场景 | 优点 | 风险 |
|---|---|---|---|
| Black Box | 低风险、短任务 | 快、打断少 | 用户对长时间等待缺乏理解 |
| Plan Preview | 复杂但目标清晰的任务 | 用户可提前发现方向错误 | 每次都预览会增加操作负担 |
| Collaborative Planning | 专业、高价值、多约束任务 | 可把专家知识注入计划 | 交互成本高，适合少数任务 |
动态计划：Plan → Act → Observe → Evaluate → Re-plan
Agent 的关键不是“一次规划正确”，而是根据真实环境反馈持续修正。搜索没有找到可靠来源时需要改关键词；接口失败时需要切换工具；文件格式不可读时需要请求替代材料；发现目标冲突时需要停下让用户选择。
这个循环要求工具返回足够结构化，使 Agent 能判断成功、失败和异常；任务还必须定义停止条件，防止系统在开放环境中无限尝试。常见停止条件包括达到完成标准、连续失败次数上限、成本或时间预算上限、需要人工判断或触发风险策略。
**Plan Preview，而不是 Chain-of-Thought Preview。**用户需要看到 Goal、高层 Plan、Current Step、Activity、Artifacts、Approval 与 Verification，而不是模型内部完整推理。
Agent UI 不应只有一个聊天框
当任务从“回答问题”变成“持续执行”，聊天流很难承载全部状态。用户需要区分“我说了什么”“AI 计划做什么”“当前正在做什么”“产生了哪些文件或结果”“哪些动作等待批准”。Agent 交互因此更接近工作空间，而不是纯对话产品。
| 界面区域 | 承担的信息 |
|---|---|
| Conversation | 目标补充、澄清、自然语言沟通 |
| Task / Goal | 当前任务、完成标准、约束 |
| Plan | 高层步骤与可调整顺序 |
| Activity Timeline | 工具调用、关键状态变化、失败与重试 |
| Artifacts | 报告、表格、代码、草稿等中间或最终产物 |
| Approval Center | 待确认的高风险动作 |
| History | 过去任务、权限记录、撤销与恢复入口 |
05｜从 Automation 到 Autonomy：控制权如何分配
自主性等级：不是所有动作都应该同一档
| 等级 | AI 的权限 | 典型交互 | 适合任务 |
|---|---|---|---|
| L0 Information | 只提供事实与解释 | “这是你需要知道的信息” | 查询、解释 |
| L1 Suggestion | 给出行动建议 | “建议你这样做” | 策略、决策辅助 |
| L2 Draft | 生成可执行草稿 | “我已经准备好，等待你编辑” | 邮件、文档、计划 |
| L3 Confirm Action | 用户审批后调用工具 | “确认后我会发送或提交” | 对外沟通、重要修改 |
| L4 Bounded | 授权范围内自动操作，可撤销 | “已完成，可撤销” | 低风险整理、同步、分类 |
| L5 High Autonomy | 用户给目标，系统持续执行 | “完成后汇报，仅异常时打断” | 可信环境内的长期任务 |
优秀 Agent 不应默认追求最高自治等级，而应采用 Progressive Autonomy。系统根据任务风险、可逆性、证据充分度、权限范围、历史成功记录和组织政策逐步增加自治度；同一个 Agent 在“读取文件”和“发送邮件”两个动作上也应使用不同等级。
Risk × Reversibility × Evidence Sufficiency
确认策略由三个主要变量共同决定：Risk 代表错误会造成多大损失；Reversibility 代表是否能够低成本恢复；Evidence Sufficiency 代表当前理解与执行是否有足够证据支持。
Evidence Sufficiency 不等于让模型直接自报“我有 95% confidence”。它应由关键参数完整性、多源证据一致性、Tool 返回状态、规则校验、Evaluator 结果与目标歧义程度共同形成。
| 动作 | 风险 | 可逆性 | 推荐策略 |
|---|---|---|---|
| 搜索公开资料 | 低 | 高 | 自动执行 |
| 创建文档草稿 | 低 | 高 | 自动执行 |
| 修改内部文档 | 中 | 高 | 自动执行 + 清晰撤销 |
| 调整日历 | 中 | 中高 | 授权范围内执行，变更摘要可见 |
| 发送外部邮件 | 高 | 低 | 发送前确认收件人、内容与附件 |
| 提交申请或发布 | 高 | 低 | 强确认 + 最终预览 |
| 删除数据 | 高 | 低或不可逆 | 强确认，优先回收站或软删除 |
| 支付或下单 | 关键 | 有限 | 强确认 + 金额、对象与账户二次核验 |
Human-in-the-loop 的六类触发器
- 高风险：资金、身份、生产环境、法律责任等。
- 不可逆：删除、提交、发布或难以撤销的外部动作。
- 对外沟通：Agent 以用户身份向第三方发送内容。
- 意图不清：存在多个合理解释且不同选择会显著改变结果。
- 异常成本：工具调用次数、金额、Token、时间或资源消耗超出阈值。
- Evidence Sufficiency 不足或证据冲突：系统无法可靠判断事实、参数或执行结果。
核心不是“每一步都确认”，而是在错误影响即将扩大之前确认。
权限设计：Least Privilege 与 Just-in-time Permission
Agent 能力越强，权限设计越接近产品核心。最小权限原则要求系统只获得完成当前任务所需的最低权限；即时授权意味着只有任务真正需要某项能力时再请求，而不是首次使用产品就索取邮箱、日历、云盘和通讯录的全部权限。
| 权限层级 | 可做什么 | 典型策略 |
|---|---|---|
| Read | 读取信息 | 可持续授权，但明确数据范围 |
| Create | 新建草稿或对象 | 通常低到中风险 |
| Modify | 修改已有对象 | 版本记录与撤销 |
| Send / Publish | 对外产生影响 | 通常执行前确认 |
| Delete | 移除数据 | 优先软删除、强确认 |
| Purchase / Commit | 资金或不可逆承诺 | 最高强度确认与额外校验 |
Agent Security：当外部内容本身不可信
当 Agent 开始浏览网页、读取邮件、处理文件以及调用外部 Tool 后，风险不只是“有没有权限”，还包括外部内容本身可能包含攻击指令。产品必须坚持：Untrusted Content ≠ Trusted Instruction。
| 风险 | 产品场景 | 产品侧保护 |
|---|---|---|
| Indirect Prompt Injection | 网页、邮件、文件试图改变 Agent 行为 | 外部内容视为 Data；高风险动作再次确认 |
| Tool Trust | 第三方 Tool 或 MCP Server 返回异常或恶意内容 | Tool Allowlist、来源验证、Schema Validation |
| Cross-system Data Leakage | 数据从一个系统被错误发送到另一个系统 | Data Scope、目标系统限制、敏感数据检测 |
| Authorization Abuse | Agent 获得超过当前任务需要的权限 | Least Privilege、即时授权、Token Scope |
这不是网络安全技术教程，而是产品边界设计：权限、Tool Boundary、Sandbox、Human Checkpoint、Trace 与 Rollback 需要共同限制一次错误或攻击的“爆炸半径”。
06｜失败不是异常：可观测性、状态与恢复设计
为什么 Agent 比 Chatbot 更容易“错得更远”
Chatbot 的一次错误通常停留在一段回答中；Agent 的错误会通过计划、工具和状态继续传播。错误目标可能生成错误计划，错误计划会触发错误工具调用，错误结果又可能成为下一步输入。Failure Path 因此不是边缘情况，而是 Agent 核心路径的一部分。
恢复机制可以概括为四类：Retry、Re-plan、Rollback、Escalate。产品需要明确系统什么时候可以自行重试，什么时候应该换路径，什么时候必须撤销，以及什么时候应该停止并把决定权交还给用户。
Agent State Machine：让任务处于可管理状态
| 状态 | 含义 | 用户应该看到什么 |
|---|---|---|
| Planning | 正在形成计划 | 目标、约束、预计步骤 |
| Executing | 正在调用工具执行 | 当前步骤、关键进度 |
| Waiting for User | 等待信息或审批 | 缺什么、为什么需要用户 |
| Retrying | 在安全范围内重试 | 失败原因、当前第几次尝试 |
| Re-planning | 原路径不可行，正在换方案 | 将改变哪些步骤 |
| Blocked | 无法继续 | 阻塞原因与可选替代方案 |
| Partially Completed | 部分完成 | 已完成部分、未完成部分、原因与影响 |
| Completed | 满足完成条件 | 最终结果、证据与后续操作 |
进度可见：不要只显示 “Thinking…”
当 Agent 工作几十秒甚至数分钟，用户最关心的不是内部推理文本，而是“它是否在推进”“是否卡住”“是否正在做我允许的事情”。Progress Visibility 应展示可验证的工作状态，而不是伪装成透明度的长篇思维输出。
| 差的进度信息 | 更好的进度信息 |
|---|---|
| Thinking… | 正在读取 12 份候选资料，已完成 8 份 |
| Working… | 已筛除 7 个不匹配岗位，正在分析剩余 5 个 JD |
| Almost done… | 报告主体已完成；2 个数据来源存在冲突，正在交叉核验 |
| Something went wrong | 日历接口连续失败 2 次；可以稍后重试，或先生成会议邀请草稿 |
失败分类与恢复策略
| 失败类型 | 例子 | 优先恢复方式 |
|---|---|---|
| 理解失败 | 目标或对象识别错误 | 请求最小澄清；回到 Goal 层 |
| 计划失败 | 路径遗漏关键步骤 | 局部 Re-plan；保留已有成果 |
| 工具失败 | API 超时、页面变化 | Retry → 替代工具或数据源 |
| 权限失败 | 未授权、登录过期 | 解释所需权限并请求授权 |
| 数据失败 | 缺失、冲突、低质量 | 标记不确定性；补证据或让用户选择 |
| 执行失败 | 工具返回错误状态 | 停止后续高影响动作，必要时 Rollback |
| 验证失败 | 动作成功但目标未满足 | 继续补步骤，不把 “200 OK” 当完成 |
| 循环或成本异常 | 反复尝试无进展 | 触发预算与次数阈值，Escalate 给用户 |
Partial Success：比“成功 / 失败”二元状态更真实
复杂任务经常只完成一部分。例如 Agent 成功分析了 17 份文件，但 3 份加密文件无法读取；完成了会议 Brief，却因为权限不足无法创建日历邀请。简单标记“失败”会抹掉已有价值；标记“完成”又会掩盖缺口。
因此 Agent 产品需要正式支持 Partially Completed：明确已完成、未完成、原因、影响和下一步选项。部分成功状态也有利于恢复，因为系统可以从已有成果继续，而不是重头执行。
07｜Trust Design 与结果验证
用户信任来自哪些产品因素
当产品只生成文本时，用户可以用“看完再用”控制风险；当 Agent 能直接影响外部世界时，信任必须被设计成一组具体机制。用户需要知道 AI 准备做什么、为什么做、能做到什么范围、做完后发生了什么，以及做错后如何恢复。
| 机制 | 作用 |
|---|---|
| Preview | 在高风险操作前让用户看到对象、参数与后果 |
| Explain | 解释行动依据与关键假设，而非暴露内部思维链 |
| Scope | 明确权限边界、数据范围与时间范围 |
| Evidence | 关键事实附证据或来源，支持核验 |
| History / Trace | 保留任务、工具调用与关键状态的可追踪记录 |
| Undo / Rollback | 对可逆动作降低错误后果 |
| Confirmation | 在影响扩大前建立人工检查点 |
| Guardrails | 在输入、工具调用或输出层拦截违规行为 |
本文将 Agent 用户信任拆解为四个主要产品因素：Accuracy、Transparency、Control、Recoverability。模型准确性影响用户第一次是否愿意尝试；透明、可控和可恢复，更影响用户是否愿意长期把行动权交给 Agent。这是一种产品分析拆解，不是数学等式。
Outcome-oriented：从“动作成功”转向“目标完成”
Agent 最容易出现的评测错觉是把 Tool Success 当作 Task Success。用户说“给张三安排明天下午会议”，Calendar API 返回成功并不意味着任务完成；还需要验证时区、参会人、时间冲突、邀请是否真的创建并处于预期状态。
因此每个高价值任务都应定义 Completion Criteria。系统在结束前需要执行结果核验；若无法自动验证，也应明确告诉用户哪些部分已确认、哪些部分仍依赖人工检查。
Agent Product Scorecard
| 指标 | 定义 | 为什么重要 |
|---|---|---|
| Task Completion Rate | 满足用户最终目标的任务比例 | 最核心的结果指标 |
| First-pass Success | 无需重试或人工修正即可完成的比例 | 反映稳定性 |
| Action Accuracy | 关键动作对象、参数和操作是否正确 | 防止“做了很多但做错” |
| Human Intervention Rate | 任务中需要用户接管或补信息的比例 | 衡量自主性与打断成本 |
| Recovery Rate | 发生失败后能够恢复并完成的比例 | 衡量鲁棒性 |
| Undo / Correction Rate | 用户撤销或修改 Agent 行动的比例 | 识别潜在错误与不信任 |
| Completion Time | 从目标提交到交付的时长 | 衡量效率 |
| Cost per Task | 模型、工具与基础设施的单任务成本 | 决定规模化可行性 |
| User Acceptance | 用户最终采用交付结果的比例 | 连接模型表现与真实价值 |
最重要的北极星指标是 Verified Task Completion Rate：经结果核验后，真正满足 Completion Criteria 的任务比例。
Tool Success ≠ Task Success覆盖“结果、过程与边界”
Agent 评测至少覆盖三层：结果层看任务是否完成；过程层看工具、计划、状态与重试是否合理；边界层看权限、确认、Guardrails 是否在正确时机生效。离线阶段可使用可重复的沙盒任务；上线后结合真实任务成功率、人工介入率、异常分布与用户纠正行为持续监控。
从框架到实测：一次 Codex Agent 真实使用观察
这不是 Codex 使用教程，也不是性能 Benchmark。这里使用真实 Coding Agent 工作流，观察前文提出的 Context Gathering、Planning、State、Action 与 Verification 是否会在实际任务中出现。
实测 01｜Context Gathering & Planning
截图中，Codex 明确说明“已完成只读检查，尚未写入任何文件”，并识别 Astro 7、MDX Content Collection、/insights/、/research/<slug>/、PDF 阅读页、Article Header、Sticky TOC、Lightbox 与首页研究数据逻辑。
**产品观察：**Agent 的第一步不应该总是 Action。对于复杂系统，可靠的 Context Gathering 是后续执行正确性的基础。
实测 02｜Multi-file Action & Verification
第二项任务涉及 Notes 页面、Timeline Card、多篇 MDX、日期排序与 Series Metadata。Codex 不仅列出修改文件，还继续验证最终顺序：08-17 → 08-13 → 08-12 → 08-11 → 08-06。
**产品观察：**Code Change Success ≠ User Goal Success。用户要求的是“最终页面按正确顺序工作”，而不是“代码成功保存”。
实测 03｜Build / Link Verification
第三项任务同时涉及 Content Schema、Series Metadata、Article Components、Notes Timeline 与多篇 MDX。Codex 随后运行 Prettier、ESLint、Astro check、npm run build 与链接检查；当次记录为 33 pages generated、14 internal pages checked、0 missing links。
**产品观察：**Verification 必须属于 Agent 工作流本身，而不能完全留给用户事后检查。
该实践只是一次真实产品体验观察，不构成 Codex 模型能力 Benchmark，也不能代表其所有任务的成功率。
08｜从研究走向产品：Personal Work Agent MVP
为什么 2026 年还要设计这个 MVP？
2026 年已经存在 ChatGPT Work 等通用 Agent，因此本文不是重新设计一个“万能 AI Assistant”。Personal Work Agent 是用于验证本文产品机制的设计载体：把 Goal Card、Progressive Clarification、Plan Preview、Progressive Autonomy、Risk-triggered Approval、Activity Timeline、Partial Success、Undo / Rollback 与 Result Verification 放入同一个可检查流程。
From Research to Product
Personal Work Agent
帮助知识工作者完成需要跨资料、跨工具与多步骤执行的复杂工作任务。
这个 MVP 不追求“什么都能做”，而聚焦一种高频价值：把用户从搜索资料、阅读、整理、写文档与准备沟通的重复多步骤工作中释放出来，同时严格限制高风险外部动作。
MVP 目标：用户用一句自然语言描述任务后，Agent 形成目标卡片和高层计划，在授权范围内完成搜索、文件读取、信息整理和文档生成；涉及对外沟通时只生成草稿，获得用户批准后才执行。
MVP Scope 与 Non-goals
| MVP 支持 | 第一阶段明确不支持 |
|---|---|
| 网页搜索与公开信息读取 | 自动支付或下单 |
| 用户授权文件读取 | 不可逆删除 |
| 文档生成与结构化整理 | 无确认自动对外发送 |
| 邮件草稿生成 | 生产环境修改 |
| 日历读取与冲突检查 | 跨组织的高权限系统写入 |
| 低风险任务状态记录 | 长期无限制后台自主运行 |
核心任务案例：“帮我准备明天下午的项目评审会议”
| 步骤 | Agent 行为 | 产品机制 |
|---|---|---|
| 1. Goal Understanding | 识别会议对象、时间与准备目标 | Intent / Goal / Constraints |
| 2. Context Gathering | 读取日历、指定项目文档与历史会议记录 | Just-in-time Permission |
| 3. Planning | 形成“进度—风险—未决问题—议程”的高层计划 | Plan Preview |
| 4. Execution | 整理材料并提取关键证据 | Tool + State + Progress |
| 5. Artifact | 生成 1 页 Brief 与议程草稿 | Artifact Workspace |
| 6. Verification | 检查关键数据与引用是否齐全 | Result Verification |
| 7. Approval | 询问是否生成或发送会议材料 | Human Checkpoint |
| 8. Completion | 经确认后执行允许动作并记录结果 | Trace + History + Recovery |
Prototype 01｜Task Creation
用户输入最终目标，同时补充截止时间、资料范围、限制条件和允许调用的工具。界面把自然语言任务转换为可检查的目标、约束与授权范围，而不是立即开始不可见的执行。
Prototype 02｜Plan Preview
在复杂任务真正执行前，让用户了解 Agent 准备如何完成任务，并允许修改执行计划与边界。页面只展示稳定的高层阶段、预计工具与风险边界，避免把内部细碎步骤全部暴露给用户。
Prototype 03｜Execution Workspace
执行过程中持续展示 Current Step、Activity、Artifacts 与待处理的 Approval。聊天仍是入口，但任务、状态、产物和审批拥有各自清晰的位置。
Prototype 04｜Approval & Result
高风险动作执行前，界面展示 Action Summary、Risk Review、Approval Required、最终预览与已完成的校验。用户可以 Review、Edit、Approve 或 Cancel。
对于已经完成的不可逆行为，产品不应显示虚假的 Undo。邮件发送后更合理的恢复入口是 Create Correction、Send Follow-up 与 View History；Undo / Rollback 只适用于真正可逆的动作。
| 页面 | 核心信息 | 关键交互 |
|---|---|---|
| Task Creation | 用户目标、附件、可用上下文 | 自然语言输入；快速补充约束 |
| Plan Preview | 目标卡、阶段计划、预计使用工具 | 开始执行、调整计划、修改权限 |
| Execution Workspace | Current Step、Activity、Artifacts | 暂停、取消、查看证据、调整任务 |
| Approval & Result | 高风险动作预览、最终交付物、完成核验 | Review、Edit、Approve、Correction、Follow-up |
关键产品假设与验证方法
| 假设 | 验证方式 | 核心指标 |
|---|---|---|
| H1 用户愿意把低风险、多步骤任务交给 Agent | 可用性测试 + Beta 真实任务 | Task Completion、人工接管率 |
| H2 Plan Preview 能降低复杂任务的方向性错误 | A/B：直接执行 vs 计划预览 | 取消率、计划修改率、首次成功率 |
| H3 关键节点确认优于逐步确认 | A/B：全量确认 vs 风险触发确认 | 确认次数、完成时间、错误率 |
| H4 Activity Timeline 能提升长任务可理解性 | 访谈 + 行为数据 | 中途取消率、查看进度率、信任评分 |
| H5 Undo 能提高用户对 L4 可逆自动执行的接受度 | 灰度开放可撤销自动化 | 授权率、撤销率、长期留存 |
| H6 结果核验能减少“看似完成”的假成功 | 增加 completion checks 前后对比 | Task Success、返工率 |
MVP 的成功标准
MVP 是否成功，不应以“用户觉得很智能”衡量，而应以能否稳定减少真实任务成本衡量。第一阶段的北极星指标是 Verified Task Completion Rate，并用平均人工介入次数、完成时长、撤销或纠正率和单任务成本作为约束指标。
如果任务完成率提升的同时，确认次数和成本快速上升，说明系统可能只是用更多步骤换取结果；如果人工介入率很低但纠正率升高，则说明自主性超出了用户可接受边界。Agent 产品需要在结果、效率与风险之间做三方权衡。
09｜结语：Agent 产品真正竞争的不是“会不会调用工具”
Agent 让 AI 产品从“信息系统”向“行动系统”移动。这个变化改变了产品经理需要关注的核心问题：过去更多关心回答质量、对话体验和内容生成；现在还必须关心权限、环境状态、过程可见、人工审批、失败恢复、成本边界与结果责任。
因此，Agent 不是 Chatbot 加几个 Tools，也不是把固定 Workflow 换成大模型来决定每一步。一个可用 Agent 的关键，是把目标、计划、权限、行动、反馈、恢复和验证组织成稳定闭环，并在每一个可能放大错误的节点设计控制机制。
未来 Agent 产品的竞争，可能逐步从 Model Capability 转向 Task Completion Reliability：谁能在真实环境里更稳定地完成任务、少打断用户、可解释地失败、可恢复地继续，并在需要的时候把决定权交还给人，谁才更接近真正的生产力产品。
当 AI 产品从“回答用户”进一步走向“代表用户行动”，产品经理需要关注的不再只是模型生成质量，而是目标理解、任务规划、权限、状态、确认、恢复和结果验证。
Agent 真正需要解决的，并不是“AI 能不能执行更多事情”，而是：哪些事情应该由 AI 自主完成，哪些决策必须重新交还给用户。
附录
附录 A｜Agent 产品需求评审 Checklist
- 需求是否真的需要动态决策？固定 Workflow 是否已经足够？
- 用户的最终 Goal 与 Completion Criteria 是否可明确描述？
- Agent 需要访问哪些工具、数据与账户？是否满足最小权限原则？
- 哪些动作会影响外部世界？分别属于什么风险等级？
- 哪些动作必须在执行前确认？哪些动作允许执行后撤销？
- 任务状态有哪些？是否支持 Pause / Cancel / Resume？
- 每一步如何获得环境反馈？如何判断工具“成功但结果错误”？
- 失败后采用 Retry、Re-plan、Rollback 还是 Escalate？
- 是否定义最大迭代次数、时间预算和成本预算？
- 用户能否看到有意义的进度，而不是只有 “Thinking…”？
- 结果是否具备证据、来源或其他可验证信息？
- 离线评测集是否覆盖成功、失败、权限和边界案例？
- 上线后是否能观测任务完成率、介入率、恢复率、撤销率和成本？
附录 B｜Agent 风险与确认模板
| Action | Risk | 默认确认策略 | 必要保护 |
|---|---|---|---|
| Search | Low | No | 来源与范围控制 |
| Read File | Low–Medium | 通常 No | 文件范围授权、敏感数据提示 |
| Create Draft | Low | No | 清晰标记草稿 |
| Modify File | Medium | 按授权范围 | 版本历史、Undo |
| Change Calendar | Medium | 视组织策略 | 变更摘要、Undo |
| Send Email | High | Yes | 收件人、正文、附件最终预览 |
| Publish / Submit | High | Yes | 强确认、身份与对象核验 |
| Delete | High | Yes | 软删除优先、二次确认 |
| Purchase / Pay | Critical | Strong Confirmation | 金额、对象、账户二次校验 |
附录 C｜LLM / Workflow / Agent 选择速查
| 问题 | 若答案为“是” | 推荐方向 |
|---|---|---|
| 一次生成即可完成？ | 无需持续调用工具或修改状态 | LLM / Chatbot |
| 流程能够被稳定写成固定节点？ | 输入输出和分支规则较确定 | AI Workflow |
| 中间结果会持续影响后续路径？ | 必须根据环境反馈决定下一步 | Agent 候选 |
| 需要多个系统协同与长期状态？ | 跨工具、跨阶段、需要恢复 | Agent 价值更高 |
| 错误后果很高且缺乏回滚？ | 自主行动风险不可接受 | 降低自治或不用 Agent |
| 自动化收益不足以覆盖成本或延迟？ | “更智能”但业务收益有限 | 保持更简单方案 |
References / 参考资料
本文以一手官方产品、工程与协议资料为主。以下链接均在本文论证中实际使用：
OpenAI — OpenAI Agents SDK Documentation
，2026。
Anthropic — Building Effective AI Agents
，2024-12-19。
Anthropic — Demystifying Evals for AI Agents
，2026-01-09。
Anthropic — Trustworthy Agents in Practice
，2026-04-09。
OpenAI — ChatGPT is now a partner for your most ambitious work
，2026-07-09。
Model Context Protocol — The 2026-07-28 Specification
，2026-07-28。
Google Developers — Agent and Model Evaluations in Gemini Enterprise Agent Platform are now GA
，2026-07-31。
OpenAI — From assistance to execution: How enterprises put AI to work
，2026-08-12。
Anthropic — Mitigating the risk of prompt injections in browser use
，2025-11-24。
Model Context Protocol — Security Best Practices
，2026-07-28。
Anthropic — Measuring AI agent autonomy in practice
，2026-02-18。