第24章：主流 Agent 产品形态与垂直场景分析

框架告诉你怎么搭，产品告诉你怎么用。如果你只读框架文档，会错过大量来自实际落地的工程判断。

24.1 为什么要拆解 Agent 产品

很多工程师的第一反应是：我直接看 LangGraph 和 CrewAI 的文档不就行了？

框架回答的是"怎么搭"——状态图怎么设计、工具怎么注册、Agent 之间怎么通信。但产品回答的是另外三个问题：

怎么卖：谁在付钱，他们在为什么价值付钱
怎么用：用户的真实交互路径是什么，不是 demo，是日常工作流
怎么落地：权限怎么设计、沙箱怎么隔离、失败了怎么恢复、成本怎么控制

这三个问题在框架文档里几乎找不到答案，但在产品的设计决策里都有痕迹可循。

还有一个现实原因：很多团队的 Agent 实践，是从"老板说我们也得用 Cursor 或者 Claude Code"开始的，而不是从"我们来评估一下 LangGraph 和 CrewAI"开始的。产品先于框架进入团队，拆解产品能帮你快速定位"这个产品在解决什么问题、用了什么架构决策、哪里有工程局限"。

最后，不同产品形态代表了不同的执行位置（本地/IDE/云端）、任务时长（秒级/分钟级/小时级）和自主程度（建议/执行/委托），理解这些区别比死记框架 API 更有助于做技术选型。

24.2 五种典型产品路线

在现有的 Agent 产品里，可以清晰地看到五条路线，每条路线回答了不同的问题。

路线一：终端原生 Agent

在你的 shell 里直接工作。能读写文件、执行命令、调用 git、运行测试。最贴近"程序员的工作方式"——你的 .bashrc、Makefile、CI 脚本都在终端里，Agent 也在那里。

代表产品：Claude Code、OpenAI Codex CLI。

关键特征：本地执行、细粒度控制、天然支持脚本化和 CI 集成。缺点是缺少视觉反馈（没有 diff 预览面板），对不熟悉命令行的开发者有门槛。

路线二：IDE 原生 Agent

嵌入在编辑器里，能看到你当前的文件、光标位置、选中的代码，能做内联编辑、多文件重构、实时建议。

代表产品：Cursor Agent Mode、GitHub Copilot Agent、Gemini Code Assist Agent Mode。

关键特征：上下文感知更强（知道你打开了哪些文件、最近改了什么）、视觉反馈好（直接在 diff 视图里看改动）。缺点是任务执行时间受限于前台 IDE 进程，长任务容易阻塞工作流。

路线三：云端异步 Agent

任务提交到云端，在远程沙箱里独立执行，你去干别的事，完成后收通知。

代表产品：OpenAI Codex（在 ChatGPT 侧边栏里）、Devin、Cursor Background Agents。

关键特征：适合长任务委托（分钟到小时级）、可以并行起多个 Agent、有完整的执行记录和引用链。缺点是与本地环境的集成需要额外配置，中途修改方向不如本地便捷。

路线四：Browser/Computer Use Agent

不通过 API 操作系统，而是通过截图 + 鼠标键盘操作界面——就像让 AI 当一个远程桌面操作员。

代表产品：Anthropic Computer Use（Claude）、OpenAI CUA（Computer Use Agent）、Browser Use 开源库。

关键特征：能操作任何软件，包括没有 API 的老系统。缺点是速度慢、错误率高、成本高（每次操作都要截图送给模型推理）。

路线五：企业流程 Agent

不是帮你写代码，而是自动化业务流程：客服、审批、CRM 更新、工单分流、知识库问答。这条路线的用户往往不是工程师，是业务人员。

代表产品：Intercom Fin（客服）、Salesforce Agentforce（CRM/销售）、ServiceNow AI Agent（IT 工单）、各种内部自建的企业 Agent。

关键特征：直接对接业务系统、需要人工审批节点、对准确率要求极高（出错直接影响客户或财务）。

24.3 主流 Coding Agent 产品拆解

Coding Agent 是目前最成熟的 Agent 产品品类，也是工程师接触最多的一类。但说"coding agent"很容易以为就是"帮你写代码的 AI"——实际上，不同产品在执行位置、任务时长、权限模型、上下文获取方式上有根本性的差异。

Claude Code：终端里的 Agent 循环

