代理委派 :
你的开发代理把测试委派出去
代理委派让你的开发代理完成一个功能后,把验证交给独立的 QA 代理。开发端继续用你信任处理难题的模型写代码。QA 代理在更便宜的模型上跑测试。两者通过 AgentsRoom MCP 服务器对话,所以代理委派端到端工作,不用你手动复制任何东西。
你不再为浏览器点击付 Opus 价格。你不再用截图和 DOM dump 撑爆开发代理的上下文。代理委派把每个任务路由到合适价格的合适模型,QA 代理完成后会回 ping 开发代理,循环自动闭合。
代理委派运行中 : Codex 开发代理完成功能,调用 run_qa_test,QA 代理在更便宜的模型上打开浏览器并回报结果。
这就是代理委派要解决的问题。你跑一个强力的开发代理 (Claude Opus、Codex,那种能设计 API 或重构 store 的模型)。代理 10 分钟交付功能。然后再花 8 分钟在浏览器里点来点去验证功能。同样昂贵的 token 单价。同一个刚才还在深入思考你的领域逻辑的模型,现在在读按钮的文字。
代理委派解决了这个问题。功能完成时,开发代理调用一个 MCP 工具 run_qa_test,附带一个场景。AgentsRoom 用你为 QA 选定的模型 (Claude Haiku、Codex mini、GPT-4 mini,随你) spawn 一个临时 QA 代理。QA 代理拿到 AgentsRoom Browser MCP,驱动页面,断言结果,回报判定。开发代理读取判定,继续前进。
这就是代理委派,也是本页面覆盖的唯一循环。一个开发,一个 QA,一个 MCP。和资深工程师把回归测试委派给初级工程师或 QA 是同一个想法:资深继续设计,初级跑清单。代理委派在模型之间复制了这种分工。

