Agent 产品分类：两个维度，推出整套技术选型

一个 agent 产品的本质，是它替谁、负责多大范围的事。把这两件事想清楚，运行时、记忆、Skill、Tool、身份与凭证该怎么选，基本都能推出来。

Claude Code、Codex、Manus、OpenClaw、dots、Claude Duet、Fin、AWS DevOps Agent，都叫 agent，技术栈却差得很远。有的跑在你笔记本的沙箱里，有的常驻在云上一台属于它自己的电脑里；有的用你的 git 账号，有的有自己的身份。

分类即理解。几种常见分法都站不住：

• 按服务人数分：Claude Code 服务几百万人，但每次运行只代表一个人。
• 按模型分：换模型不换架构。
• 按执行环境分：Codex 既有本地 CLI 又有云端形态，环境是部署选择，不是产品属性。

本文只用两个纯产品维度给 agent 产品分类，再从这两个维度推导技术选型，最后用五个典型产品和四个云平台来验证。

一、定义：两个维度，六个格子

一个 agent 产品的核心承诺，可以写成一句话：替【谁】负责【多大范围】的事。两个空，就是两个维度：责任归属和责任范围。它们都能从产品定位里直接看出来，不需要知道它怎么实现。

维度一：责任归属（对谁负责）

判断看三个问题：谁给它定能力边界，它用谁的身份，出了错谁来担。

这里问的是“对谁负责”，不是“谁在用”。一个团队都在用 Codex，仍是每个人自己派活、自己验收，所以它代表个人。报销 agent 属于财务部门，却要借员工的授权去查他自己的报销单，这就是交叉型。

维度二：责任范围（负责多大的事）

判断只看一个问题：下一件事由谁决定。

运行时长不是标准。跑几天的大任务仍是任务型；每天只运行几分钟、但自己决定做什么的，是职责型。“主动”也不是标准。OpenAI 说 Automations 让 Codex 变得主动，到点自己回来干活；但它重复的是人事先定好的事，仍是任务型，只是多了调度（OpenAI Academy）。

六格定义

推导逻辑：归属管边界，范围管时间

每一项技术选型，都由两个因子共同决定：归属决定它的边界，范围决定它的时间。

两个因子一组合，就是六个格子各自的选型。第三节逐格展开。至于 agent 操作什么对象（代码、网页、业务系统），它决定的是接哪些工具、沙箱要多重，属于同一格内的垂直细分。

二、典型产品矩阵

把主流产品放进六个格子，有四个现象值得注意。

同一格里的产品互为直接竞品。Claude Code、Codex、Cursor 在抢同一类开发者；Fin 的对手正是 Sierra、Decagon 这类按解决量收费的客服 agent（Voiceflow）。Kiro autonomous agent 和 AWS Security Agent 的渗透测试都能连续工作数小时到数天，但每次干什么由人指派，仍归任务型。

头部公司两列各做一个产品，并让职责型给任务型派活。OpenAI 的 dot 可以在你连接的电脑上创建 Codex 任务、接着推进本地 Codex 任务，也能用你建好的 Codex 云环境（SessionWatcher）。Anthropic 的 Claude Duet 直接继承 Claude 账户里的记忆、skills 和已连接的应用（iPhone in Canada），并与 Claude Code 共用用量额度（Ecosistema Startup）；目前公开信息里还没有 Duet 给 Claude Code 派活的说法。结构已经很清楚：职责型统筹，任务型执行。

计费单位印证了分类。个人产品按订阅收费；Fin 按每次解决收 0.99 美元（Activepieces）；据报道 AWS DevOps Agent 做 SRE 工作约每小时 30 美元（Enterprise DNA）。工具按人头，服务按结果，员工按工时。

交叉 × 职责基本空白。这一格要同时做到三件事：长期有效的个人委托授权、在组织系统里为每个用户保存长期档案、主动联系用户。三者叠加，合规成本最高，这也是平台方最值得布局的空位。

三、技术选型推导

五项技术选型在六个格子里各不相同。下面两张表横着读是归属的影响，竖着读是范围的影响；最后一行的难题，单看任何一根轴都推不出来。

任务型的三个格子

职责型的三个格子

两个最能体现组合的技术点

身份与凭证：来源由归属决定（本人、委托、agent 自有），有效期由范围决定（随任务失效、长期持有）。六个格子正好对应 3 × 2 种凭证形态，没有一种能通用。

