10款AI智能体工作平台拆解：你的Agent该在哪里干活？

当AI编程进入"智能体时代"，开发者面临的核心问题已经从"用哪个模型写代码"，转向了一个更结构性的命题：你的智能体（Agent）应该在哪里工作？移交任务后，又有什么东西能真正存活下来？

YouTube频道Flywheel的主播Tali在这期深度拆解中，用一套统一的测试标准——控制权、运行位置、持久性、总成本与证据——对10款AI智能体工作平台进行了逐一审视。她强调自己的原则是"读它们实际提交的东西，而不是台上的宣传"。本文梳理这份"按架构分层"的测评地图，帮助你在为下一个智能体工具付费前想清楚：真正缺失的能力到底是什么。

四种起点：谁来托管你的智能体？

这期测评的核心洞察在于：市面上的集成环境看似相似，实则在"工作从哪里开始"这个问题上做出了四种完全不同的选择，而起点本身就是锁定（lock-in）。

Cursor 把编辑器放在中心。文件、语言服务器、远程访问、代码审查和多模型能力都聚合在一起，采用订阅制，云端智能体的工作则从套餐额度中扣除。它适合那些希望"编辑器始终是控制面"的开发者——即使工作迁移到云端，操控权依然留在熟悉的IDE里。

Cognition（Devin） 则从另一个前提出发：开发者正在从"与单个智能体结对编程"转变为"管理本地与云端智能体的经理"。Tali引用其观点——最优秀的工程师不再是一次只盯着一个agent，而是在划定范围、规划任务、委派给云端agent、审查进度并决定什么能上线。Devin Desktop（即原Windsurf IDE的更名版本）是本地与云端智能体的指挥中心，而Devin本身则是运行在托管开发环境中的云端worker。两者相邻，却分属不同的架构层：一个执行被委派的backlog工作，另一个是你用来操控和审查的地方。

Replit Agent 打包的是另一端：提示词、应用、数据库、认证、托管与部署。它的定位是"从想法到可运行应用"的完整工作流，无需在本地拼装基础设施。其关键优势在于——智能体能使用与人类开发者完全相同的托管服务，可以创建数据库、连接前后端，甚至帮你部署全栈应用。订阅解锁入口，但真正的成本由effort credits（工作量积分）决定。

Kiro 把起点又往前挪了一步，将需求与可复用任务置于代码生成之前。这是亚马逊推出的"需求优先"工作区，横跨IDE、命令行和Web。它能读取代码库、编写生产级代码、运行自动化质量检查、连接数据库，一切配置都可通过Git在团队间共享。它适合那些想要规范（specs）、钩子（hooks）、自定义智能体与组织级对齐的团队。

这四款产品并非同一个编辑器的四个版本：Cursor以开发环境为中心，Devin以委派为中心，Replit以运行中的应用为中心，Kiro以规范为中心。你的工作从哪里开始，决定了你被锁定在哪里。

**锁定（Lock-in）**在这里有具体的技术含义：当你的工作流、配置文件、权限体系和历史上下文都沉积在某个平台的特定格式或私有存储中，迁移的摩擦成本就会让切换在实际上变得不可行。对于AI编程工具来说，锁定的粒度比传统SaaS更细——不只是数据格式，还包括智能体对代码库的"记忆"（如项目级规则、自定义指令）、积累的工作流脚本，以及团队成员已经内化的操作习惯。选择"起点"时，值得提前问清楚：如果三个月后要换平台，哪些东西可以随Git一起带走，哪些只能留在那个平台里？

注意力编排：当终端标签变成"座位表"

Tali指出，第五类失败往往在智能体干完活之后才浮现——最先崩溃的是你的注意力。当并行的终端标签多到像一张座位表，等待和审查本身就成了可被量化的工作。

这一层的工具（herder、Orca、cmux、ccmux）并不取代编程智能体，它们负责组织会话、终端、工作树（work tree）、依赖关系和通知。

herder 把三个agent终端变成一个你能真正监督的队列。它能告诉你某个agent何时需要输入、何时就绪、何时被阻塞。借助后台服务器，会话在断连后依然存活，等待状态变成队列，操作者可以跨机器重新连接。本地运行时免费，云端定价未公开。

Orca 以代码仓库和工作树为中心，组合了隔离工作区、受管终端、可见的diff、技能、自动化、计算机操作与受监督的协调。它的理念是：每个任务都应有自己隔离的空间——自己的文件、自己的分支、自己的终端，agent们并行运行却互不干扰，完成后保留成果继续推进。工作树是产品的边界，而非实现细节。公开定价暂缺。