代理委派可视化:父开发代理 (Codex) 和子 QA 代理 (Claude) 出现在同一个代理列表里,开发到 QA 的交接一目了然。
为什么值得接入代理委派
首先,钱。在 Claude Opus 上的一次测试通过和在 Claude Haiku 上的一次测试通过成本相差悬殊。同样的浏览器、同样的断言、同样的截图。代理委派让便宜的模型做便宜的活。打开这个开关的人报告说,在 QA 多的日子里,他们的 token 账单按一个真实可测量的倍数下降,不是 5 到 10 个百分点。
其次,上下文。当开发代理自己跑测试时,每一张截图、每一个 DOM dump、每一条 console log 都会进入开发代理的上下文窗口。20 分钟的点击就是开发代理接下来整段会话都要扛着的兆字节级别的噪音。代理委派把那些噪音隔离在临时的 QA 代理里。开发代理只拿回一句干净的'通过'或'失败',没别的。
第三,生态角度。每一次代理委派都节省真实的算力。在 Opus 在跑的地方改跑 Haiku,那一步的能耗砍半。乘上团队所有人和一年里所有的测试循环,代理委派就成了你技术栈碳排放面上的一个不容忽视的旋钮。
第四,可靠性。自己驱动浏览器的开发代理容易跑偏。截了两张图后,它就忘了自己原本想验证什么。代理委派里的 QA 代理只有一个任务、一个提示。它测试、它回报、它消亡。循环短、可预测、易于调试。
本页唯一涵盖的流程
一个开发代理。一个 QA 代理。一个 MCP 调用。端到端的代理委派。
开发代理交付功能
你的开发代理 (Claude Opus、Codex high reasoning,任何你信任的贵模型) 完成实现。新端点、新页面、新流程。代码写好,文件保存。
开发代理调用 run_qa_test
开发代理不自己开浏览器,而是调用 AgentsRoom Test Runner 服务器的一个 MCP 工具 run_qa_test,附带一个朴素英文场景。那就是代理委派 API 表面的全部。
AgentsRoom spawn QA 代理
AgentsRoom Test Runner 用你配置的更便宜的模型 (Claude Haiku、Codex mini、GPT-4 mini) spawn 一个临时 QA 代理。QA 代理拿到 AgentsRoom Browser MCP 的工具 : navigate、click、type、screenshot、evaluate、get_logs、get_state。
QA 代理跑测试
QA 代理打开页面,走完场景,断言结果,必要时捕获截图,并读取 console log 抓住开发代理可能会漏掉的运行时错误。
QA 代理提交判定
完成后,QA 代理调用 submit_verdict,给出通过、失败或无法判定的结果以及简短摘要。截图和日志会附上。QA 代理进程被销毁。它的上下文窗口随之消失。
开发代理读判定继续
开发代理收到判定作为 run_qa_test 的响应。通过时,开发代理提交或转下一张工单。失败时,开发代理读取失败摘要,修 bug,触发新一轮代理委派。循环自动闭合。
代理委派的经济学
为什么聪明的开发到 QA 分工在不降低标准的前提下降低你的 AI 账单。
浏览器测试是重复的。打开页面、点按钮、读标签、检查 toast。每百万 token 50 美元的模型干这活,和每百万 token 3 美元的模型干这活一样好。甚至可能更好,因为便宜的模型不会觉得无聊。代理委派把工作里无聊的那一半交给便宜的模型。
真实会话里的真实数字:一个复杂流程的典型端到端测试在截图、DOM dump 和推理步骤之间会烧掉 60k 到 200k token。在 Opus 上,那是每次测试真金白银。在 Haiku 上,那是零钱。代理委派把每日 QA 习惯从预算负担变成免费的反射动作。
乘以每一次循环。一个非平凡功能的正常开发日要跑 5 到 20 次测试。代理委派在这些重复中复利累积。开发代理保持昂贵 (你希望它昂贵),QA 代理保持便宜,差额就是纯粹的节省。
代理委派对地球也更友好。同样的活更少的算力意味着更少的能源、数据中心更少的水、更少的碳排放。这不是接入代理委派的唯一理由,但确实是把任务路由到合适大小的模型的一个合理副作用。
代理委派的真实模型分工
人们实际接到代理委派开发端和 QA 端上的东西。
开发端 (有意保持昂贵)
- Claude Opus 4.7
- Claude Sonnet 4.6
- Codex high reasoning
- GPT-4 with deep reasoning
- Gemini 3 Pro
QA 端 (委派给更便宜的)
- Claude Haiku 4
- Claude Sonnet 4 (low effort)
- Codex mini
- GPT-4 mini
- Gemini 3 Flash
代理委派不锁死这张矩阵。你按项目配置 QA 模型。你甚至可以代理委派到完全不同的提供商:开发用 Opus,QA 用 Codex mini,无共享上下文,就一次 MCP 调用。
代理委派在底层实际做什么
代理委派建在 AgentsRoom MCP 栈之上。开发代理在它自己的 CLI 里运行 (Claude、Codex、GitHub Copilot CLI、Cursor 以及另外 10 个代理 CLI)。AgentsRoom 把 Test Runner MCP 服务器注入到那个代理。Test Runner 暴露一个工具 : run_qa_test。那是每一次代理委派调用的入口。
当 run_qa_test 触发时,AgentsRoom 在同一个项目里 spawn 一个新的 CLI 进程,配置不同。那个配置挂着 Browser MCP,挂着 QA 系统提示,模型换成你在 QA 端设的那个。新进程是一个临时 QA 代理:它在测试期间活着,在 submit_verdict 之后死亡。
QA 代理运行期间,开发代理在 run_qa_test 调用上暂停。AgentsRoom 把 QA 代理显示在同一个代理列表里,缩进在开发代理下面 (上图可见)。QA 代理完成时,它的判定作为 run_qa_test 的结果返回,开发代理恢复。从开发代理的视角看,代理委派就是一次 MCP 往返。
开发代理永远拿不到浏览器工具。AgentsRoom 在 spawn 时从开发代理的允许列表里剥掉 browser_* 工具。这就是让代理委派可靠的部分:即使开发代理本能想截一张图,它也无法回退到自己测试。唯一的前进路径是 run_qa_test。靠移除而不是请求实现的代理委派。
代理委派今天跑在哪里,下一步去哪里
AgentsRoom 的代理委派今天优先支持浏览器。同样的形状,更多平面在路上。
今天:浏览器测试委派
QA 代理通过 Browser MCP 驱动 AgentsRoom 内嵌浏览器。本地开发服务器、公开预览隧道、staging URL,Chromium 能渲染的一切。表单、模态框、拖放、对话框、console log、网络错误。代理委派覆盖一个 Web QA 工程师会覆盖的全部表面。
Electron 应用测试委派
如果你自己交付 Electron 应用,你可以在你的项目里安装 AgentsRoom Electron MCP 库。QA 代理连接你的 Electron 应用的方式和连接 Chromium 标签页一样。代理委派跨入桌面应用测试,开发端完全不变。
React Native 应用测试委派 (路线图)
同样的代理委派形状即将到来 React Native。QA 代理将通过 AgentsRoom React Native MCP 驱动 iOS 或 Android 模拟器。开发代理交付一个屏幕,QA 代理在上面点击操作。同样的 run_qa_test 调用,同样的开发到 QA 的交接,移动目标。
没有代理委派 vs 有代理委派
同样的功能,同样的 QA 通过。不同的账单、不同的上下文、不同的可靠性。
没有代理委派
- : 开发代理 (贵的) 自己开浏览器。
- : 每张截图、每个 DOM dump、每条 console log 都落进开发代理的上下文。
- : 20 分钟点击在更便宜的模型本可以做的活上烧 Opus 的 token。
- : 开发代理截到第二张图就忘了自己在干什么。
- : 你为浏览器点击付全价,地球也付全价。
有代理委派
- : 开发代理调用 run_qa_test 然后等。
- : 便宜的 QA 代理做点击、做断言、抓截图。
- : 只有判定 (通过、失败、摘要) 到达开发代理。
- : QA 代理是临时的 : submit_verdict 后消亡,上下文不膨胀。
- : token 账单下降,开发代理保持专注,循环自动闭合。
代理委派是你能接入编码代理配置里最便宜的可靠性胜利。
一次代理委派调用长什么样
这是一次开发到 QA 代理委派的完整形状。开发代理通过 Test Runner MCP 发起这个调用,然后等响应。
MCP 工具调用 (开发代理)
run_qa_test({
scenario: "Open http://localhost:3000/login.\n Type the seeded test user in the email field.\n Submit the form.\n Assert the dashboard URL is reached and the user's name is shown in the header.\n Capture a screenshot on success, capture console logs on failure."
})FAQ
AgentsRoom 里的代理委派是什么 ?
代理委派是两个 AI 编码代理之间的开发到 QA 的交接。开发代理完成一个功能,调用一个 MCP 工具 (run_qa_test),一个临时 QA 代理在不同的模型上跑测试。开发代理读取判定,继续前进。整个代理委派流程通过 AgentsRoom MCP 服务器进行。
为什么我会想要代理委派 ?
三个原因。钱 : QA 代理跑在更便宜的模型上,所以一次测试通过的成本只是在开发模型上的一小部分。上下文:开发代理保持干净,所有截图和 DOM dump 都和 QA 代理一起消亡。可靠性 : QA 代理只有一个任务,所以它测得比一个一边点浏览器一边多任务的开发代理更好。
哪些模型能用于代理委派 ?
AgentsRoom 支持的任何模型:Claude (Opus、Sonnet、Haiku)、Codex (high、mini)、GitHub Copilot CLI、Cursor 以及另外 10 个代理 CLI。代理委派是跨提供商的。常见分工是开发端用 Claude Opus 或 Codex,QA 端用 Claude Haiku 或 Codex mini,但由你来选。
代理委派只用于浏览器测试吗 ?
今天是的,QA 代理驱动 AgentsRoom 内嵌的 Chromium 浏览器。明天,同样的代理委派形状覆盖 Electron 应用 (在你的 Electron 项目里安装 AgentsRoom Electron MCP 库) 和 React Native 应用 (路线图,iOS 和 Android 模拟器)。
代理委派怎么防止开发代理自己做测试 ?
AgentsRoom 在 spawn 时从开发代理上剥掉 browser_* 工具。开发代理字面上无法调用 browser_navigate 或 browser_screenshot。唯一的浏览器路径是 run_qa_test,它会触发代理委派。这个约束是机械的,不是提示里礼貌的请求。
代理委派是云的还是本地的 ?
本地优先。开发代理、临时 QA 代理、MCP 桥接和浏览器全都在你的机器上运行。代理委派只在底层模型 (Claude、Codex、Antigravity) 与它自己的提供商通信时才使用云,和普通的代理运行完全一样。
代理委派真的省钱吗 ?
是的,在 QA 重的日子里省得很有意义。在 Opus 或 Codex high 上的一个复杂端到端测试 vs 在 Haiku 或 Codex mini 上的同一个测试,成本差大约是 10 倍。在整个团队的一个开发日里做代理委派,这个差距会快速放大。
开发代理从代理委派那里拿回什么 ?
一段简短的结构化判定:通过、失败或无法判定,附摘要、可选的截图路径和可选的 console log。上下文里没有原始截图,没有 DOM dump。这正是代理委派的全部要点:把 QA 的噪音隔离在 QA 代理里。
QA 代理失败时可以建一张 backlog 工单吗 ?
可以。代理委派给 QA 代理配备了 Backlog MCP。一次失败可以作为项目上的一张 backlog 工单落地,附带场景、截图和 console log。开发代理读取判定,backlog 工单承载长篇细节。
代理委派相对于 AgentsRoom 其他功能位于什么位置 ?
代理委派建立在 Browser Automation (给 QA 代理浏览器) 和 AgentsRoom MCP 服务器 (给每个代理它的工具表面) 之上。Agent Teams 是更广的多代理工作流编辑器:代理委派是那种工作流的开发到 QA 口味的版本,但以一次 MCP 调用的形式暴露出来,所以任何提供商的任何代理都可以使用,不用配置一张图。
搭配使用
Browser Automation
代理委派的 QA 端驱动的 Chromium 和 Browser MCP 层。每个项目一个真实持久的浏览器。
Agent Messaging
委派会派生一个临时代理,它报告结论然后消亡。代理之间的消息传递是另一个方向:常驻成员互相写信,收件箱比每一次会话都活得久。
Agent Teams
可视化多代理工作流编辑器。代理委派是开发到 QA 的口味,Agent Teams 是带 N 个节点和反馈循环的完整图版本。
AgentsRoom MCP
让代理委派成为可能的 MCP 服务器 : Test Runner、Browser、Backlog、Terminal Commands、Prompt Library。
Multi-Provider
Claude、Codex、Antigravity、OpenCode、Aider、Grok Build、Mistral Vibe 和 Kimi Code 并排运行。代理委派是同一个想法的跨提供商角度。
Claude Code Token Usage
每个会话的实时 token 表。确认代理委派在实际中给你的美元节省最快的方法。
Public Backlog
当 QA 代理在一次代理委派通过中失败时,bug 落在这里。客户和队友看到回归,开发代理接手。
别再为 QA 点击付 Opus 价格
下载 AgentsRoom 试试代理委派。把开发代理接到你信任的模型上,把 QA 代理接到更便宜的模型上,让开发到 QA 的交接通过 MCP 自动发生。
配套应用:随时随地监控你的 Agent
使用 Claude、Codex、Antigravity CLI 或其他 AI 提供商。
把 Bug 和需求直接发送到您的公开待办清单。