Tool：关键不在“接了哪些工具”，而在“以谁的权限、以什么节奏调用”。任务型是一次性调用；职责型要订阅和监听，工具本身就是它的事件来源。

四、运行时专题

运行时是两根轴叠加最深的地方。任务型以“任务”为生命周期单位；职责型以“职责”为单位，但计算是间歇的：身份、状态、环境常驻，计算按需唤醒。

六格运行时画像

4.1 运行时长：职责型是“逻辑常驻、物理间歇”

任务型的时长由任务决定。长任务要做到三点：能中断、能续跑、能封顶。AWS Security Agent 允许给一次渗透测试设任务时长上限，到上限时平稳停止，并保留已经找到的问题（AWS）。

职责型的时长由职责决定，但没有哪家真让模型一直跑。Claude Duet 每隔几个小时检查一次已连接的账户，因为持续检查会更快耗光套餐额度（Ecosistema Startup）；dot 在空闲时做主动研究（The Telegraph India）。职责型运行时的设计目标因此是：身份、状态、环境常驻，计算按事件或节奏唤醒。

4.2 起停与恢复：三类状态分开持久化

agent 停下来再起来，要恢复三样东西，它们的持久化方式各不相同：

1. 推理上下文：对话历史、计划、进度。存在会话存储里，恢复时重新装载并压缩。
2. 工作区：文件系统、已安装的依赖、浏览器状态。用快照恢复；AgentCore Runtime 就支持在会话停止和恢复之间保留文件系统状态（AWS）。
3. 外部副作用：已经发出的消息、已经提交的变更。快照管不了它，要靠“先记意图、再执行、后确认”的日志加幂等键，防止恢复后重复发送、重复付款。

职责型还要多一步：唤醒后先对账。挂起期间外部世界已经变了，邮件可能被别人回了，工单可能被人关了，不能按挂起前的计划直接往下做。

4.3 并发：五种不同的压力曲线

• 个人 × 任务：一个人同时开好几个任务，瓶颈在沙箱密度和冷启动，常用预热池和镜像缓存。
• 交叉 × 任务：大量用户同时涌向同一个 agent。运行时必须无状态、横向扩展，并按用户限流，保护下游业务系统。
• 组织 × 任务：随事件起伏，比如 PR 高峰。用队列削峰；同一个 PR 有新提交时，取消旧的运行。
• 个人 × 职责：海量 agent，大多数时间在等。可以大比例超售，事件到达再唤醒；每个 agent 要有自己的预算上限。
• 组织 × 职责：平时安静，告警风暴时突发。同一根因的告警合并成一次调查，对共享状态的写入要加锁。

4.4 隔离：计算、数据、权限三层

• 计算隔离：本地形态用操作系统原语。Claude Code 在 macOS 上用 Seatbelt、在 Linux 上用 bubblewrap，同时限制文件系统和网络（Claude Code 文档）。托管形态用容器或 microVM，AgentCore 给每个用户会话一个独立的 microVM，会话结束后整机销毁并清理内存（AWS）。
• 数据隔离：记忆、文件、缓存按用户或租户分区。交叉型最容易出事：同一个 agent 服务很多人，缓存和共享记忆都可能串。
• 权限隔离：凭证不进沙箱。Claude Managed Agents 的环境变量类凭证在沙箱里只是占位符，出站请求时才替换成真实值，agent 看不到密钥（Claude 文档）。身份参数也不让模型填，由网关从已认证的会话里绑定。
• 职责型的额外要求：环境长期存在，风险会累积，需要定期重建环境、轮换凭证。

4.5 成本：职责型最硬的工程约束

任务型的成本跟着任务走，按次算即可。职责型的成本和“盯得多紧”成正比：巡检越频繁，越接近实时，也越贵。所以职责型运行时要把“什么时候值得醒”做成一等能力：事件推送优先于轮询，轻量模型先做初筛，重模型只在需要时上场。

五、典型产品的技术推导

五个产品分别落在五个格子里。先用分类推出它应该怎么做，再对照它实际怎么做。

5.1 Claude Code：代表个人 × 任务型

开发者把一件开发任务交给它，它用开发者本人的身份把事做完。分类推出的重心是：运行时要轻，安全要保护用户自己的机器。

