一句话说清区别
普通对话应用是「你问一句，它答一句」，模型输出的就是最终交付物。Agent 是「你给一个目标，它自己拆步骤、调工具、看结果、再决定下一步」，模型输出的是动作，动作执行完的结果再喂回去继续循环。ChatGPT 网页版是对话应用，同一个 GPT-4 接上代码解释器、浏览器、文件系统，让它自己去查资料、写代码、跑代码、改 bug，那就是 Agent——比如 Cursor 里的 Agent 模式、OpenAI 的 Operator。模型本身没变，变的是外面的那层循环。
Agent 的四个组成部分
第一是规划：把「帮我订一张下周去上海的便宜机票」拆成查日期、比价、看时刻、下单等子任务。现在的做法基本是让大模型自己生成计划，ReAct 那种「想一步、做一步、看一步」的循环最实用，复杂任务再配一个显式的任务列表。
第二是工具调用：这是 Agent 和普通对话最大的分水岭。模型通过 function calling 输出结构化的调用指令，宿主程序去执行真实操作——查数据库、发请求、读写文件、操作浏览器。工具定义得好坏直接决定 Agent 的上限，PM 在这里要做的是决定「给它哪些能力、每个能力的权限边界在哪」。
第三是记忆：短期记忆就是对话上下文，长期记忆靠向量库或者结构化存储。实际项目里记忆往往是被高估的，大多数任务把关键中间结果写进上下文就够了，上来就搞长期记忆系统属于过度设计。
第四是环境反馈：工具执行的结果（成功、报错、返回内容）回传给模型，模型据此修正下一步。没有反馈闭环的「Agent」只是 prompt 链，这是判断一个产品是不是真 Agent 的试金石——市面上不少「Agent 产品」扒开看就是几条固定 prompt 串起来，流程是写死的，模型没有任何根据中间结果改主意的余地。
这四件事里，PM 介入最深的是工具定义和权限边界。给 Agent 配工具跟带新人一个道理：工具说明书（参数说明、返回格式、报错含义）写不清楚，再强的模型也调不对；权限放得太宽，迟早出事故。我们项目里光是「查订单」这一个工具的参数说明就改了十几版，改的不是代码，是描述文字。
PM 视角：什么任务适合 Agent
我的经验是三条标准：步骤多但路径相对固定、中间结果可验证、出错代价可承受。代码场景全中——Cursor 和 Copilot Workspace 能起来，就是因为代码能跑测试、能编译，错了立刻有反馈，改错了大不了回滚。反例是直接让 Agent 替用户转账、发不可撤回的邮件、操作生产环境，错误累积加上不可逆操作，一次事故就毁掉产品信任。
要算一笔账：单步准确率 90% 的 Agent，连跑 10 步全对的概率只有 0.9^10 ≈ 35%。所以 Agent 产品的核心设计不是「怎么让它更聪明」，而是「怎么在关键节点让人兜底、让系统可回退」。Manus 这类通用 Agent 演示惊艳但日常留存一般，问题就出在任务成功率撑不起用户预期。
产品设计上的取舍
做 Agent 产品我坚持两点：一是把自主性分级，像自动驾驶分 L2 到 L4 一样，默认低自主、关键操作必须人工确认，用户信任攒够了再放开；二是过程可见，把 Agent 的每一步思考和动作展示出来，Cursor 把 diff 摆在你面前让你 accept/reject 就是这个思路。黑盒全自动的 Agent 演示好看，实际没人敢用。另外要有心理预期：一个像样的 Agent 任务动辄消耗几万到几十万 token，成本是普通对话的几十倍，定价和限流策略得提前想清楚。
还有一个常被忽视的设计点是「任务范围收窄」。同样一个 Agent，「帮我处理这封邮件」比「帮我打理邮箱」靠谱得多——范围越具体，规划越不容易跑偏，工具组合越可控。做 Agent 产品的初期，宁可选十个窄场景做到八成成功率，也别做一个号称什么都能干的通用助手，成功率五成，后者在演示视频里赢，在用户口碑里输。