# 普通用户未必需要一个通用 Agent

上一篇留下了一个产品问题：当AI提供的仍然是有条件的外部能力，普通用户究竟应该直接维护一套通用Agent，还是使用已经把复杂性收进产品内部的AI服务？

通用Agent叙事把“产出物幻觉”又放大了一步。Agent比Chatbot更让人兴奋，因为它看起来不再只是聊天，而是可以替人行动。它能接工具，读文件，调接口，写代码，安排任务，甚至假装自己有一点长期记忆。这个画面太有诱惑力了：每个人都拥有一个数字员工，随时听指令，自动干活，最好还能替你把那些烦人的工作都处理掉。这无异于数字飞升，永享天福。

作为泼凉水专业户，我对这个叙事也很怀疑。Agent当然有价值，也会进入大量产品，在专业场景里承担具体任务。但我的担忧在于：面向广大普通用户的独立通用Agent，很可能把少数硬核用户的爽感误读成了大众市场的需求。

普通人当然需要AI（就算只是为了情绪价值），这个判断现在已经没有太大争议。问题在于，他们需要的是一个随时打开、不管什么问题都会耐心解答的小可爱，还是一个把配置、授权、验证和token账单都交给自己的重型工程系统？这两个东西看起来都叫AI，对应的用户负担却完全不同。

## Chatbot已经覆盖了大量日常需求

对大多数普通用户来说，Chatbot现在仍然是最好的AI入口。它不够性感，也不太像一个“未来产品”，但解决的问题非常朴实。一个概念没懂，一段材料读不下去，一封邮件不知道怎么开头，或者一个想法在心中兜兜转转需要有人帮忙展开，Chatbot都能很快给出可以继续追问和修改的回答。

这个入口的关键价值是低负担。用户打开就能问，答得不好可以追问，结果不满意也可以换一种说法。它不要求用户理解运行环境和权限管理，也不教导用户配置API key、查看token账单。它的失败也相对便宜：一次回答不好，大不了删掉重来。

普通人使用AI的很多场景，本来就不需要一套完整的自动化系统。他可能只想借一次对话理解眼前的问题，或者获得一点启发。上一篇也提到过，很多AI使用的价值就在于知识、快乐和行动意愿，不必都包装成生产力革命。

通用Agent很容易把这个低负担入口改造成高负担系统。产品演示里，它替用户执行了更多步骤，看起来当然更厉害。只要授权更多工具，AI似乎就能把一切调度得风生水起。可它读取什么数据、能够做什么，需要由用户划定；出错如何发现和恢复，也会逐渐变成用户的问题，token账单则把这些责任直接换成了成本。

## 演示成功在掩盖长期成本

我能理解很多人第一次看到通用Agent时的兴奋。它确实很像魔法。一个粗糙想法可以变成网页，一个模糊任务可以拆成步骤，甚至还可以让硅谷的大佬们在电脑屏幕上开会，只为了讨论某个岗位需要什么MBTI特质的人才。用户刚走神回来，AI已经替他做出了一堆东西。这个瞬间非常容易让人相信AGI很快就要实现了。

但我们已经在第一篇里说过，类demo形态最擅长制造错觉。对通用Agent来说，这个问题还会更严重，因为Agent展示的不只是产物，还有“它替我行动了”的戏剧性。它会让人觉得自己终于拥有了一个数字管家。可演示成功和长期使用之间，隔着一套工程系统。一次成功要变成可复制的工作，目标和数据必须稳定，错误还要能够暴露在反馈里。

一次演示只需要在人工高度干预的情况下运行一次，长期使用则要求它在相似但不断变化的条件下反复完成任务。今天的数据格式变了，明天账号权限变了，后天模型理解错了一个细节，系统都要能发现问题并完成修复。一个Agent如果只是生成一份报告，也许问题还不大；如果它开始发邮件、改文件，甚至接触业务系统，风险马上就变成另一回事。

这也是我最不认同“人人都应该拥有一个通用Agent”的地方。它把必然存在的工程化责任包装成了另一个富有亲和力的个人效率工具。普通人只是想让AI处理邮件、账单或者旅行信息，为什么还要负责这套系统的权限和运行状态？如果稳定获得价值的前提是长期照看工作流，它就已经离大众入口很远了。