• 运行时：本地进程，沙箱用操作系统原语，macOS 上是 Seatbelt，Linux 上是 bubblewrap，同时限制文件和网络。文档特别指出，没有网络隔离，被攻破的 agent 就能把 SSH 密钥这类文件发出去（Claude Code 文档）。
• 身份与凭证：直接继承本机的 git 和云平台凭证，这正是沙箱重点放在“保护用户机器”的原因。
• 记忆：项目里的 CLAUDE.md 等说明文件，跟着仓库走，可以共享、可以评审。
• Skill：放在本地目录，先只加载描述，用到时再读全文。
• Tool：内置文件和 Shell 工具，加上用户自己配置的 MCP；需要并行时开子 agent。

同一个引擎放进 CI、换成服务账号，就搬到了“代表组织 × 任务型”，技术栈跟着变，这就是 5.4。

5.2 Meta Muse：代表个人 × 职责型

Muse 于 9 月 8 日在美国发布，可以发邮件、订行程、填表、购物，并围绕长期目标持续推进（iClarified）。分类推出的难题是：常驻、拿着私人凭证、又持续接触不可信内容。Muse 的答案几乎逐条对应：

• 运行时：每个用户一台专属云端虚拟机 Muse Secure VM，带独立的浏览器、存储和算力，其他用户的 agent 访问不到（VKTR）；关掉 App 后它仍在后台工作（The Rundown）。
• 身份与凭证：凭证放在 agent 读不到的安全存储里（Let's Data Science）。
• 隔离：另有一个 Sentinel agent，和 Muse 在系统层面隔离，Muse 发往互联网的一切都要经它审核；发邮件、付款等敏感动作要用户批准（iClarified）。
• 记忆与任务管理：Goals 标签页管理长期项目的计划和进度，Ideas 标签页给出主动建议；审计轨迹覆盖已执行和计划执行的动作（Let's Data Science）。
• 架构来源：Meta 参照开源框架 OpenClaw 来构建底层系统（BetaNews）。

最值得借鉴的是 Sentinel：它用一个独立的守门 agent，把“不可信输入驱动高权限动作”这个难题和干活的 agent 拆开了。

5.3 报销 agent：交叉 × 任务型

它属于财务部门，替员工办一件报销。分类推出的核心是：一次会话里要频繁切换身份，而切换必须由配置和网关决定，不能由模型决定。

• 身份与凭证：按动作拆开。查政策、发票验真用 agent 的服务身份；查“我的”报销单和公司卡流水、以员工名义提交，用员工委托。委托用 OAuth 2.0 Token Exchange（RFC 8693）换一张短期票：sub 是员工，act 是 agent，范围收窄、绑定受众。有效权限 = 员工 ∩ agent ∩ 本次任务。
• Tool：MCP server 按身份拆开，员工数据一个，财务规则一个。工具签名里不出现 employee_id，由网关从已认证的会话里绑定。
• 运行时：无状态的会话服务，不需要代码沙箱；月初月末扇入高，按用户限流。
• 隔离：服务账号能看全公司的数据，但员工的问题只走委托票。合规审核交给规则引擎或独立 agent，只看结构化的报销单，不看聊天记录，防止“VP 已经口头批准”这类注入。
• 记忆：每个员工的记录彼此隔离；“最常见的驳回原因”这类经验，去标识后才进共享层。
• 审计：双主体日志。员工对内容真实性负责，提交前的显式确认就是他的签字；财务对规则和审核结果负责。

5.4 CI review bot：代表组织 × 任务型

PR 一提交就自动审查，结果以评论的形式回到 PR。它代表的是团队的代码规范，不是某个开发者。分类推出的难题是：高权限和不可信输入同时出现。

• 运行时：PR 事件触发，在临时 CI runner 里运行，结束即销毁；同一个 PR 有新提交时，取消旧的运行。
• 身份与凭证：用 bot 或 App 自己的身份，令牌按次签发，只给读代码、写评论的权限，不给合并权限。
• 隔离：PR 的描述和代码注释里都可能藏着注入指令，所以对外部 fork 的 PR 不暴露密钥，出网走白名单。GitHub 的 Copilot coding agent 默认就用防火墙限制联网，并提醒关掉防火墙会增加代码和敏感信息外泄的风险（GitHub 文档）。
• 记忆：团队规范写在仓库的说明文件里，和代码一起版本化、一起评审。
• Skill 与 Tool：审查规则和工具集随仓库或流水线发布，以只读工具为主。

5.5 Specialist dot：代表组织 × 职责型

OpenAI 在发布 dots 时预览了组织专属的 specialist dot，内部测试覆盖采购、发票处理、邮件营销、客服和商务合同（IT Brief）。分类推出的诉求，简单说就是一套“人事制度”。