cmux 从终端本身切入，是一个为多任务编程智能体打造的原生Mac终端，带有智能体工作区、通知、浏览器面板、Socket API和可选云端机器。本地终端免费且开源。你可以在分屏面板里嵌入浏览器（基于WebView Safari），当Claude停止时左侧会即时弹出提醒。

ccmux 则做了相反的选择：它不替换终端，而是观察已经运行在tmux中的agent，追踪等待状态、预览面板、管理移交。一个是重建终端界面（cmux），一个是适配你已有的终端（ccmux）——这是注意力编排层里两种截然不同的哲学。

**工作树（Work Tree）**是Git的一项内置功能（git worktree），允许同一个仓库在多个目录中同时签出不同分支，每个目录有独立的工作区状态，却共享同一份提交历史和对象存储。在多智能体并行场景下，这一机制的价值变得尤为突出：每个agent可以在自己的工作树里修改文件、运行测试，彼此不会产生文件冲突，也不需要频繁的stash/pop操作。Orca和ccmux都以工作树为核心抽象，正是因为隔离的工作树天然对应了"一个任务、一个空间、一个分支"的并行工程模型。

tmux是终端复用器（terminal multiplexer），允许在单个终端连接中同时维护多个会话、窗口和面板，且会话在断开SSH连接后依然保持运行。ccmux在此基础上增加了对agent状态的感知层，而不替换tmux本身，这体现了一种"适配已有工作流"而非"重建工作流"的设计哲学。

上下文与证据：什么必须在移交后存活？

整期测评最锋利的问题，是那个"移交测试"（handoff test）：切换agent后，问它四件事——目标是什么？谁拥有这项工作？计划为何改变？什么通过了验证？

如果你的Git、文档和Issue追踪器能回答这四个问题，那就什么都不用加。只有当答案仅存在于会话中时，一个有范围的上下文服务才有可衡量的价值。

Tali提到的Breathe MCP提供了27项操作的目录，分为记忆、工作、协调、证据与运维五类。一次移交从"捕获"到"认领"到"证据"再到"恢复"。但她明确指出其边界：Breathe MCP不会生成agent、不拥有终端、不创建工作树、不部署软件、也不提供模型。其定价和公开许可证均不可得，托管、存储、备份和连接的模型仍是账单的一部分。

共享工具不等于共享判断，共享记忆也不会让两个agent在同一个代码签出里变得安全。 这是最后一类失败——一旦agent能把工作移交给另一个agent，你依然需要雇佣站在整个技术栈之上的那个人。工具能展示发生了什么，但如何确认一位工程师能理解实时系统、判断移交质量、验证工作成果？这是一个招聘问题。

**MCP（Model Context Protocol）**是Anthropic于2024年底提出的开放协议，旨在标准化AI模型与外部工具、数据源之间的连接方式。MCP服务器以统一接口暴露"资源"（数据）和"工具"（可调用操作），模型客户端通过该协议动态发现并调用这些能力，而无需为每个外部系统单独硬编码集成逻辑。Breathe MCP正是基于这一协议构建的上下文服务——它把记忆、任务状态和证据封装为MCP工具，供不同的agent在同一任务生命周期的不同阶段调用。理解MCP的边界有助于理解Breathe的边界：它是协议层的上下文服务，而不是执行层的agent框架。

选型六问与"减法"原则

Tali给出的实操建议，是在买下又一个智能体之前先问清楚哪项能力真正缺失，然后跑一遍六个问题：

1. 它在卖什么？ 模型、harness、工作区、托管计算机、编排器，还是上下文服务？
2. 它在哪里运行？
3. 它能控制什么？ 聊天、浏览器、账户、终端、仓库，还是部署？
4. 会话结束后什么存活下来？
5. 总账单是多少？ 包括积分、模型、托管与审查。
6. 验收前返回了什么证据？

她的核心主张是减法原则：从一条执行路径、一个真实任务开始，只有当被量化的失败给出理由时，才添加新产品。

由此产生四个合理的起点：单人仓库只需一个harness加Git；"从创意到URL"的项目可能需要一个集成构建器；受管的backlog或许能证明云端工作区的价值；并行工程则应先用隔离的工作树，只有当等待成为瓶颈时才引入注意力编排层。

如果Git能回答移交问题，就跳过记忆基础设施；如果一个agent独占任务，就跳过编排；如果工作区本身就能发布应用，就保留它的技术栈。

Tali最终的判断掷地有声：赢家是最小的可验证技术栈，而不是agent最多、发布会最光鲜的那个。 选择那个你理解其边界、能解释其账单、并有一个具名的人类来验证和负责的技术栈。健全的架构只包含你看得见、也能恢复的失败。