也会有少数用户愿意承担这套成本。他们开始学习自动化和脚本，也愿意长期维护自己的流程。可这时产品面对的已经不再是典型消费者，而是创造者。把他们的成功算成“大众通用Agent成功”，就像把少数会折腾NAS的人算成家庭服务器的大众化成功，判断会因此失真。

## Coding Agent的成功有特殊前提

Claude Code和Codex经常被用来证明通用Agent将会成功。AI coding是目前最成功的Agent场景之一，但它成功的原因，恰恰说明普通大众市场会很艰难。

代码世界天然适合Agent。一次修改能否运行，很快就有工程化反馈；测试和CI持续缩小错误空间，Git保留变更和回退路径，review机制则让人重新检查关键修改。软件工程原本就有仓库、依赖和验收环境，Agent进入的是一个高度结构化的世界。

程序员也天然适合这种工具。会写代码只是表层，更关键的是，他们习惯把模糊需求放进已有测试和版本管理的工程环境，失败时也能从日志和diff追查原因。Agent在这里没有替代工程化能力，反而极度依赖它。

这解释了为什么Claude Code能迅速进入程序员工作流，也解释了为什么Codex的产品边界很清楚。Codex没有被包装成普通人的万能管家。它围绕代码和工程任务工作，理解仓库、修改文件并运行命令，最后把结果留在可以审查的环境里。它看起来像Agent，底层借用的是软件工程几十年积累下来的验证系统。

离开代码世界，验收机制很快就会松动。一份股票分析看起来很专业，却很难证明它帮助用户承担了风险。PPT、网页和新闻聚合的问题也类似：产物出现了，目标却可能含混，错误未必会暴露，回滚机制也往往不存在。Agent最需要的支点开始松动。

## 复杂性最终还是会被产品吸收

如果程序员只是“写代码的人”，AI会写代码以后，这个角色的意义当然会被严重削弱。可程序员在现实系统里承担的工作，从来不只是把字敲进编辑器。

如果普通用户都会写代码，很多应用本来早就应该消失了。每个人都可以写自己的记账软件、CRM或者日程系统。在这轮AI浪潮之前，类似的想象已经出现过很多次：建站工具、办公自动化、低代码和数据分析平台，都曾经承诺让普通人直接创造工具。但全民开发最终没有成为主流。

这个结果一点也不奇怪。普通用户想要的是“不用理解系统也能解决问题”。他们使用浏览器、App、办公软件和云服务，因为产品已经在内部承担了复杂性。新技术越多越强，普通用户越需要无负担地使用它。

AI也不会例外。模型越强，能创造的应用场景越多，需要被包装的能力也越多。普通用户未必直接拥有一个OpenClaw或Codex，但会在财务软件里整理账单，在办公套件里处理材料，在旅行产品或CRM里使用被包装好的Agent能力。单纯编码的门槛会被稀释，把Agent做成产品、把一次成功变成稳定服务的工作却不会消失。

## OpenClaw暴露了这个矛盾

OpenClaw很适合作为观察样本。它让“每个人都可以拥有个人Agent”的想象变得具体：连接服务，执行任务，保留记忆，通过日常通讯工具接收指令。它比传统Chatbot更像助手，也更容易让用户产生“终于有个东西替我干活了”的兴奋。

OpenClaw越强，矛盾就越明显。它要做更多事，就需要更多权限。它越像个人管家，隐私和安全风险就越难被忽略，长期运行的成本与维护也无法藏在演示背后。热度起来的时候，大家看到的是它能展示多少惊艳效果；热度退下去以后，留下来的大概率还是愿意配置环境、阅读日志和调整工作流的人。

这不是OpenClaw一个产品的问题。这类大众通用Agent经常把创造者工具包装成消费者产品。对创造者来说，裸露工作流意味着自由；对普通用户来说，裸露工作流意味着麻烦。创造者愿意为了可控性忍受复杂性，消费者只会在复杂性反复出现时变成创造者或者离开。