• 身份与凭证：每个 specialist dot 有自己的身份、凭证和系统权限，由雇主设定（IT Brief）。
• 治理：组织定义它的职责、工具权限和审批流程；OpenAI 还在和微软合作，把它纳入 Microsoft Agent 365 的治理和安全管控（IT Brief）。
• 运行时：dot 有自己的云电脑和浏览器，空闲时做主动研究（The Telegraph India）。可能影响账户或对外共享信息的动作会先经过自动审查；监控系统发现安全问题时可以暂停或停止 dot（BetaNews）。
• 记忆：dots 会从反馈中学习，并在不同渠道间保持上下文（IT Brief）。

对照一下就能看出来：岗位定义、身份开通、权限、审批、审计、随时停职，数字员工需要的正是企业管人的那套东西。

六、云平台如何支撑这张矩阵

四个平台都不是 agent 产品，而是给 agent 产品用的底座。用矩阵去读它们，看的是：哪些格子的诉求已经有现成原语，哪些还要自己补。

6.1 AWS Bedrock AgentCore

AgentCore 提供 Runtime、Gateway、Policy、Identity、Memory、Observability、Evaluations、Browser、Code Interpreter，可以单独或组合使用（AWS 定价页）。

• 运行时：每个用户会话一个独立 microVM，会话结束后销毁并清理内存；文件系统状态可以跨停止和恢复保留（AWS 文档）。单个会话最长 8 小时（Tech Jack Solutions 整理的 AWS FAQ）。
• 身份与凭证：出站认证分“代表用户”和“自主”两种模式（AWS 文档）；发布说明里已有 on-behalf-of token exchange 的文档（AWS 发布说明）。
• 记忆：短期记忆加跨会话的长期记忆，并新增了让 agent 从过往经验中学习的 episodic 策略（AWS News Blog）。
• 治理：Policy 已于 2026 年 3 月正式发布，关联到 Gateway 上约束 agent 的动作，规则可以用自然语言描述（AWS News Blog）。
• 要自己补的：AgentCore 不替你强制会话与用户的对应关系，要求从已认证的主体推导用户 ID（AWS 安全最佳实践）。

6.2 阿里云 Agent Core

阿里云在 9 月 22 日的杭州云栖大会上发布了 Agent 构建治理平台 Agent Core，同期发布的还有 Agent Sandbox 等新品，并把 Model、Harness、Context 作为 Agentic Cloud 的三个核心场景（上海证券报）。从公开信息看，它的重心在治理和上下文，正对矩阵里“代表组织”那一行。

• 定位：覆盖 agent 全生命周期的构建与管理平台，企业可以管控人与 agent 怎么协作，并持续监控 agent 的表现（CRN Asia）。
• 治理与安全：安全内嵌在运行层；配套的 Agent Security Center 负责 agent 应用全生命周期的安全与合规，用实时威胁检测把 agent 约束在设定的边界内（CRN Asia）。
• 记忆：Agent Context 把企业文档、业务系统、聊天记录和多模态数据连起来，让 agent 记住过去的任务、在团队之间共享知识；阿里云称在客服、AI 编程等知识密集场景最多可减少 67% 的 token（CRN Asia）。
• 身份：阿里云把“安全、控制、信任和身份认证”列为企业级 agent 落地的四大支柱之一，目标是人与 agent、agent 与 agent 之间的可信协作（上海证券报）。
• 运行时：据第三方解读，运行层负责 agent 的创建、调度、扩缩和回收，支持跨会话持续运行的长时 agent；治理侧包括权限范围、审计日志、PII 脱敏和平台级策略，可以在设定的决策阈值要求人工介入（Institute of AI PM）。

隔离单元、凭证托管这些运行时细节，官方披露还不多，值得继续关注 Agent Sandbox 的后续文档。

6.3 火山引擎 AgentKit

AgentKit 由 Runtime、Tools、Memory、Knowledge、MCP 等模块组成，可以单独或组合使用（PyPI）。下面的能力取自 BytePlus 版产品文档目录（BytePlus 文档）。