执行位置：本地终端（Terminal）为主，也可以通过 IDE、CI、SDK 或托管入口接入

Claude Code 的核心是一个运行在你本地环境里的 agentic coding loop：接收指令 → 读取代码库 → 执行工具（bash、文件编辑、grep）→ 观察输出 → 决定下一步。

截至 2026.05，Claude Code 官方文档强调的是一组共同能力：CLI、IDE 集成、GitHub Actions / GitLab CI、Agent SDK、hooks、MCP、项目记忆文件和权限控制。具体入口和功能会继续变化，因此产品拆解时不要记"某个入口是否存在"，而要看它是否保留了同一套工程边界：工作区、工具权限、项目指令、审计轨迹和人工确认。

权限模型：Claude Code / Claude Agent SDK 支持通过 permission mode、allowed tools、settings、hooks 等方式控制工具调用。只读搜索、文件编辑、shell 命令、网络/API 调用不应该被放在同一风险等级里；企业部署时还要把"允许模型请求某个工具"和"运行时实际执行该工具"分开，由 hook、策略引擎或人工审批做最后判断。

上下文获取：通过"agentic search"主动探索项目结构，而不需要用户手动选择哪些文件要包含在上下文里。这和传统的"Ctrl+K 选区域"方式有本质区别——Claude Code 自己决定需要看什么。

扩展方式：通过 CLAUDE.md / AGENTS.md 等项目指令文件写入构建、测试、代码规范和禁区；通过 MCP 连接外部工具和数据源；通过 hooks 在工具调用前后插入确定性逻辑；通过 CI/CD 或 Agent SDK 把 Claude Code 嵌入自动化流程。

python

# Claude Agent SDK 的典型形态：把 Claude Code 能力嵌入自己的自动化流程
import asyncio
from claude_agent_sdk import ClaudeAgentOptions, query

async def main():
    options = ClaudeAgentOptions(
        allowed_tools=["Read", "Grep", "Edit", "Bash"],
        permission_mode="acceptEdits",
    )

    async for message in query(
        prompt="找到认证模块的 failing tests，修复最小必要代码，并说明验证结果",
        options=options,
    ):
        print(message)

asyncio.run(main())

OpenAI Codex：云端异步工程师

执行位置：ChatGPT / Codex CLI / 云端远程沙箱

Codex 的产品路线可以分成两类：一类是本地命令行里的 Codex CLI，另一类是 ChatGPT / Codex Cloud 里的云端异步工程任务。后者不是在你的本地环境里跑，而是在 OpenAI 的云端沙箱里跑。你把任务提交给 Codex，它在一个预装了你代码库的独立容器里工作（通常通过 GitHub 授权接入）——完成任务可能需要几分钟到更久，期间你可以去做其他事情。

OpenAI 在 2025 年 5 月发布 Codex 云端软件工程 Agent 时，强调它能在独立沙箱里理解代码、修改文件、运行测试并给出可审查结果。到 2026 年，产品形态已经扩展到 CLI、云端任务和更完整的工程工作流；因此不要把"codex-1"或某个发布日 benchmark 当作长期选型依据，选型时更应该验证你的仓库、测试、依赖和权限模型是否跑得通。

执行透明度：这是 Codex 设计中值得关注的一点。云端 Coding Agent 必须留下可审查轨迹：改了哪些文件、运行了哪些命令、测试输出是什么、关键结论引用了哪些文件或日志。这样用户才能在 merge PR 之前做有根据的代码审查，而不是盲目相信 AI。

安全隔离：Codex 的关键不是"永远不能联网"，而是把执行放进可配置沙箱里。联网、secret、依赖安装、仓库访问和分支写入都应该显式配置，并在企业环境里接入审批、审计和策略控制。默认更封闭的环境安全性更高，但会影响需要下载依赖、查外部文档或调用私有 API 的任务；开放网络则必须按第 20 章的工具权限原则做白名单和日志。

AGENTS.md / CLAUDE.md：越来越多 coding agent 支持在仓库根目录放 Agent 指令文件，说明测试怎么跑、代码规范是什么、哪些目录不要碰。它正在变成跨工具协作的实用约定，但不要只写口号；最有价值的是明确命令、约束和验收标准。

Cursor：IDE 里的自主权滑块

执行位置：本地 IDE + 云端 Background Agents

