Agent 产品版图

每周都有新的 Agent 产品发布，如果只按产品名去记，很快就会被淹没。换个视角，按任务类型和系统设计来分类，版图其实相当清晰。这一课给你一张分类地图和一套比较维度。具体产品会不断更替，但这套方法在相当长时间内都适用。

按任务可以分成六类。Coding Agent 读写代码、修 Bug、提 PR，有编译、测试和 CI 这些天然验证手段。办公 Agent 处理文件、表格和邮件，验证较弱，多依赖人工检查产物。研究 Agent 做多轮搜索和综合，引用可追溯但结论难自动判定。浏览器 Agent 在网页上操作，易受页面变化干扰。客服 Agent 看解决率和转人工率。垂直业务 Agent 则取决于业务规则能否程序化校验。

除了按任务分，还有两种按形态划分的类别值得单独关注。一种是企业 Agent 平台，让企业自己搭建和治理 Agent，重点在知识接入、连接器、权限和生命周期管理，比如 Microsoft Copilot Studio。另一种是个人常驻 Agent，长期运行在个人电脑或服务器上，通过聊天软件接入，能执行本地命令、使用 Skills，比如开源项目 OpenClaw。

观察版图会发现，Coding Agent 的成熟度和用户接受度普遍领先。原因是代码领域天然具备 Agent 需要的条件：终端、文件和 Git 都是现成的文本接口，代码仓库本身就是完整上下文，编译和测试几秒就给出客观反馈，Git 让每次修改都能撤销，开发者也看得懂 diff。办公领域则相反，系统分散、标准模糊、邮件发出就收不回来，审查成本也高。

这对做业务 Agent 的启发是：想办法给你的领域补上测试和 Git。所谓测试，就是可以程序化执行的校验规则；所谓 Git，就是可回滚的操作，以及清晰的产物差异展示。补上这两样，业务 Agent 才能像 Coding Agent 一样被放心使用。

面对一个新产品，不要只看宣传视频，而是用同一套维度拆解：它替用户完成什么任务，能调用哪些工具，从哪里获取信息，在哪里动手，谁决定下一步，怎样确认做对了，哪些动作需要人确认，出错了怎么恢复。这八个维度也是整个课程最后拆解主流产品时用的框架。

用这套维度对比一下。Coding Agent 的工具是文件读写、终端、搜索和 Git，由模型自主规划，通过跑测试验证，出错了用 Git 回滚。客服 Agent 的工具是查订单、改地址、发起退款，常见做法是固定流程加模型判断，靠读回订单状态和客户确认来验证，退款或补偿超额要审批，出错了转人工或撤销操作。

从产品形态上能看到几条趋势。越来越多产品把计划、进度、产物和审批放在界面中心，而不是一问一答。Agent 在云端沙箱里运行，用户可以关掉电脑稍后回来。MCP 等协议让同一个工具被多个产品复用。Skills 让团队把专业方法沉淀下来共享。通用 Agent 覆盖长尾任务，垂直 Agent 凭借业务数据和规则做深。

这对你的产品意味着什么？做通用 Agent，竞争对手是大模型厂商，差异化难度高。做垂直业务 Agent，优势在业务数据、专有工具和行业规则，要优先把验证和审批做扎实。企业内部自建，先评估现有平台或产品能否满足。在现有产品里加 Agent 能力，就从用户最高频、最耗时的任务切入，不要另做一个独立的 AI 助手入口。

再看三个误区。第一，按模型厂商划分产品，其实同一家厂商会同时做 Coding、办公、浏览器等多类 Agent，底层模型相同，产品设计差异巨大。第二，通用 Agent 会吃掉所有垂直 Agent，但垂直场景的壁垒往往是数据、系统接入和业务规则。第三，演示视频通常是精心挑选的成功案例，要看它失败时怎么表现、需要多少人工介入、单任务成本多少。

课后请做一份迷你竞品地图。从六类里至少选三个你能接触到的产品，用八个维度逐项填写，能试用的尽量亲自试一次。然后把它们标在这张二维图上，横轴是自主性从低到高，纵轴是场景从通用到垂直。最后想一想，如果要做客服工单处理 Agent，最值得借鉴哪个产品的哪项设计。

总结一下。看 Agent 产品，按任务和执行环境分类，而不是按产品名或模型厂商。Coding Agent 跑在最前面，是因为工具、上下文、验证和回滚都是现成的，做业务 Agent 要想办法补上测试和 Git。遇到任何新产品，都可以用八个维度来拆解。下一课我们讲版图中最重要的变量之一：自主性等级。