• 运行时与沙箱：沙箱模板包括代码和浏览器合一的 AIO 沙箱、Skills 沙箱，以及可以接入消息渠道的 ArkClaw Sandbox；沙箱实例可以设生命周期时长、用快照备份和恢复；会话可以暂停、恢复、设置 TTL。
• 身份与凭证：Agent Identity 提供用户池与企业 IdP 联合、为 agent 和工具分配工作负载身份、加密托管第三方凭据、基于属性和上下文的动态授权（VeADK 文档）。出站支持 API Key、OAuth2 M2M 和 OAuth2 用户委托；用户委托需要用户首次授权（VeADK 文档）。
• Skill：Skills 中心有 skill 空间和版本管理，并对 skill 做质量检查和安全扫描。
• Tool 与网关：可以把 REST/OpenAPI 或现有 MCP Server 接入网关，带入站身份认证；另有 A2A 中心做 agent 注册和语义检索。
• 记忆：长期记忆的检索策略可以配置。

Skill 的质量检查和安全扫描，正对应第三节里“托管后用户自装 skill 落在多租户环境”的难题。

6.4 Claude Managed Agents

MA 围绕 Agent、Environment、Session、Events 四个概念构建，环境可以是 Anthropic 托管的云沙箱，也可以是自托管沙箱（Claude 文档）。

• 运行时：会话有状态、可长时间运行，暂停后可以干净地恢复，对话历史、沙箱状态和产出都存在服务端；还支持按 cron 定时运行的 scheduled deployments（Claude 文档）。
• 身份与凭证：vault 是一个终端用户的凭证集合，在创建会话时引用，产品按 agent 粒度管理、用户按 session 粒度管理；MCP 凭证按 server 地址自动注入，环境变量凭证在出站时才替换，agent 看不到密钥（Claude 文档）。
• 记忆：memory store 之外还有 dreaming：定期回看记忆库和最多 100 个历史会话，生成一个重新整理的记忆库，可以自动应用，也可以先审再用（Let's Data Science）。
• 多 agent：lead agent 把任务拆开，派给各自有模型、提示词和工具的专家 agent（9to5Mac）。
• 要自己补的：vault 是 workspace 级的，同一 workspace 里任何 API key 都能引用，“这个会话属于哪个用户”要由后端保证（Claude 文档）。

按报道，Claude Duet 也沿用了 MA 的凭证设计，系统不直接接触密码和令牌（WWWhat's new）。

四个平台对照

一句话结论：任务型的隔离和交叉型的代用户凭证，多数平台已经有了原语；阿里云 Agent Core 把重心放在组织型需要的治理和共享记忆上。真正拉开差距的是职责型，也就是“怎么以接近零的闲置成本常驻、又能随时醒来”。

结语

分类给出的不是标签，而是一条推导链：产品承诺（替谁、负责多大）→ 能力要求 → 技术选型。归属管边界，范围管时间。拿到一个新的 agent 产品，先问这两个问题，它该怎么做沙箱、怎么管凭证、怎么存记忆，大致就有了答案。

这张矩阵也标出了三个还没有被填满的地方：

1. 会话属于谁：平台提供了代用户凭证的原语，但“这个会话属于哪个用户”的绑定仍留给开发者，AgentCore 和 MA 的文档都说得很明白。
2. 交叉 × 职责：长期有效的个人委托授权还没有成熟做法，矩阵里这一格几乎空着。
3. 职责型运行时：逻辑常驻、物理间歇，如何在闲置成本和响应速度之间取舍，是下一阶段平台竞争的关键。

参考资料

• Codex Automations（OpenAI Academy）
• Claude Code sandboxing（Claude Code 文档）
• Claude Managed Agents overview；Authenticate with vaults
• Anthropic adds dreaming to Claude Managed Agents（Let's Data Science）；9to5Mac
• Claude Duet（iPhone in Canada）；Ecosistema Startup；WWWhat's new
• dots 与 Codex 任务（SessionWatcher）；IT Brief（always-on agents）；IT Brief（specialist dots）；BetaNews；The Telegraph India
• Meta Muse（iClarified）；VKTR；The Rundown；Let's Data Science；BetaNews
• Kiro autonomous agent；AWS Security Agent 按需渗透测试；AWS Security Agent 预算控制
• Intercom 定价（Activepieces）；Voiceflow
• AWS frontier agents 定价（Enterprise DNA）
• Copilot coding agent 防火墙（GitHub 文档）
• AgentCore Runtime；安全最佳实践；定价页；发布说明；AWS News Blog；Tech Jack Solutions
• 阿里云发布 Agent Core（上海证券报）；CRN Asia；Institute of AI PM
• AgentKit SDK（PyPI）；AgentKit 文档（BytePlus）；Agent Identity（VeADK）；OAuth2 用户委托（VeADK）