Cursor 的核心是渐进式自主权：同一个工具里，你既可以用它做精准的内联补全（Tab 模式），也可以做选区/文件级编辑，还可以把整个功能交给 Agent 模式，或者让 Background / Cloud Agent 在远程环境里跑任务。这种渐进式设计比"要么全手动要么全委托"的二元模式更符合工程师的实际工作习惯。

截至 2026.05，Cursor 这条路线值得关注的不是某个版本号，而是四个产品能力：

IDE 内上下文：当前文件、选区、diagnostics、最近修改、终端输出都能成为 Agent 的上下文。
多任务隔离：通过 worktree / background agent 等方式让多个任务互不干扰。
可视化审查：diff、计划、终端输出和中间步骤在 IDE 里可见，方便随时接管。
模型路由：支持多家模型供应商和自研编辑模型，但不同模型在 tool use、上下文、价格和数据策略上并不等价。

Cursor 的产品启发不是"IDE 里放一个聊天框"，而是给开发者一个自主权滑块：从补全、局部编辑、Agent 执行到后台委托，每一级都对应不同的风险和确认成本。

Devin：面向企业的委托式工程师

执行位置：云端（Cognition 托管的沙箱环境）

Devin 的目标群体不是个人开发者，而是有大规模重复性工程任务的企业团队。Cognition 在 2024 年 3 月发布时，用 SWE-bench 成绩建立了"AI 软件工程师"的产品叙事；但更能说明 Devin 定位的是企业迁移、重构、测试修复这类可拆分任务。

Cognition / Devin 披露过 Nubank 的大规模 ETL 迁移案例：数百万行代码、重复模式明显、验收标准相对清楚，适合多个 Agent 实例并行处理。官方案例给出了显著效率和成本改善，但它仍然是厂商披露的客户案例，不能直接外推到所有软件工程任务。

这个案例揭示了 Devin 的核心价值主张：大规模、高度重复、有明确模式但不可纯脚本化的任务，是 Devin 的甜区。

关键设计决策：

组织知识注入：通过历史任务、文档、代码规范、session 轨迹或定制训练，把团队内部习惯（命名规范、测试写法、目录结构）注入 Agent 行为。
Multi-agent fleet：对于大规模任务，可以同时起多个 Devin 实例并行处理子任务。
经验沉淀：把过去 session 的执行轨迹转成可复用知识，避免每个任务都从零探索。

适用边界：Devin 不是"随叫随到的 pair programmer"，它更像一个可以独立处理清晰规格任务的异步工程执行单元。对于需要频繁沟通、实时调整方向、强产品判断或深业务语境的任务，异步委托模式反而会增加返工成本。

四类产品的能力对比

维度	Claude Code	OpenAI Codex	Cursor	Devin
执行位置	本地 + 云端	云端（ChatGPT）	本地 IDE + 云端	云端（Cognition）
任务时长	分钟级（实时）	1-30 分钟（异步）	秒级（inline）/ 分钟级（agent）	小时级（长任务）
模型绑定	Claude 系列	OpenAI 系列	多供应商 + 自研	Claude + 其他
权限模型	tool allowlist + 确认 / hooks	沙箱 + 网络/secret 配置	IDE 权限 + 企业策略	企业权限管理
上下文获取	agentic search	GitHub 授权仓库	代码库索引	GitHub 集成 + 学习
适合场景	日常开发/自动化	批量任务/PR 工厂	IDE 内全程	大规模迁移/重构
集成方式	MCP/CLI/SDK	GitHub/CLI	内置 + SDK	GitHub/Slack/Linear

读这张表时要记住：这些不是能力高低排序，而是产品约束不同。本地/IDE 型产品更适合交互式开发和快速纠偏；云端异步产品更适合把清晰任务排队执行；企业委托型产品更看重权限、审计、批量调度和组织知识沉淀。

24.4 不是只有 Code Agent：其他重要 Agent 类型

Coding Agent 因为开发者能直接感知，所以曝光度最高。但从实际部署规模和商业价值来看，企业流程 Agent 的规模要大得多——只是大部分以 B2B SaaS 形式存在，开发者不太容易"感知"到。

Research Agent

做什么：从多个信息源搜集资料、交叉验证、综合生成报告。

