办公 Agent 正从“回答问题”走向“替人办事”，但真实办公场景中资料分散、判断复杂、结果难验证。千问办公产品负责人余航分享一线实践，拆解如何通过“找得到、推得动、交得出”接住真实任务，并探讨从跑通 Case 到产品化沉淀的关键：定义质量、控制边界、设计价值。

在 2026 AI 产品大会上，千问办公产品负责人余航分享了他在 QoderWork 以及千问办公产品实践中的观察：办公 Agent 怎样从“回答问题”走向“替人办事”，又怎样把一次跑通的 Case 变成可以反复交付的产品能力。

以下内容根据现场音频和演示材料整理，Enjoy：

大家好，我是余航，现在在千问办公负责产品。

其实我接到这次邀请的时候，还在 QoderWork 团队，后来阿里把 QoderWork、悟空和 MuleRun 三款产品合到了一起，我也从原来的产品工作转到了千问办公。

所以今天我不太想站在一个宏观观察者的角度，去讲“Agent 的未来会怎样”。我更想从自己这一年做 Agent 的经历出发，分享一些在一线看到的判断和问题。

千问办公融合了三款产品：QoderWork 提供桌面和本地工作现场，悟空连接钉钉和企业协作上下文，MuleRun 提供云端执行和专业能力。我们为什么要把它们放到一起？一个很现实的原因是，用户真正要完成一项办公工作时，往往需要这几种能力同时配合。

比如销售要给客户做一份项目进展 PPT，资料可能在电脑文件里，项目背景和历史沟通在钉钉、飞书等群聊或私聊里；人在外面时，还希望不打开电脑也能让这份 PPT 继续做下去。缺少本地、协作上下文或云端执行中的任何一块，我们都很难从头到尾接住这项工作。

一、从回答问题到替人办事，办公 Agent 的难点在哪里

我观察到，用户对 AI 的期待正在变化。过去，用户可能是问一个问题，希望 AI 给出回答，或者生成一段内容；现在，越来越多用户是把一件真实的事情交给 AI，希望 Agent 接住这个活儿，继续往下把事情办完。整个 Agent 市场也正在从“回答问题”走向“替人办事”。

这个趋势最早在编程领域形成清晰的产品形态，并不奇怪。代码世界已经准备好了 Agent 工作需要的环境：代码仓库、技术文档和 Git 记录让上下文比较集中；读代码、修改、运行、测试和 CI 形成了相对清晰的工作循环；代码能不能运行、测试能不能通过，也可以快速验证。

办公领域不一样。还是以客户拜访 PPT 为例，相关资料可能散落在电脑文件、钉钉或飞书的群聊、会议纪要和同事的记忆里。办公任务至少有三个现实问题：资料分散，判断很多，结果又不好验证。

我需要判断这次拜访要讲什么、听众是谁、重点是什么，哪些数据还没有补齐，哪些内容不能对外说。即使接入一个 PPT Skill，文件生成出来了，也不等于它的事实、数据、样式和表达都能用于真实场合。代码世界里现成的工作条件，到了办公场景都要重新解决。

一句“明天下午拜访客户，把最近的项目进展整理成一份 PPT”，背后其实是一整条工作链：先确认拜访目标，再翻历史沟通和客户关注点；找到旧方案、最新数据和相关材料；必要时找同事确认信息和口径；然后搭建汇报结构、生成 PPT，最后核对事实和数字，确保第二天可以直接拿去讲。

二、我们怎样把一项办公工作接住

在千问办公的实践里，我们把这条工作链压缩成三件事：找得到、推得动、交得出。

1. 让 Agent 找得到真实上下文

第一步不是让 Agent 立刻写 PPT，而是让它看见这项工作。准备客户拜访 PPT，需要拿到客户和项目资料、历史沟通和最新进展、会议结论以及客户关注点。

我们通过 DWS 把知识库、群聊和 AI 听记等信息带回同一个任务。Agent 找到的不是一堆孤立文件，而是客户是谁、项目进行到哪里、哪些信息已经过时、哪些问题还没有解决，以及这次拜访真正应该讲什么。

这对我个人也很实用。我每天会收到很多消息、需求和待办，开完几场会后，经常会忘记答应过谁、拒绝过谁、哪些事情还没有做。我会让 Agent 进入真实的钉钉上下文，把当天的聊天和会议内容走一遍，再整理出我答应了谁、接下来要做什么。没有这项工作的真实上下文，模型再聪明，也很难把事情落到实处。

2. 让 Agent 把任务往前推，人保留关键判断

资料找齐只是开卷。接下来要看 Agent 能不能继续把任务往前推进。这里很考验 Harness：我们要把模型、Skills、工具、Sub-agent 和人的参与组织成一套真正能干活的流程。

Agent 要理解目标、拆分任务、加载制作 PPT 所需的 Skills，并行搜索、分析和补充信息，再根据执行结果调整后续步骤。但我们不能把所有判断都交给 Agent。资料整理、信息搜索和初稿生成，可以让它自己继续；这次拜访要推动什么、内容重点是什么、哪些结论可以对客户讲，就需要在关键节点停下来，让用户澄清和确认。

所以一套好的 Harness，一方面要让 Agent 尽可能并行地往前推进，另一方面也要在信息不足或需要关键判断时暂停，把控制权交还给人。

3. 把结果交出来，而不是只生成一个文件

