WorkBuddy / OpenClaw 这类产品的关键问题，不是“Agent 能不能操作电脑、写文件、调用工具”。
更关键的问题是：
用户为什么愿意把一件真实工作交给它？
它做错时用户能不能看懂、接管、回滚？
它做多了以后，能不能沉淀任务历史、权限配置、失败日志和可复用流程？
所以我不会把这类产品当成“炫技型自动化 demo”来评价，而会把它看成一个执行型 Agent 是否能成为工作入口的样本。
30 秒回答
如果面试官问：“你怎么看 WorkBuddy / OpenClaw 这类执行型 Agent？”
我会这样答：
我觉得它们的方向是成立的，因为很多办公、开发、资料整理和跨系统操作任务，用户真正想要的不是答案，而是结果被推进。但这类产品的分水岭不在“能不能动手”，而在“能不能被放心委托”。
我会从四层看：任务是否足够重要，Agent 相比 RAG / RPA / 普通助手有没有增量，公司有没有入口和工具生态优势，做成后能不能沉淀任务历史、权限日志、失败数据和工作流写回。
WorkBuddy / OpenClaw 给我的启发是：执行型 Agent 的机会真实，但壁垒不在一次 demo，而在稳定、可控、可验证、可接管、可复用。
这张卡不是什么
它不是 WorkBuddy / OpenClaw 的产品测评。
它也不是为了证明某个产品好或不好。
它要证明的是：
我能用一个真实体验过的样本，分析执行型 Agent 这个方向为什么值得做、哪里有增量、哪些体验问题其实指向底层产品问题，以及长期壁垒可能在哪里。
一、任务是否重要
执行型 Agent 不是适合所有任务。
我会先判断：用户是不是已经在为这些任务付出真实成本。
更适合交给执行型 Agent 的任务
1. 资料整理和格式转换
例如把网页、文档、聊天记录、表格材料整理成报告、摘要、清单、PPT 草稿、Markdown 文件。
这类任务频率高、风险相对低，适合做首次成功任务。
2. 跨工具的办公动作
例如从资料库读取内容，写入腾讯文档，生成链接，通知用户，或把结果同步到手机端。
这里的价值不只是生成文字，而是把结果放回用户真实使用的工具里。
3. 长周期任务的状态接续
例如持续跟进某个研究主题、项目文档、日报周报、求职材料、代码任务。
用户不想每次重新解释背景，也不想自己维护全部版本。
4. 开发者任务
例如读仓库、改文件、跑测试、根据报错继续修、生成 PR 说明。
这类任务可验收性强，因为代码能测试、diff 能看、失败能定位。
不适合直接委托的任务
1. 高风险外部动作
发正式邮件、公开发布、支付、提交合同、删除文件、大额交易，都需要强确认。
2. 重大判断任务
职业方向、产品路线、商业策略、重要汇报，不适合让 Agent 独立决定。
3. 用户自己也说不清目标的任务
如果目标、边界、验收标准都不清楚，Agent 越主动，越容易把事情带偏。
我的判断
执行型 Agent 的早期切入点，不应该是“什么都能帮你做”。
更合理的切入是：
先做低风险、高频、可验收、能写回的任务；再逐步进入需要监督委托和共同决策的任务。
二、Agent 是否有增量
执行型 Agent 的增量，不是“多一个聊天框”，而是把任务从回答推进到执行。
相比普通助手，它的增量在哪里
普通 Chatbot / RAG
更适合回答问题、总结文档、解释资料。
如果用户只要答案，不需要动作，Agent 增量有限。
Workflow / RPA
适合路径固定、字段明确、规则稳定的流程。
如果流程很稳定，不一定需要 Agent 接管。
通用 Agent + skill
适合自驱强、懂工具、会调 prompt 的用户。
但普通用户未必知道该选什么 skill，也未必知道怎么验收结果。
执行型 Agent
真正增量在于：理解目标、选择路径、调用工具、处理中途异常、产出文件或写回系统，并留下任务状态。
从体验里看到的增量
WorkBuddy 已经展现了一些有价值的方向：
- 微信登录、腾讯文档连接、QQ 邮箱等生态打通，降低普通用户进入成本。
- 没指定工作区时自动生成任务文件夹，减少用户一开始的文件管理压力。
- 生成报告后能预览，并可上传到腾讯文档。
- 可以把对话里的内容写入腾讯文档，说明它不只是回答，而是能写回真实工具。
- Clawbot / 微信入口让手机端可以调用电脑端能力，说明执行型 Agent 不一定只发生在桌面输入框里。
这些都说明：
WorkBuddy 的潜力不只是“能聊”，而是把 IM、桌面、文件、本地执行和腾讯文档串起来。
从体验里看到的不足
不足也很明确：
- 手机端看不到完整执行进度，容易误以为卡住。
- 电脑端和手机端消息同步不稳定，任务体验被切断。
- 任务生成的工作区在访达改名后，对话无法打开，说明状态依赖还脆弱。
- 执行过程展示太多，深度思考、搜索、获取网页等步骤淹没对话窗口。
- Skill 安装后，用户不知道能力发生了什么变化，也不知道什么时候该用。
- 专家入口看起来更像启动话术，而不是完整的专家知识、工具和流程组合。
- 记忆依赖文件注入和 Agent 主动写入，可靠性仍需要用户“信任但核查”。
这些问题不是简单 bug，而是执行型 Agent 的底层问题：
状态连续性、过程透明度、能力可见性、异常接管、跨端一致性和记忆可靠性。
三、公司是否有优势
执行型 Agent 不是谁都适合做。
我会看一家公司是否掌握四类资源。
1. 入口
WorkBuddy 的优势之一，是它可以从桌面、微信、服务号、小程序等入口触达用户。
这很重要。因为普通用户未必会主动打开一个“AI 工作台”，但可能会在微信里给一个 Clawbot 发消息，或者在电脑上让它继续处理文件。
入口的价值不是流量本身，而是：
它是否站在用户想发起任务的地方。
2. 工具和生态接口
WorkBuddy 连接腾讯文档、QQ 邮箱、小程序通知、微信登录，这些比单纯模型能力更重要。
执行型 Agent 的价值取决于它能否把结果写回真实工具。
如果只能生成文本，它只是助手。
如果能打开文档、编辑内容、同步结果、通知用户，它才开始接近工作入口。
3. 信任和权限
执行型 Agent 越能动手，用户越会关心：
- 它能访问哪些文件？
- 它会不会误删、误改、误发？
- 高风险动作前会不会确认？
- 出错后能不能回滚？
- 我能不能看见它改了什么？
这对有微信、文档、企业服务、云服务和账号体系的公司来说，是机会，也是压力。
4. 组织和生态能力
执行型 Agent 不是只靠模型团队做出来的。
它需要产品、模型、工具、云、文档、IM、权限、安全、用户运营、开发者生态一起配合。
WorkBuddy 的成长计划、腾讯文档连接、Clawbot、skill / 专家入口，都说明它不是单点工具，而是在尝试搭一个工作台生态。
但生态能不能成立，要看后续能否解决：
用户不知道 skill 有什么用、不会选 skill、不会验收 skill、也不知道安装后能力哪里变强。
四、做成后是否守得住
执行型 Agent 很容易被模仿。
聊天框、任务卡片、确认按钮、进度条、专家人设、skill 市场、自动化任务，这些都不是强壁垒。
真正可能守住的是资产。
容易被复制的部分
- 聊天入口。
- 侧边栏预览。
- 文件读写。
- 工作流编排。
- 专家人设。
- Skill 清单。
- 自动化任务。
- IM bot 入口。
- 思考过程展示。
这些功能重要，但不能单独构成壁垒。
更可能沉淀的资产
1. 任务历史
用户长期让 Agent 做过什么任务，哪些成功、哪些失败、哪些被采纳。
2. 权限配置
哪些文件、文档、邮箱、系统可以访问，哪些动作需要确认，哪些动作禁止。
3. 失败日志
任务在哪一步卡住，为什么失败，用户如何接管，后续如何修复。
4. 工作流写回
结果是否进入腾讯文档、邮箱、日历、项目管理、代码仓库、企业系统。
5. 个人 / 组织记忆
用户偏好、项目背景、团队规范、常用格式、历史判断。
6. Skill 生态治理
不是 skill 数量多，而是能搜索、审查、推荐、组合、评估 skill。
7. 信任基础设施
确认、预览、diff、日志、回滚、审计、人工接管、风险分级。
我的判断
执行型 Agent 的长期壁垒，不在“会操作电脑”。
更可能在：
谁能更稳定地进入用户真实工作流，记录任务过程，控制风险，写回结果，并让下一次任务因为上一次的沉淀而更顺。
执行型 Agent 的任务分层
面试时可以用这个分层来讲产品迭代。
1. 直接委托
适合低风险、结果可检查的任务。
例如：摘要、整理资料、格式转换、生成草稿、资料转表格、文件分类、日报初稿。
产品重点：首次成功、速度、结果预览、导出和保存。
2. 监督委托
Agent 可以做，但关键动作要确认。
例如：写入腾讯文档、发送邮件、修改共享文档、提交表单、改代码、创建自动化任务。
产品重点：预览、diff、确认、撤回、日志、权限分级。
3. 共同决策
Agent 只能辅助，不能替用户拍板。
例如：产品路线、职业方向、重要汇报、谈判方案、招聘决策。
产品重点：多方案、依据展示、风险提示、保留用户判断权。
4. 强确认 / 转人工
高风险、高责任任务。
例如：支付、合同、医疗、法律、投资、公开发布、删除重要文件。
产品重点：强确认、权限限制、人工接管、审计和责任边界。
产品下一步应该看什么
如果让我参与这类产品，我会优先看六个问题。
1. 首次成功任务
新用户第一次让 Agent 做什么最容易成功？
不要一开始就教用户管理 skill、配置记忆、理解工作区。应该给用户一个简单任务，让他立刻知道“这个东西能帮我完成一件事”。
2. 过程展示的颗粒度
用户不需要看所有内部步骤。
他需要知道：
- 现在在做什么；
- 卡在哪里；
- 要不要我确认；
- 失败后怎么办；
- 最终产物在哪里。
3. 跨端一致性
如果手机端发起任务，电脑端执行，结果和进度必须同步。
否则用户会感觉任务消失了、卡住了、不可控。
4. 结果写回
执行型 Agent 不能只输出一段答案。
它要让结果进入用户真实工具：文档、文件夹、邮箱、日历、代码仓库、项目系统。
5. Skill 可理解性
用户不应该面对一堆 skill 清单发呆。
更好的方式是：Agent 根据任务推荐 skill、解释为什么用、用完后展示效果，并让用户知道下次怎么复用。
6. 失败接管
执行型 Agent 一定会失败。
产品不应假装失败不存在，而要设计：
- 暂停；
- 接管；
- 重试；
- 回滚；
- 提交错误原因；
- 下次避免同类失败。
怎么验证它有没有变好
不要只看活跃用户和生成次数。
执行型 Agent 更应该看任务指标。
首次成功任务率
新用户第一次是否真的完成了一个有产物的任务。
任务完成率
任务是否从发起走到可验收结果，而不是停在半路。
人工确认通过率
用户看到预览 / diff 后，是否愿意确认执行。
失败接管率
失败时用户是否能接管，而不是直接放弃。
结果采纳率
产物是否被保存、写回、继续修改、提交或复用。
任务历史复用率
用户是否基于旧任务继续做新任务。
权限 / 风险拦截有效性
高风险动作是否被正确确认、拦截、记录。
跨端任务完成率
手机发起、电脑执行、手机查看结果的链路是否完整。
面试中可复述的判断
30 秒版
我看执行型 Agent，不会只看它能不能操作电脑，而会看它能不能被放心委托。它要先找到足够重要、低风险、可验收的任务，让用户形成首次成功；然后通过预览、确认、日志、回滚和失败接管，把更复杂的任务逐步接进来。长期壁垒不在一次 demo，而在任务历史、权限体系、工作流写回和反馈数据。
1 分钟版
WorkBuddy / OpenClaw 这类产品的机会是真实的，因为很多用户要的不是回答，而是跨文档、跨工具、跨设备把事情推进。但它们也容易被平台和模型厂商追赶，所以我会重点看四件事：第一，承接的任务是否足够重要；第二，Agent 相比 RAG、workflow、通用助手是否有执行增量；第三，公司是否有入口、工具接口和信任优势；第四，做久以后能否沉淀任务历史、权限日志、失败数据和工作流写回。否则就容易停留在“会动手的 demo”。
初步结论
WorkBuddy / OpenClaw 类执行型 Agent 的方向值得重点关注。
但它的成熟路径不是“越来越自主地替用户做所有事”，而是：
从低风险可验收任务开始，建立首次成功；
用预览、确认、日志、回滚和接管建立委托感；
通过任务历史、权限配置、失败数据、工作流写回和 skill 生态治理形成长期资产。
如果只做自动操作和聊天入口，它会很快被模型厂商、OS、浏览器、办公套件、开源框架模仿。
如果能进入真实工作流，并把每次执行变成下一次更可靠的上下文，它才有机会从工具变成工作入口。