OpenAI 的 Deep Research 和 Anthropic 的类似功能是这类产品的典型代表——给一个研究问题，Agent 自主搜索数十个来源，花几分钟到几十分钟生成带引用的分析报告。

工程挑战：

信源质量评估：Agent 怎么判断一个来源可信？
交叉验证：多个来源说法不一致时如何处理？
引用追踪：确保最终结论能追溯到原始来源（防止幻觉）
任务范围控制：避免"挖一个洞就往下无限挖"导致任务无法完成

Research Agent 和 RAG 的区别在于主动性：RAG 是被动检索已有知识库，Research Agent 会主动去搜索新信息、判断是否足够、决定是否需要继续。

Browser/Computer Use Agent

做什么：通过截图理解屏幕内容，通过鼠标键盘操作界面，完成本来需要人工操作 GUI 的任务。

核心技术是 VLM（Vision Language Model）+ 操作生成。Anthropic 在 2024 年 10 月发布了 Claude 3.5 Sonnet 的 Computer Use 功能，并用 OSWorld 等基准说明：模型已经能完成一部分真实 GUI 操作，但距离人类稳定性仍有明显差距。到 2026 年，OpenAI CUA、Anthropic Computer Use、Browser Use 等路线都在推进，但它们的共同现实仍然是：能演示，不等于能无人值守地跑生产关键流程。

为什么这条路线有价值：

世界上绝大多数软件没有 API。老系统（ERP、遗留 CRM、行政系统）、竞争对手网站、各种 SaaS 工具——你没办法让 Agent 直接调用 API，但可以让它"看着屏幕操作"。这把 AI 自动化的范围从"有 API 的世界"扩展到"所有人能用鼠标操作的世界"。

现实限制（截至 2026.05）：

速度慢：每一步都要截图 → 推理 → 生成操作，一个简单的表单填写可能需要几十次截图
错误率高：像素级定位不准确、弹窗处理、加载等待时机难以判断
成本高：大量图像 token 消耗
安全风险：间接 prompt injection 攻击（网页上的恶意内容可能欺骗 Agent）

Browser Use 开源库是这个方向的一个有趣补充——它把 Browser 操作抽象成 Agent 工具，让 LLM 通过结构化 API 操作浏览器，而不是纯截图模式，在常见任务上更稳定。

Workflow/Ops Agent

做什么：自动化 Jira 工单处理、Slack 消息路由、Email 回复起草、数据库查询、审批流触发。

这是企业 AI 自动化的主战场，也是目前最多"低代码/无代码"产品在竞争的领域。典型产品：Zapier AI（工作流自动化）、Make（前 Integromat）、n8n（开源自动化）的 AI 增强版本。

工程特点：这类 Agent 通常不需要深度推理能力，但对可靠性和幂等性要求极高——你不能让一个 Agent 重复发两封审批邮件，或者在系统重试时扣两次款项。第 16 章讨论的幂等键、去重表在这里是硬性要求。

Customer Support Agent

做什么：处理用户咨询、判断意图、查询订单状态、执行退款、处理投诉、必要时转人工。

Intercom 的 Fin 是这个类别的代表案例之一，Salesforce Agentforce、ServiceNow AI Agents、Zendesk、Freshworks 等也都在把客服/工单 Agent 产品化。这里的核心不只是"回答得像人"，而是能否在企业系统里安全地完成动作。

与普通 RAG 聊天机器人的区别：

早期的客服 bot 是纯检索 + 模板回复，遇到知识库里没有的问题就给"请联系人工客服"。现代的 Customer Support Agent 能：

主动调用工具查询用户账户状态
执行操作（退款、修改订单、重置密码）而不只是回答问题
根据对话历史判断用户情绪和优先级
在满足条件时自动升级到人工，并把上下文完整传递

关键工程挑战：如何设计"执行权限"和"质量闭环"。一个 Customer Support Agent 应该能执行多大权限的操作？退款 50 元可以自动执行，退款 5000 元要人工确认吗？高价值客户、投诉升级、监管行业用户是否必须转人工？这是产品决策，但需要工程架构来支撑（见第 12 章的 Calibrated Autonomy 设计）。

客服 Agent 上线前至少要评估四组指标：

解决率：自动解决了多少真实问题，而不是只看回答相似度。
误操作率：错误退款、错误改订单、错误承诺的比例。
升级质量：转人工时上下文是否完整、分类是否正确。
合规风险：是否泄露 PII、是否越权查询账户、是否给出不允许的承诺。

