# 普通人需要 AI，但未必需要一个通用 Agent 上一篇我写到，很多人对 AI 的兴奋常常来自一种“产出物幻觉”。原来做不出来的东西突然出现在屏幕上，粗糙想法被包装成像样结果，甚至还能跑起来。成就感会先于判断抵达。人于是很容易把“我生成了一个东西”理解成“我解决了一个问题”。这正是后面所有讨论的起点：产出变多，不等于能力变强。 通用 Agent 面向大众市场时，会把这个问题放大。Chatbot 主要发生在对话里：你把问题抛给它，它给出解释或草稿。Agent 的承诺更往前一步，开始替用户行动。它不只是回答，而是接入工具，调用记忆，并推动任务继续往下走。这个叙事最迷人的地方，也最容易出问题：它让人觉得每个人都应该拥有一个数字员工。 我认为这个叙事很可能会失效。Agent 能力会成功，也会进入大量产品和工作流；但那种面向广大普通用户，把完整工作流暴露给用户自己维护的独立通用 Agent 产品，很难成为真正的大众入口。 这个判断需要先划清边界：普通用户当然需要 AI，只是很多需求并不值得用一个重型 Agent 来解决。 ## Chatbot 已经解决了大量普通人的真实需求 对大多数普通用户来说，Chatbot 其实是一个非常好的入口。它最大的好处是简单：打开就能问。用户不必安装运行环境，也不必理解工具权限或 API 调用这些概念，更不需要先学会管理一个长期工作流。 这件事不能低估。普通人使用 AI 的大量场景，本来就低风险，也不要求很强承诺。用户常常只是卡在一个局部问题上：某个概念没懂，某段材料读不下去，某封邮件不知道怎么开头。Chatbot 的价值就在这里，它不必接管完整流程，只要在当前这一步把人往前推一点。上一篇我也强调过，学习和探索的快乐本身就有价值，不必每一次都换算成生产效率。 Chatbot 的优势正在于它不要求用户先成为一个“系统管理员”。问错了可以重问，模型答得不好可以追问，结果不满意也可以换一种说法。它的失败成本很低，使用边界也相对清楚。对于普通人而言，这种低成本的来回对话，比一个号称能自动完成一切的 Agent 更接近真实需求。 很多通用 Agent 的误判，是把少数重度用户的兴奋当成了大众用户的需求。重度用户看到的是自动化和长期任务链；普通用户先感受到的，往往是另一件事：安装麻烦，权限吓人，结果不知道怎么验收，跑起来以后 token 消耗还很快。 ## 演示能做，不代表值得长期使用 如果只看演示，AI 当然已经很强。一个粗糙想法可以很快变成网页，也可以被包装成一套像样的展示材料。再往前一步，它还能写小工具，替人把几个软件串起一段流程。第一次看到这种结果时，很难不震撼。它确实说明模型能力已经越过了一个门槛。 问题出在“严肃使用”和“重复使用”上。 一个任务进入严肃场景以后，要求会完全不同。目标不清，系统会跑偏。数据一旦不稳，结果就会失真。权限放得太大，又会引入新的风险。成本要控制，错误要发现，结果也要能追溯。一次演示只需要跑通，长期使用则要求它每天都能在相似但不完全相同的条件下跑通。后者已经超出提示词，进入了工程化管理。 这恰恰是程序员和类程序员群体擅长的领域。他们会先追问输入来源和状态保存方式。系统失败时，现场如何恢复；关键动作发生前，是否需要人工确认；任务能不能拆小；系统到什么程度应该停下来。这些问题看起来琐碎，却决定一个 Agent 能不能长期工作。普通人大多不应该承担这套注意力成本，我们也不应该期待他们为了使用 AI 而直接学习 AI 的工程化管理。 当然，现在普遍存在的 AI 焦虑也有积极的一面。它推动很多人学习，逼迫人们重新理解工具，甚至让一些非程序员开始掌握自动化和系统设计的方法。这是好事。可如果一个普通用户真的学会了怎样工程化使用 AI，那不能被简单归因为“通用 Agent 的大众成功”。更准确地说，这个人已经进入了更小众也更强的群体：他成了某种意义上的类程序员。 ## Coding Agent 的成功不能直接外推 Claude Code 和 Codex 这类 coding agent 的成功，经常被拿来证明通用 Agent 的未来。我觉得这个推导太快了。 AI coding 是一个非常特殊的赛道。代码能不能运行，是第一道反馈；测试和类型检查会继续收缩错误空间；diff 和 Git 记录，再加上 review，又让人能看到它到底改了什么。软件工程原本就有仓库，有依赖管理，有构建系统和 CI，也有代码评审和回滚机制。Agent 进入的是一个已经高度结构化的世界。 OpenAI 对 Codex 的产品定义就很克制。它没有把 Codex 包装成普通人的万能管家，而是明确放在软件工程任务里。它围绕代码修改这一件事工作：先理解代码并修改文件，再运行命令和测试，最后把结果做成可以审查的形态，并留下终端日志和测试输出。Codex 表面上像 Agent，底层其实是在借用软件工程的验证系统。它让人放心，靠的不只是模型会写代码。运行结果可验证，差异可以比较；出了错可以回滚，最后还有 review 兜底。 这也是 Claude Code 能够快速进入程序员工作流的原因。程序员本来就在这样的循环里工作。他会先定义任务和验收条件。任务失败后，他能拆问题，看日志，也能处理失败。他也能判断什么时候应该让 Agent 继续做，什么时候应该停下来。Agent 在这里没有替代工程化能力，反而依赖工程化能力。 把这个经验直接搬到大众市场，就会出现很大的断裂。普通用户当然也有任务。问题是这些任务往往没有测试和日志，也没有清楚的验收标准，更缺少天然回滚机制。一个报告写得像样，不代表判断是对的；一个PPT做得漂亮，不代表推动了决策；一个股票分析看起来专业，不代表真的承担了风险。离开 coding 以后，Agent 最需要的支点开始松动：目标变得含混，验证变得主观，工作流也很难维护。 ## 程序员到底在做什么？ 讨论到这里，其实需要重新审视一下程序员这个角色。 如果程序员只是“会写代码的人”，那么当普通用户都能写代码时，很多应用程序都应该消失。用户可以直接写出自己的记账软件，也可以写自己的 CRM，甚至写日程系统和数据分析工具。既然每个人都能创造软件，为什么还需要那么多应用和软件公司？ 现实不是这样运转的。历史上很多新技术出现时，都伴随过类似的大众化想象。建站也好，办公自动化也好，低代码应用和数据分析也好，都曾经被包装成“每个人都可以自己完成”的事情。最后出现的是更多封装；全民开发者没有成为主流。大众最终使用的是浏览器里的网站，是手机上的 App，是办公软件里的按钮，是云服务里已经设计好的流程。技术的能力越强，普通用户越希望它以更轻的方式出现。 这背后是分工有效。把它说成大众懒惰并不公平。程序员真正承担的事情，不只是把需求翻译成代码。他们把模糊目标变成稳定系统，把一次性的能力变成可以反复使用的产品，把复杂工具包装成普通人不用理解底层也能使用的界面。他们还要处理那些不漂亮但决定系统能不能长期工作的部分：状态要正确保存，权限要收住，成本要可控；异常要能被发现，升级不能破坏旧流程，安全边界也要提前设计。 AI 不会改变这个基本逻辑，反而会强化它。模型能力越强，可被创造出来的场景就越多，需要被包装的能力也越多。程序员不会因为 AI 会写代码就失去意义，他们会更多地承担“如何把 AI 能力变成大众可用产品”的工作。未来需要的未必只是传统意义上的程序员，也包括更多类程序员的创作者：他们懂 AI，懂产品，也愿意承担工程化管理带来的注意力消耗。 因此，我不认为“人人都掌握通用 Agent”是一个现实的大众市场假设。更可能的情况是，少数创造者掌握 Agent，把它变成更多应用和服务；多数用户继续使用被包装好的能力。 ## 通用 Agent 把工程化责任交给了用户 我对大众通用 Agent 最怀疑的地方，是它经常把工程化责任悄悄交给用户。 一个长期可用的 Agent，需要的不只是一次回答。它先要理解目标，再稳定接入数据，并拿到恰当权限。出错以后，它还要保存现场，把经验复用到下一次，并知道什么时候停止和恢复。这些听起来像产品功能，实际上都是工程化能力。对程序员或者类程序员用户来说，这些责任可以沉淀到配置和脚本里，写进技能文件，落进日志，最后交给云端运行环境。对普通用户来说，这套东西往往没有必要，也没有动力长期维护。 所以我不喜欢把“普通人不会用 Agent”解释成普通人能力不足。更准确的说法是，普通人没有理由承担这套成本。一个用户只是想整理账单，跟进几封邮件，或者规划一次旅行，为什么要理解 token 和 API key？为什么要知道哪些工具可以调用？为什么还要照看长期记忆，排查工作流失败，并理解安全边界？如果一个产品要求用户先学会这些，才能稳定获得价值，它就已经偏离了大众市场。 这也是很多需要用户自己提供 API token 的通用 Agent 会迅速变尴尬的原因。刚开始很好玩，因为用户第一次看到一个东西替自己行动；过一段时间以后，问题会不断变具体：token 为什么花得这么快，任务为什么跑偏，工具为什么误调用，结果为什么这次稳定下次又不稳定。最后用户还要定期修 prompt，修记忆，修工作流。 即使产品不要求用户自带 API，token 成本也不会消失，只是从用户账单里移到了产品公司的成本结构里。Agent 天然比 Chatbot 更贵。它先规划，再调用工具，过程中还要读长上下文；失败了，往往还会重试。只要任务价值不够高，成本就会变成硬约束。包月订阅可以在一段时间里掩盖这个问题，无法长期取消这个问题。 ## OpenClaw 是一个很好的观察样本 OpenClaw 之所以会让很多人兴奋，是因为它把“每个人都可以拥有一个个人 Agent”的想象做得非常具体。它可以连接服务，执行任务，保留记忆，甚至通过日常通讯工具接受指令。对很多人来说，这比传统 Chatbot 更像一个助手。 但 OpenClaw 同时也暴露了大众通用 Agent 的核心矛盾。它越强，就越需要用户授予更多权限；它越像一个个人管家，安全和隐私问题就越难被忽略，成本和维护问题也越难假装不存在。热度起来时，大家看到的是“它能做什么”；热度退去后，留下来的更可能是本来就习惯配置环境，也愿意阅读日志和修复工作流的人。 OpenClaw 的价值恰好在这里：它把问题暴露得足够彻底。大众用户喜欢 Agent 的演示效果，长期门槛却常常落在“能不能维护一个持续运行的人机系统”上。 Hermes Agent 的位置反而更务实一些。按照目前能看到的产品表达，它更像是在服务类程序员群体：这些人不一定每天写大量代码，但能够理解任务如何拆分，权限怎样配置，工作流如何沉淀，也接受云端部署带来的运行方式。它明确强调云上部署，也就没有把自己包装成一个本地全能管家。这种边界感很重要。它承认 Agent 需要稳定运行环境，也承认有价值的自动化需要持续运行。 把 OpenClaw 和 Hermes Agent 放在一起看，通用 Agent 的真实用户画像会不断收缩。最早被吸引来的人很多，真正留下来的，是那些愿意把 Agent 当作工程系统来管理的人。 ## 大众需要被包装好的 AI 更可能发生的是，Agent 能力被包装进具体应用里。账单整理发生在财务应用里，行程调整发生在旅行应用里；文档和会议处理留在办公软件里，客户跟进则留在 CRM 里。用户看到的是一个明确的产品能力，而不是一套需要自己搭建和维护的 Agent 框架。 这条路没有那么性感，但更接近真实市场。因为应用开发者可以替用户吸收复杂性：先决定数据从哪里来，再设计权限和成本边界。接下来，产品要让关键动作有确认机制，让结果有验收方式，也让失败以后有恢复路径。用户不需要知道背后是不是有 Agent，只需要知道这件事能不能稳定帮他完成。 很多通用 Agent 产品的问题，是它们把“创造者的工具”误包装成了“消费者的产品”。对于创造者来说，裸露工作流是自由；对于普通用户来说，裸露工作流是负担。创造者愿意为了可控性忍受复杂性，消费者只会在复杂性反复出现时离开。 ## Codex 和 ChatGPT 的分工反而更诚实 重新看 OpenAI 对 Codex 和 ChatGPT 的安排，会发现它其实没有把两个产品做成互相打架的关系。 ChatGPT 仍然是大众入口。它承担成本低且学习负担也低的任务，同时适合高频交互。用户在里面完成的，通常是从问题到材料的往返：先问，追问，再把材料整理成能用的形式。它也可以分析文件与搜索信息，或者接住一些轻量的主动任务。Projects 和文件上下文，再加上连接应用以及定时和监控任务，已经覆盖了很多通用 Agent 宣称要做的事情。Project 负责承载长期主题。资料和上下文放进去以后，ChatGPT 就可以在特定时间提醒或检查变化。这些功能没有要求用户先理解 Agent 架构，却在逐步把 Agent 能力产品化。 Codex 则是更重的工具箱。它面向的是软件工程和类软件工程任务，需要仓库和环境，需要测试与命令行，也需要审查机制。用户还要理解一次修改会带来什么后果。OpenAI 没有把 Codex 硬塞给所有普通用户，说每个人都应该用它管理生活；它把 Codex 放在一个更明确的工作场景里，同时让它和 ChatGPT 连接起来。大众用户从 ChatGPT 进入，硬核用户在需要时调用 Codex。 这个设计原则值得重视。它没有把功能无脑堆到一个产品里，也没有看到 Agent 火了就把所有东西都改名叫 Agent。它在区分不同用户的真实负担：普通用户需要入口简单，失败成本低，上下文可延续；专业用户需要更高权限，也需要执行力和验证环境。两个需求都存在，却不能用同一个裸露的通用 Agent 形态解决。 很多产品最容易犯的错，是把“我们可以让 AI 做更多事”理解成“我们应该把更多能力直接暴露给用户”。但产品设计的关键经常相反：越是复杂的能力，越需要被压缩成清楚的边界和默认值，也越需要确认机制与可恢复路径。Agent 能力越强，越不应该把系统管理责任随手甩给普通用户。 ## 普通人会使用 AI，但不一定会拥有一个通用 Agent 回到标题，普通人当然需要 AI。AI 会成为学习工具，表达工具，搜索工具和办公工具，也会成为大量应用背后的自动化能力。未来很多人每天都会和 Agent 能力发生关系，只是他们未必知道那个能力叫 Agent。 面向大众的独立通用 Agent 最大的问题，是它高估了普通用户维护工作流的意愿，也低估了长期运行的成本。演示阶段，大家看到的是一个任务被自动完成；使用阶段，用户面对的是权限和上下文，是验证与异常，也是 token 和安全。前者能制造传播，后者决定留存。 所以我不认为通用 Agent 会以“每个人一个 OpenClaw / Codex”的方式进入大众市场。更合理的路径，是 Chatbot 继续作为普通用户的低门槛入口，专业 Agent 成为硬核用户和创造者的工具箱，而大多数人的 AI 自动化需求，由具体应用包装后提供。 这也自然引到第三篇：即使个人真的因为 AI 或 Agent 变强了，这种增强能不能复制到团队里？如果每个人只是多生成了一些产物，团队未必变强；如果每个人都开始维护自己的小型 Agent，组织甚至可能获得更多碎片化工作流。个人工具的繁荣，离团队能力的提升，还有很长一段距离。