有个很常见的对照实验。同一个需求，比如“把手机导出的照片按拍摄日期重命名”，交给网页对话里的 AI，和交给装在本机的 Agent，结果会走向两个完全不同的世界。

前者的剧本是这样的：它给你一段代码，你复制、新建文件、粘贴、保存、运行，报错，把报错贴回去，它给你新代码，你再复制……一晚上过去，东西没跑起来，人先累了。

后者的剧本是：你说完需求，它去翻目录、写代码、运行、自己读报错、自己改、再跑，最后告诉你改了多少张、跳过了哪些。你去睡觉，第二天收成品。

很多人把这个差别归结为“后者更智能”。从工程角度看，这个解释基本是错的。真正的差别在四个地方：输入通道、输出通道、反馈闭环、以及成本结构。下面逐个拆。

一、输入通道：它拿到的是什么

网页对话里的模型，输入只有一份：你在对话框里输入的文本。它看不到你的文件系统，看不到文件内容，也看不到项目的目录结构。

这意味着所有“现状信息”都必须由人工转录过去。你的文件名长什么样、日期信息存在属性里还是在文件名里、有没有已经改过的一批——这些它一概不知，只能按最常见的情况去猜。猜对是运气，猜错就是你的一轮返工。

本地 Agent 的输入通道多了一层：它能主动读取。可以列目录、读文件、看代码、看日志、看运行输出。信息是它自己去取的，不是你替它搬的。

这一层差异看起来只是“省了你复制粘贴”，实际上改变了任务的性质：从“基于假设生成”变成了“基于观察生成”。前者本质上是概率输出，后者才可能做到确定性收敛。

二、输出通道：它给的是什么

网页 AI 的输出是一条消息。这段文字本身没有副作用，它不会创建文件，不会修改变量，不会启动进程。所有副作用都必须由人执行。

这决定了网页对话里的 AI 只能交付“指令”，不能交付“结果”。你可以把它当需求文档生成器、代码生成器、思路生成器，但它永远停在“说”这一层。

本地 Agent 的输出通道是双向的：一边对话，一边落盘。它能写文件、改文件、执行命令、启动进程。它的每一个动作都在真实环境里产生可观测的后果。

这也是为什么“Agent 能不能干活”这个问题，本质上不是一个模型能力问题，而是一个接口问题。模型只会输出文字，这句结论对两者都成立；区别在于这段文字后面接的是“人”，还是“执行器”。

三、反馈闭环：谁在读报错

我认为这是最容易被低估的一环。

网页对话里的循环，是人在推的：人复制代码，人运行，人看报错，人把报错贴回去，模型才知道错在哪。这个循环每转一圈，都要人做一次中间件。人不在，循环就停。

本地 Agent 的循环是它自己转的：执行、读输出、判断、修改、再执行。它读的不是你转述的报错，是原始报错；它看的不是你截图的界面，是真实的运行状态。信息没有经过人的翻译，就不会在翻译过程中丢掉关键细节。

这一点值得展开说。人转述报错的时候，往往会漏掉堆栈的关键行、漏掉警告、漏掉上下文里的路径。这些漏掉的信息，恰恰是定位问题的关键。所以“人肉 relay”不但慢，还会降低修复的成功率。

顺带说一句，这个循环在网页 AI 身上其实也存在，只不过它调用的是云端工具，能联网、能抓页面，但伸不到你的硬盘上。所以它更像一个闭环了、但闭环在别人机房里的智能体。

四、状态与记忆：一次会话，还是一个任务

聊天型 AI 的默认单位是“一次会话”。会话结束，上下文就散了。下次接着干，你得重新交代一遍前情。

Agent 的默认单位是“一个任务”。它需要维护任务状态：已经做了什么、还剩什么、哪些验证通过了、哪些被跳过了。所以它的工位上会有记忆管理，会有中间产物，会有可回看的执行记录。

这个差别在大任务上会放大。一次会话适合问答；一个任务需要认领、拆解、执行、验证、交付，这是一个项目管理的形状，而不是一次聊天的形状。

五、权限与边界：能力带来的是双向责任

讲到这里必须插一句。Agent 能改你的文件，就意味着它也能改错文件；它能删东西，就意味着它也能删掉不该删的东西。

所以一个成熟的 Agent 工位，不只是“给工具”，还得“给约束”：哪些目录可写、哪些操作需要确认、破坏性动作要不要二次核对、失败时是重试还是停下等人。

很多人只盯着“它能不能干”，忽略了“它有没有边界”。后者才是它能不能长期被你用的前提。

六、成本结构：为什么它天生更贵

Agent 每转一圈，通常都要把上下文重新读一遍，再生成下一步。转几十圈，token 消耗就是几十份上下文的总和。再加上跑偏、纠正、重试，成本会进一步放大。

所以网页端可以免费，本地 Agent 很难免费——不是商业模式选择，是这类工作方式的成本结构决定的。

这条成本规律带来一个很实用的推论：任务描述的清晰度直接决定成本。含糊的需求会导致更多轮试错，试错就是重复计费。把需求写成验收标准，是省钱最直接的手段。

七、工程结论：任务该怎么分流

把上面几条收起来，分流逻辑其实很清楚。

• 交给人机对话的：概念解释、思路梳理、文案起草、单点问题的判断、需要反复讨论的方案设计。这类任务的产物本来就是文字，不需要副作用。

• 交给 Agent 的：需要真实文件读写的、需要执行和验证的、需要多步试错收敛的、需要产出成品文件（程序、文档、表格、演示文稿、整理好的数据）的。

• 两者配合的：先在对话里把方案和验收标准聊清楚，再交给 Agent 执行。前者解决“想清楚”，后者解决“做出来”。

八、附：写给 Agent 的任务书，至少包含三样东西

如果你打算认真用 Agent，别把它当成一个更聪明的搜索框。给它写任务书，至少写清三件事。

1. 目标态。任务完成时，世界上多了什么、变了什么。不要描述过程，描述终态。

2. 验收标准。格式、命名规则、边界条件、失败如何处理、要不要交付清单。可判定的标准，才是标准。

3. 禁区。不许动的目录、不许执行的操作、不确定时必须停下来问的情形。

这三条写得越像技术规格书，Agent 的表现就越稳定。反过来，把它当许愿池，你就得接受它像实习生一样反复试错，而且账单来得很快。

一句话收尾：聊天型 AI 与 Agent 的分野，不在模型参数，在它能不能观察到环境、能不能对环境产生后果、以及那个反馈循环由谁来转。把这三件事看清，你就知道什么时候该聊天，什么时候该下班。