Data/Analytics Agent

做什么：理解自然语言查询 → 生成 SQL / Python 代码 → 执行查询 → 生成可视化和洞察报告。

Text-to-SQL 是这个方向最成熟的子任务，但 Analytics Agent 更进一步：它不只是翻译语言，而是能做多步分析（先找异常，再下钻原因，再给建议）。

典型产品形态：Databricks Assistant、Snowflake Cortex Analyst、各种 BI 工具的 AI 问答层。

常见失败模式：

SQL 幻觉：模型生成的 SQL 语法正确但逻辑错误（比如 JOIN 条件写错，结果不报错但数据全乱了）
Schema 漂移：数据库结构变了，但 Agent 的上下文还是旧的
权限混乱：Agent 能查的表和用户真实权限不一致

生产级 Analytics Agent 不能直接把自然语言丢给模型生成 SQL 就结束。更稳的设计是：先接入语义层或数据目录，限制可查询指标和维度；用只读、按用户下发的数据库凭证执行；对生成 SQL 做 lint、成本估算和 row-level security 检查；高风险查询先解释计划再执行；最终结果要带 SQL、数据时间范围、过滤条件和置信提示，方便用户复核。

Security/IT Agent

做什么：告警分诊（区分真假阳性）、日志排查、Runbook 自动执行、权限审计、漏洞修复建议。

这是 Agent 最晚进入但潜力最大的领域之一。安全事件的特点是：信息量极大（海量日志）、需要快速判断（告警来了 MTTR 越短越好）、但错误代价极高（误判可能导致生产中断或安全漏洞被忽视）。

CrowdStrike、Palo Alto Networks、Microsoft Security Copilot 等安全厂商都在把 AI Agent 集成到 SIEM/SOAR 工作流里。但安全 Agent 不能一上来就自动处置生产系统。更合理的演进路径是：

只读分诊：总结告警、聚合日志、推荐 runbook，不执行动作。
半自动处置：低风险动作自动执行，高风险动作需要审批。
闭环自动化：只对经过长期验证、可回滚、影响范围明确的 runbook 开放自动执行。

安全场景最怕的不是 Agent "不会做"，而是它在错误判断后太快地做完一串动作。限速、审批、blast radius 控制、回滚脚本和完整审计日志，比模型能力本身更重要。

24.5 如何做产品级选型

从代码到产品，Agent 选型要看的不只是"哪个模型更聪明"。

第一步：先定任务边界

不同任务需要完全不同的能力栈：

任务类型	核心能力需求	执行位置
代码生成/修复	代码理解、工具调用（bash/git）、长上下文	本地或云端隔离沙箱
网页/GUI 操作	视觉理解、操作生成、错误恢复	本地或远程桌面
研究报告	搜索、信源评估、综合生成	云端（需要网络访问）
客服处理	意图识别、知识库检索、系统集成	云端 API
数据分析	Text-to-SQL、执行环境、可视化	云端（数据库连接）
流程自动化	工具集成、幂等执行、审批流	云端 + 企业内网

不要用 coding agent 做客服，不要用客服 agent 做代码审查——听起来显而易见，但在实际选型中，"我们已经有 Copilot 了，能不能用它做一下问题路由"这种需求非常常见。

第二步：确认执行位置

执行位置决定了数据安全边界、延迟、成本和集成难度：

本地执行的优势：代码不离开机器、延迟低、与本地工具链集成天然。代价：计算资源占用本地 CPU/内存，长任务会阻塞工作流。

云端异步执行的优势：任务可以并行、长任务不占用本地资源、有完整的执行记录。代价：代码需要上传到供应商云端（数据安全合规要评估）、网络延迟、冷启动时间。

第三步：评估治理要求

这是大公司和小团队最大的分野。

小团队的考虑：准不准、快不快、好不好用。

大公司的考虑（必须回答的问题）：

审计日志：Agent 做了什么？谁触发的？改了哪些文件？
权限控制：Agent 能访问哪些仓库、哪些数据库、哪些 API？能不能细粒度到"只能读 prod，不能写 prod"？
审批流：高风险操作（push 到 main branch、调用生产 API）要不要走人工审批？
成本可见性：每个团队、每个项目的 AI 使用成本是多少？有没有限额？
数据驻留：代码和数据是否可以离开特定地理区域（GDPR、数据主权）？

