如果你同时跟踪几家 AI 公司的产品，大概见过三种互相矛盾的说法。Cursor 和 Codex 讲 planner 加 executor，一个拆任务，一个干活。Grok Bot 换了副调子，说你的账号里住着一批领工牌的 AI 同事：销售外呼、报销对账、产品表现各有专人，管周报的叫 Piper，你合上电脑他们继续干。到了 Claude Code，路子又变了，模型把编排直接写成 JavaScript 脚本，几十上百个 subagent 照着依赖图跑。三边都在说自己才是正解。
一个自然的疑问是：给 agent 套上职业岗位，到底是营销包装，还是真能帮模型提效？先把名字放一边，叫 Piper 还是老王纯属点缀，这里的帽子指的是岗位定义：你是产品经理、你是财务、你是 QA。这种争论往往预设了前提，觉得岗位设定和底层机制在同台较量。但我 8 月中旬测 Grok Build CLI 时拿到的日志，指向了另一种读法：这几套设计分属不同层级，回答的也是不同问题。机制层管 agent 的实际表现，编排层决定谁握控制权，接口层负责把系统翻译给人用。职业帽子老老实实待在接口层，它有自己的真用途，只是对模型的输出质量帮不上忙。
先看三种产品的真实形态。Cursor 和 Codex 走的是功能分工路线。Codex 从 0.145.0 版本引入 Multi-Agent V2 架构，Cursor 则把多 agent 协同架在 Composer 与 Agent Mode 之上。两边的 agent 都有明确职能，名字也是清一色的功能词：planner、executor、reviewer、explore。代码编辑器里没人会给 subagent 取名叫老王。
Grok Bot 选了具名同事的走法。它在 2026 年 8 月 11 日开启早期测试，为每个账号分发一台 24 小时开机的云电脑，里面住着挂着名牌和岗位的 AI 同事。官方文档直接列了八个岗位：销售外呼、招聘寻源、付费广告、报销对账、产品表现、缺陷复现、客户健康、幕僚长。每个角色绑定一份标准产出，比如销售外呼同事趁你睡觉做完客户研究与联系人排序，按你的语气拟好邮件，早上留下一份待审批列表。
Claude Code 和 Grok Build 走了脚本编排的路。Claude Code 在 5 月底发布
dynamic
workflows，由模型针对当前任务现场写出一段 JavaScript
脚本，交由后台独立的 runtime
跑起来。脚本只管流程控制，自己不动手，专职负责 spawn subagent。Grok
Build 也是一个思路，它的 /deep-research 命令背后趴着一段
Rhai 脚本，这种 Rust 生态里的脚本语言，做的事情和 JavaScript
版本没有两样。
这看起来像是路线分野。实际上，三款产品只是在不同层级上各取所需，而它们赖以运转的机制地基完全相同。
机制层的关键只有一件事：context window 隔离。找个日常场景一试便知。假设你要做一份周度业务复盘，需要对比十家竞品的黑五营销。最省事的做法是把十家材料统统塞进同一个 prompt。模型确实会交出一份格式周正的报告，目录清晰、分节工整。但只要稍微细读就会露馅：好几个小节都在换着花样倒腾同一套套话，内容深浅不一。这种失败往往很隐蔽，表面格式挑不出毛病，分析质量却平庸至极。十家公司的材料挤在一个窗口里互相稀释，模型的注意力预算摊得太薄，给不出任何一家有深度的判断。
真正管用的手段是给每家竞品单独开一个干净窗口。一个 subagent 只盯一家公司、只吃一家的材料，吐出一份独立摘要，主线程最后只负责归纳这十份产出。性能提升的真正推力是多了几个互不干扰的上下文窗口，开了几个角色反倒是细枝末节。光靠角色扮演救不了场：你在同一个窗口里对模型念咒，说你现在是资深销售分析师，视角和打分标准或许能调优一点，可窗口还是那个窗口。十家公司的材料依然挤在一块，既做不到并行，也没有任何物理隔离。
这也是我翻看 Grok 运行日志时最玩味的地方。卖具名同事最起劲的公司，自己的工程内核里愣是一个 persona 都找不到。Grok Build 的 deep-research 工作流把一次调研切成四阶段：规划、检索、验证、成稿。我当时跑出来的那张角色清单格外直白：research-planner 一个、researcher-0 到 researcher-3 四个、evidence-verifier 两个、report-synthesizer 一个，凑齐八个 child agent。清一色的功能性命名，从零编号，谁也没心思给它们取好听的名字。脚本里写死的工程参数同样朴素：检索宽度默认四路，agent 总预算 128 个，并发上限 32 个，拿 journal 文件做断点恢复。这里头找不到半点 Piper 的影子。它骨子里就是前文说的干净窗口，再加上验证阶段的双倍采样：24 条候选断言抛出来，两个独立的 verifier 各自核对一遍，24 条全数通过才准写入最终报告。
换言之，卖帽子的团队自己下场干重活时从不戴帽子。这谈不上言行不一，纯粹是分层架构的自然表现：机制层认的只有窗口隔离，职业帽子在这儿使不上半点力气。
机制层解决的是 agent 输出质量的问题，但它不插手另一件事：执行任务时，究竟谁来决定下一步往哪走。我把这个控制位称为编排席。前面提到的三类产品，刚好对应了三种截然不同的坐法。
第一种坐法是队友人格坐上去。在 Grok Bot 里，用户把需求甩给某位具名同事，接下来的步骤全凭这个角色的内置逻辑往前推，跑到关键节点再跳回来找人审批。用户操作时的心智模型是委派，跟在办公室吩咐真人下属没两样：这个客户归你跟了。
第二种坐法是主 agent 坐上去。Codex、Cursor 以及 OpenHands 全在此列。OpenHands 就是个现成的样本：通用的 CodeActAgent 碰到自己处理不来的网页浏览，会触发 AgentDelegateAction，把子任务转派给专用的 BrowsingAgent。谁来拍板下一步？答案是当前的主 agent，开发者只能靠提示词去引导它的判断倾向。
第三种坐法是代码坐上去。Claude Code 的 dynamic workflow 和 Grok 的 Rhai 脚本，直接把控制流从模型的上下文记忆里剥离出来，写成白纸黑字的可执行代码。先跑哪步、何时并发、在哪里分流，全由脚本说了算；各个 subagent 守在自己的窗口里，只负责想办法搞定分派到的具体事务；验证环节再派几个独立的 child agent 做交叉比对。我们之前写过一篇文章专门分析这套设计，核心结论是它在三个层级上组合了两种确定性：流程控制用过程确定性锁死，子任务的执行与判断则留给结果确定性。这种做法的代价是脚本无法中途随机应变，因而最适合那些能够预先写明执行计划的硬仗，比如代码审计、大规模仓库迁移，以及需要多角度交叉验证的深度调研。
三种坐法押注的筹码各不相同。队友人格押的是用户的委派直觉，主 agent 押的是开发者的提示词调优手感，代码押注的则是确定性本身。有意思的是，Grok 这家公司同时把第一种和第三种端出来卖：消费端里的 Piper 头戴岗位与姓名，工程底座里的 Rhai 脚本却连个 persona 都不屑于写。同一家厂商，两款不同产品，恰好在商业现实里印证了这套分层逻辑。
既然帽子对模型本身的输出质量毫无助益，为什么商业产品还是这么乐此不疲地加码岗位设定？答案在接口层。帽子真正在解决的三件实事全围绕着人展开，直接对接人的协作直觉，跟模型本身的推理能力无关。
第一件，帽子把人类的委派意图翻译成了系统配置。普通用户很难凭空讲出把外呼流程参数化、或者为 CRM 同步挂一条异步流水线这类术语，但谁都懂得怎么说给销售配个同事。人类在现实里唯一无师自通的多 agent 编排技能，就是给人派活。岗位帽子把这项生活经验直接嫁接到了软件交互上，省去了学习新指令集的门槛。接口层设计的优劣，完全取决于隐喻的普及程度。同事显然比 planner 更符合大众直觉，这也是具名同事频频出现在订阅制消费级产品中、却很少出现在硬核开发者工具里的原因。
第二件，帽子给触发器和审批门提供了天然的挂载锚点。按日程表跑的定时任务、由 Slack 消息或 GitHub 通知触发的自动化管线、外发邮件前的人工放行卡点，这类边界控制总需要依附于一个具体的具名实体。你得清楚知道每天清晨是谁在跑报销对账，也得知道自己点击批准的外联邮件出自哪位同事之手。如果不给名字，光靠冷冰冰的 agent 编号，面向大众的产品就没办法向用户交代责任链。
第三件，帽子为持久记忆划出了独立车道。具名角色的历史对话、本地文件和浏览器会话会随时间慢慢沉淀下来，留待下次调用。如果同一个账号下的上下文不做角色分流，跑上一个月就会混成一锅难以检索的浆糊。名字在这里充当了最直观的索引键。
这方面早期的样本是 MetaGPT。它在 2023 年把软件公司的 SOP 硬编码进各种 agent 角色，产品经理写 PRD，架构师出设计，工程师写代码，主打一行需求进、一个仓库出。那时基础模型能力有限，角色设定确实承担了部分行为锚定的任务，试图靠流程把容易跑偏的输出拽回来。三年后再看，这套角色划分的价值主要留在了演示 Demo 阶段，它让系统交互变得直观易懂，而在工程上沉淀下来的真正遗产，其实是文档、接口规格与流程图这些格式化的中间产物。帽子走在了前面，底层的窗口隔离与验证机制却未跟上，框架的热度自然也就停留在了模型稚嫩的特定历史阶段。
近期的混合案例把这种分层展现得更透彻。Claude Code 的 agent teams 功能在接口层全面借用了团队概念：一旦开启，派生出的会话改称 teammate，不再叫 subagent，各个 agent 还能点对点互发消息。但转到机制层，核心不过是一份共享的 tasks.md 账本文件。任务状态、认领记录、产出依赖全写在里面，agent 靠着解析这份文件去动态认领与交接。外壳借用了团队修辞，驱动内核依然是普通的文件读写加上消息循环。即便是功能派起家的团队，只要试图把产品推向大众，也会在接口层披上一层拟人外衣，底层的机制地基却始终波澜不惊。
帽子底下还有张不得不亮出的底牌：它给不了安全边界。Grok Bot 的官方文档写得很直白，同一个账号下的所有同事共享同一台云电脑，cookie、本地文件、终端凭证完全互通，每位同事仅仅分到了独立的虚拟显示屏。销售同事与报销同事之间并不存在真正的系统权限隔离，唯一能依仗的只有人工审批门。评估这类产品时，把这点想明白，比看花哨的功能清单要紧得多。
把这三层逻辑收拢成一张对照表，做架构选型时便能对号入座。不同路线在决策权归属、确定性来源与适用场景上，边界划分得相当分明。
| 维度 | 队友人格 | 主 agent | 脚本编排 |
|---|---|---|---|
| 谁决定下一步 | 具名同事 | 当前 agent | JavaScript 或 Rhai 脚本 |
| 确定性来源 | 委派直觉加审批门 | 提示词与模型能力 | 控制流锁定为代码 |
| 记忆放哪 | 同事车道，持久沉淀 | 会话上下文 | 脚本变量加 checkpoint |
| 面向谁 | 订阅制商业用户 | 开发者 | 计划可预先写清的重活 |
如果你着手自建系统，资源投入的优先级和买商业软件的直觉恰恰相反。先扎牢窗口隔离，这是一切产出质量的物理地基；接着根据任务对可靠性的严苛程度挑编排坐法：需要可审计、可重复的流水线，就老老实实用代码把控制流锁死，探索性质的重活再交给 agent 自由发挥；人格包装排在最后，唯有系统要交付给不懂提示词的业务方时，才有必要投入。给内部使用的编排系统硬起名叫 Piper，除了给日志平添一点趣味，工程上带不来任何可测量的收益。
这个分层视角顺带能给出几条可检验的行业预测：开源框架会继续倒向功能性分工，因为核心开发者始终盯着机制层；订阅制消费工具会继续加码岗位包装，因为买单决策发生在接口层；代码生成工具则会把脚本编排沉淀为标配，因为工程世界对确定性有真金白银的定价。大可以拿未来一年的行业新品挨个对照。一旦 Piper 们主动对外公开同事背后的窗口隔离参数，或者 Cursor 宣布把 planner 改名叫老张，随时欢迎回过头来推翻我的结论。
相关阅读：关于脚本编排那一层的确定性边界，我们此前写过一篇更详尽的分析，见 Claude Code Dynamic Workflow：确定性边界画在了哪里。各家编码工具的多 agent 架构基因对比，见 多 agent 基因比较。