Agent 生成 PPT，不代表任务完成。PPT 没有像代码那样一套可以直接运行的 Test，我们还要检查数字有没有写错、事实来自哪里、内容重点对不对、版式是不是适合这个场合。

因此，在生成 PPT 后，我们提供了一个可以预览和编辑的工作界面。用户可以检查事实、修改内容、调整版式；如果只需要改某一页，也可以针对这一页让 Agent 辅助修改，而不必重新生成整份 PPT。这个工作台承担的是最后一公里：让用户拿到的不是还要重新加工的半成品，而是一份经过检查和修改、可以进入会议的结果。

PPT 上用“1–2 天 → 1 小时”表示这类交付时间的变化。这里我想强调的不是一个孤立的效率数字，而是从“生成文件”到“交付可用结果”之间，仍然需要人机协作完成验收。

三、跑通一个 Case，只是产品化的开始

到这里，我们把客户拜访 PPT 这个 Case 跑通了。但跑通一次，只能说明这一次做成了。要把一次成功沉淀成可以反复交付的产品能力，还要继续做三件事：定义质量、控制边界、设计价值。

1. AI 产品的 PRD，要写清楚“什么叫好”

产品经理说“做一个生成 PPT 的功能”，研发接入一个 PPT Skill，文件很快就生成了。但文件生成，不代表这份 PPT 可以拿去给客户讲。事实是否准确、结构是否完整、表达是否清楚、样式是否可用，这些质量标准如果没有定义，大家对“完成”的理解就不一样。

所以在 AI 产品里，我们要定义的不是“做什么功能”这么简单，而是这个功能的产物做到什么程度才算完成。除了真实任务，还要有输入材料、验收标准、失败样本和持续回归，把主观的“效果不好”变成研发可以理解、验证和优化的标准。

我很认同一句话：“Evals are the new PRDs。”只有把验收标准定义清楚，AI 产品的功能才有可能稳定地交付给用户。

2. 自主性不是全部放手，而是知道什么时候停

在编程领域，我们经常追求 Agent 的自主性：给它一个任务，它可以连续跑几个小时，直接把任务做完。但在办公领域，我们必须告诉 Agent，做到哪里要停下来找人。

原因很简单，不同动作做错之后的代价不同。内容写错了可以重来；但如果错误报价或错误信息已经发给客户，就很难收回。

所以我会看两个维度：第一，这件事有多不确定；第二，做错之后能不能撤回。

• 确定且可恢复的任务，可以让 Agent 自主执行；
• 信息不足但结果仍可恢复时，先主动澄清；
• 关键动作需要请求确认；
• 目标冲突或风险未知时，就暂停并让人接管。

办公 Agent 的自主性，不是完全放手，而是能够在正确的位置把控制权交还给用户。

3. 用户真正关心的是质量、速度和成本

产品能完成任务、质量和边界也定义清楚以后，还剩下一个很现实的问题：产品到底给用户提供了什么价值？用户不关心背后用了哪些 Skills、多少模型、多少 Sub-agent，他们关心的是结果质量、完成速度和消耗的成本。

不同任务的要求并不一样。内部整理或临时任务，用户可能希望尽快拿到基本可用的结果；日常分析和内部汇报，需要在质量与速度之间平衡；客户方案和重要对外交付，则更注重质量，需要更多搜索、验证和内容优化。

所以我们要把这些取舍做成用户能够理解和选择的档位，让用户在使用前知道大概要等多久、能拿到什么质量、适合完成什么任务。办公用户不一定知道每个模型名字意味着什么，直接给他一长串模型选项，反而把产品的判断成本转给了用户。

产品化不是一味追求最高质量，而是把质量、速度和成本之间的取舍做成清晰的用户价值。

4. AI Native 时代，产品经理要把“做好”说清楚

前面讲的是如何把 Agent 的能力标准化、产品化。回到产品经理自己，AI Native 时代功能和迭代越来越快，我们的工作方式也必须改变。我觉得有三件事很重要：定义结果、看懂过程、做出取舍。

第一，不要只提功能，要和研发约定结果。以前我们说“帮我做一个 PPT”，现在要把任务契约说清楚：面对谁，目标是什么，基于哪些材料，有哪些约束，做到什么程度才算完成。我们和研发约定的不能只是“我要一个这样的功能”，而应该是一个可以评测的结果。

第二，不能只反馈一句“效果不好”。如果 PPT 写错了产品名称，问题可能在上下文阶段：资料没有找全、没有识别最新口径；也可能在最后的验证阶段，事实检查少了一步。Agent 的工作链包括上下文、理解、规划、执行和验证，产品经理不一定要亲自写 Harness，但要能判断问题大概出在哪一层，把主观感受变成可以复现、修改和优化的问题。

第三，AI 让研发和产品快速出材料、出原型、出版本，产品经理更容易被需求和版本淹没。过去我们说“Talk is cheap, show me the code”；现在我更愿意说：“Code is cheap, show me the talking。”代码和长文档都越来越容易生成，真正难的是能不能把用户问题、产品判断和取舍说清楚。

AI 可以负责快速读材料、出版本；产品经理要负责判断真假、决定取舍、建立产品品味，并说清楚交付给用户的价值。能不能把这些事情讲清楚，是我认为 AI Native 时代产品经理最不能被替代的价值。

我最后想把今天的分享收回到一句话：AI 真正有用，不是它会得多，而是它能把事情办成。

让用户放心把事情交出去，最后拿回一个真正能用的结果，这才是我们做通用办公 Agent 时要回答的问题。