这些问题大多数开源框架不会帮你解决，但很多企业级产品（Devin Enterprise、Cursor Enterprise、GitHub Copilot Enterprise）会提供 SSO、SAML、审计日志、权限策略等企业功能。如果你的公司有 SOC 2 或 ISO 27001 要求，这些不是加分项，而是入门票。

第四步：用真实任务做产品 PoC

Agent 产品的 demo 往往很漂亮，但 demo 不等于生产价值。产品级 PoC 应该用真实任务、真实权限和真实验收标准。

PoC 维度	要回答的问题
成功率	20-50 个真实任务里，多少能一次完成？多少需要人类接管？
可审查性	用户能否看懂 Agent 为什么这样改、查、发、删？
权限边界	Agent 是否只能访问当前用户有权访问的数据和工具？
失败恢复	中途失败后能否从失败点继续，而不是重跑整个任务？
单任务成本	模型 token、工具调用、沙箱时长、人工审查加起来是否划算？
组织适配	是否接入 SSO、审计、数据驻留、保留期限和法务要求？

特别要警惕两种假阳性：一种是 demo 任务太简单，Agent 看起来很强；另一种是人类 reviewer 花了大量时间擦屁股，但成本没有计入 ROI。产品选型要算的是端到端单位经济，而不是模型回答本身。

24.6 Agent 产品 UX 设计

技术架构之外，Agent 产品的用户体验设计有一套自己的原则。这些原则在框架文档里很少提到，但它们决定了用户实际上会不会用你的 Agent，以及用完之后会不会信任它。

长任务的信任建立

人和 Agent 之间的信任建立，不是靠一次成功完成任务，而是靠持续的透明度。

进度反馈：不是一个转圈圈的 loading，而是实时的行动流。比如显示正在搜索哪些文件、执行了哪些命令、跑了哪些测试、下一步计划是什么。这不是装饰，是建立信任的必要条件——用户需要随时知道 Agent 在干什么，才能判断要不要干预。

中间产物可见：如果任务需要 20 分钟，用户希望在 5 分钟的时候能看到中间状态，而不是等 20 分钟出来一个结果发现方向跑偏了。

可暂停/可取消/可接管：任何时候用户觉得 Agent 方向错了，应该能叫停或者接管。这不是边缘功能，是 Agent 产品的基础安全网。

用户纠偏机制

Agent 会出错。好的产品设计让纠偏变得自然，而不是让用户感觉像在调试系统。

自然语言补充：用户应该能用普通话说"等等，不对，这里应该是用 TypeScript 不是 JavaScript"来修正 Agent 的方向，而不是去找配置文件改参数。

计划编辑：对于有明确规划阶段的 Agent（Plan-and-Execute），让用户在执行前看到并修改计划，是降低后期返工成本的关键设计。

审批备注：如果 Agent 需要人工审批某个操作，用户应该能在批准或拒绝的同时加备注说明原因，这个备注理想情况下应该进入 Agent 的上下文。

失败体验设计

Agent 失败的时候，用户体验有两种截然不同的处理方式：

差的处理：显示一条"发生了错误，请重试"，用户不知道发生了什么，也不知道怎么解决。

好的处理：把失败变成一个可解释的状态：

说清楚在哪一步失败了（"在运行测试 test_user_auth.py 时出现断言错误"）
展示失败时的具体输出（错误信息、堆栈、相关日志）
给出可操作的建议（"可以尝试提供测试数据库的连接信息，或者点击跳过测试直接查看代码变更"）
保存任务状态，让用户能够从失败点继续而不是从零开始

这是第 16 章 Durable Execution 在产品层面的表现——技术上是检查点和恢复机制，体验上是"失败了也不会全部丢失"的安全感。

不同自主等级的 UI 差异

这四种模式不是产品设计师拍脑袋定的——它们对应了不同的风险级别和任务特征：

建议模式：风险低但可逆的任务（代码补全、拼写检查）
草稿模式：需要用户把关内容质量的任务（PR 描述、邮件回复）
执行后通知：风险低且可验证的任务（运行测试、生成文档）
执行前审批：不可逆或高风险的任务（push 到 main、发送邮件给客户、扣款）