Hermes Agent把自己的用户边界说得更清楚。它面向的更像类程序员群体，这些人能够理解任务拆分和权限配置，也愿意维护工作流。它强调云上部署，没有把自己包装成一个本地全能管家。这等于承认Agent需要稳定的运行环境，自动化也不会只靠一次漂亮演示。

如果几个月后再统计长期用户，他们很可能主要是那些愿意把Agent当作工程系统管理的人。第一波被吸引来的人很多，长期维护的负担会把其他用户逐渐挡在外面。

## Token成本会把爽感拉回现实

还有一个经常被低估的问题：token成本。很多通用Agent在演示阶段很容易让人忘记成本，因为用户看到的是结果，看不到中间经历了多少次规划、搜索、读取和重试。Agent天然比Chatbot更贵。它需要更长上下文，需要更多工具调用，也更容易因为不确定性而反复尝试。

如果产品要求用户自己提供API token，问题会更快暴露。最初的惊喜很快会变成核算。一次任务没有按预期完成，后面的重试以及对prompt和记忆的维护，都在消耗自己的钱。即使产品不要求用户自带API，成本也没有消失，只是从用户账单转移到了产品公司的成本结构里。

这会直接影响大众市场。普通用户愿意为稳定结果付费，却很难为不可控的探索过程持续付费。尤其是很多通用Agent最容易展示的场景，本身价值并不高：画几页漂亮PPT，做一个股市摘要，第一次很爽，第二次还能传播，第三次就要问它到底解决了什么问题。

如果任务价值不高，Agent越能干，浪费就越快。上一篇讲到的“产出物幻觉”，在这里会变成“token幻觉”：用户以为自己买的是自动化能力，买到的却可能是Agent的反复尝试，以及留给自己的判断负担。

## ChatGPT和Codex没有争夺同一个入口

ChatGPT和Codex没有被塞进同一个通用Agent，也没有因为Agent很热，就把每个功能都包装成“你的数字员工”。这种安排先区分了大众入口和重工具箱。

ChatGPT仍然是默认的大众入口。它处理高频任务，门槛低，失败成本也相对低。用户可以从提问开始，把文件放进上下文，围绕材料追问细节。Projects、Library、定时任务和连接应用，又把长期材料、主动触发与外部信息纳入这个入口。这些能力已经覆盖了很多通用Agent宣称要做的事，关键在于，用户不必先理解Agent架构。

Codex则是重工具箱。它需要仓库、环境、命令行和测试，也需要用户理解一次修改可能带来的后果。它不适合作为普通人的日常入口，却适合给硬核用户和工程化创作者提供执行力。ChatGPT和Codex连接起来以后，大众用户仍然从ChatGPT进入；需要重型工具的人，再把任务交给Codex。

大众用户需要简单入口和较低的失败成本，专业用户则需要更高权限和验证环境。用同一个裸露的通用Agent形态解决两种需求，通常会把两边都搞得别扭。

很多通用Agent产品最容易犯的错，是把“AI可以做更多事”理解成“用户应该直接看到更多能力”。产品设计经常恰好相反。AI越强，产品越要替用户吸收复杂性。用户不必知道背后是不是Agent，只需要看到任务稳定完成；危险动作由产品要求确认，失败也有恢复路径。

## 普通人会使用AI，但未必需要一个通用Agent

对于普通人而言，AI会成为学习工具和办公工具，也会成为大量应用背后的自动化能力。未来很多人每天都会使用Agent能力，只是未必知道那叫Agent。

我质疑的是另一种更激进的想象：每个人都需要一个OpenClaw或Codex式的个人通用Agent，并且愿意长期维护它。这个假设高估了普通用户管理工作流的意愿，也低估了长期运行的成本。演示阶段，大家看到的是任务自动完成；使用阶段，维护和出错的成本开始由用户承担，token支出也随之显现。前者能带来迅速传播，后者决定最终留存。

更可能出现的格局是：Chatbot继续承担大众入口，专业Agent成为创造者的工具箱，大多数人的自动化需求则被具体应用吸收。它没有“每个人都有数字员工”那么刺激，却延续了软件行业反复验证过的产品逻辑：技术越复杂，消费者越不应该被迫直接管理它。