真正做得好的 Agent 产品，会让不同操作自动对应不同的确认级别，而不是全程都要用户点确认（这会让 Agent 失去价值），也不是所有操作都自动执行（这会让用户失去控制感）。

24.7 面试题解析

面试高频题：Claude Code、Cursor、Codex、Devin 分别代表什么产品路线？为什么说 Agent 不等于 code agent？

参考答案框架：

四种产品代表四种设计哲学：

Claude Code：终端原生 + 多面统一的 agentic loop，强调本地执行和细粒度权限控制，通过 CLAUDE.md 和 MCP 扩展能力
Cursor：IDE 原生 + 渐进式自主权（Tab/Cmd+K/Agent/Background），强调上下文感知和模型路由灵活性
OpenAI Codex：CLI + 云端异步工程任务，强调沙箱执行、可审查轨迹和与人类 PR 流程对齐
Devin：企业委托 + 长任务自主，强调组织知识沉淀、批量任务调度和企业治理

"Agent 不等于 code agent"的论点：

使用面：企业流程 Agent（客服、审批、工单）触达的是业务人员和客户，不只是开发者
能力栈：不同类型 Agent 需要完全不同的能力（coding agent 需要代码执行沙箱，research agent 需要网络访问，客服 agent 需要业务系统集成）
商业价值：很多行业（法律、医疗、金融）的 Agent 落地发生在"没有代码"的业务流程里
技术挑战各异：browser/computer use agent 的核心挑战是视觉理解和错误恢复，跟 coding agent 的 context management 完全不同

加分点：

指出执行位置（本地/云端）是 coding agent 选型的核心维度之一，而不只是模型能力
提到 AGENTS.md / CLAUDE.md 这类项目指令文件正在成为 coding agent 协作约定
分析 Computer Use 的能力现状：演示价值很高，但速度、成本、错误恢复和安全边界仍是生产瓶颈
指出企业 Agent 的 UX 设计挑战（信任建立、自主等级分层、失败体验）与技术架构挑战同等重要

参考资料

[1] Claude Code 官方文档 - Anthropic (https://code.claude.com/docs/en/overview)

[2] Claude Code 产品页 - Anthropic (https://claude.com/product/claude-code)

[3] Introducing Codex - OpenAI, 2025.05.16 (https://openai.com/index/introducing-codex)

[4] Introducing Devin, the first AI software engineer - Cognition/Scott Wu, 2024.03.12 (https://cognition.ai/blog/introducing-devin)

[5] Devin + Nubank 案例：How Nubank refactors millions of lines of code - Cognition (https://devin.ai/)

[6] Cursor Features - Anysphere (https://cursor.com/features)

[7] Cursor Changelog - Anysphere (https://cursor.com/changelog)

[8] Developing a computer use model - Anthropic, 2024.10.22 (https://www.anthropic.com/news/developing-computer-use)

[9] Claude Agent SDK 官方文档 - Anthropic (https://code.claude.com/docs/en/agent-sdk)

[10] Browser Use 官方文档 (https://docs.browser-use.com/)

[11] OpenAI Computer-Using Agent 文档 (https://platform.openai.com/docs/guides/tools-computer-use)

[12] Intercom Fin 产品页 (https://www.intercom.com/fin)

第24章：主流 Agent 产品形态与垂直场景分析 ​

24.1 为什么要拆解 Agent 产品 ​

24.2 五种典型产品路线 ​

24.3 主流 Coding Agent 产品拆解 ​

Claude Code：终端里的 Agent 循环 ​

OpenAI Codex：云端异步工程师 ​

Cursor：IDE 里的自主权滑块 ​

Devin：面向企业的委托式工程师 ​

四类产品的能力对比 ​

24.4 不是只有 Code Agent：其他重要 Agent 类型 ​

Research Agent ​

Browser/Computer Use Agent ​

Workflow/Ops Agent ​

Customer Support Agent ​

Data/Analytics Agent ​

Security/IT Agent ​

24.5 如何做产品级选型 ​

第一步：先定任务边界 ​

第二步：确认执行位置 ​

第三步：评估治理要求 ​

第四步：用真实任务做产品 PoC ​

24.6 Agent 产品 UX 设计 ​

长任务的信任建立 ​

用户纠偏机制 ​

失败体验设计 ​

不同自主等级的 UI 差异 ​

24.7 面试题解析 ​

参考资料 ​