当 AI 开始给 AI 派活

——读 DeepSeek Super-agent，也说说我们早走的那八个月

大家好，我们是 Browser4 核心开发团队。

2026 年 10 月 31 日晚，DeepSeek Harness 团队发布了《Super-agent设计探索：迈向更自主的Agent系统》，并同步开源了技术原型。这篇文章我们读得很认真，也读得很亲切——它要解决的问题，和我们今年 2 月起做 Coworker 时盯着的，是同一个：单个 Agent 越来越能干之后，一群 Agent 该怎么组织起来。

从单智能体到多智能体，中间有一道自然会走到的门

让一个智能体把代码写出来，是 2024 年就能做到的事。让它持续做下去，把一次提交变成每周、每天的稳定产出，中间要补的东西会一点点堆出来：

• 任务从哪里来？GitHub issues、内部 bug 列表、自动化测试 bug 报告、群聊中发现的需求、早餐时灵光一闪的随手记，都应该能被发现。
• 不是所有任务都值得交给智能体。要先看：和项目相关吗？智能体自己做会不会搞砸？相关度和风险两个维度过一遍，筛完再进队列。
• 进了队列之后怎么调度？串行一个接一个，还是并行让多个智能体各干各的？任务之间有依赖怎么办？
• 做完了怎么知道没坏？跑单元测试不够——有些改动只有在真实网站上跑一遍才看得出来。
• 改坏了怎么办？人工要守在哪里？是每一步都过，还是只过关键节点？

这些问题是顺序出现的——智能体先学会写代码，然后需要持续任务，然后需要分诊，然后需要调度，然后需要验证。每一步是下一步的前提。当你走到"让智能体自己分派任务"这一步时，你已经走过了前面所有门。

解决方案：主智能体负责协调，专家智能体负责干活儿

今天很多工具都能让 Agent 独立写代码、修 Bug、跑测试。但当你同时跑三五个 Agent，人会变成最累的那个：在多个会话之间切换，记住每个任务进行到哪一步，哪个需求变了，哪个 Agent 还在等输入。DeepSeek 的观察是一个人通常只能同时跟进 3 到 5 个活跃会话，我们的体验差不多。

年初的时候我们发现，在一个成熟系统中，一个单线的编程任务，AI 通常能够独立完成，不需要人干预。这里的单线编程任务，指的是从用户调用入口，到中间逻辑层，到后端 IO 操作，是一个相对独立的线性流程。

比如在 Browser4 中新增一个 CLI 命令 browser4-cli htmlsnapshot，让用户导出当前页面的 HTML 源码，就是一个单线编程任务。Browser4 里有大量同类单线功能。只要功能描述准确，编程智能体通常可以独立完成这个任务。

我们会同时提出一批这样的任务需求，将每个需求写到一个单独的 Markdown 文件中，然后由 AI 读取任务文件，展开编码、测试、合并等工作。

智能体在 oneshot 能力上的提升，使得多智能体协作有了实现基础：主智能体负责协调，专家智能体负责干活儿。

一张对比表：Browser4 Coworker vs DeepSeek Super-agent

机制	Browser4 Coworker	DeepSeek Super-agent
协调中枢	调度器 + 编号目录状态机	Router 主会话，维护全局上下文
任务载体	Markdown 任务文件在目录间流转	Ticket 工单：输入、进展、交付状态
事件接入	fetch 规则认领 + AI 按相关度×风险分诊	两级过滤：规则排除 + 模型判断介入价值
状态与执行	控制仓库与目标仓库分离	存算分离：云端保留状态，本地设备执行
异常处理	指数退避重试 + 0error 死信目录 + 超时熔断 + 定时归档	Watchdog 监测停滞与偏离，尝试恢复
人工门禁	批准后进入 5approved 才推送，可打标签跳过	提交 PR，等待人工审查
首次公开时间	2026-02-18（git 首次提交）	2026-10-31（技术文章 + 开源原型）

逐行看下来，对应关系相当整齐。这不是巧合，是同一个问题摆在面前时，工程师会自然走向的解法集合：任务要显式化、状态要可持久、异常要有人兜、高风险动作要有人工门禁。

三个差异

协调者：一切皆文件 vs 复杂工程

一句话结论：Coworker 遵循一切皆文件的朴素原则，文件就是任务，文件夹就是状态机，脚本就是智能体；Super-agent 的分派由 Router 模型维护全局上下文、自主完成。

Coworker 做法非常朴素：文件就是任务，文件夹就是状态机，脚本就是智能体。编程任务在 0draft → 1ready → 2working → 3done → 5approved → 6git-pushed 这条目录流水线里流转。状态迁移是自动完成的——调度器负责检查文件夹，文件夹里有活才起 Worker 进程，执行、完成、推送都由工作 Worker 脚本移动文件，转移状态。任务文件夹就像一个邮箱，人或者其他智能体都能够投递任务。Worker 的产出存放到下一个 Worker 的任务文件夹中。人只在两个门禁点出现：起草任务、完成后审批，而审批还可以用 #auto-approve 标签交给系统。工作逻辑写在确定性脚本里，每一跳都可审计、可回滚、可断点续跑。

Super-agent 以 Router 为枢纽：Router 是长期在线的主会话，接收群聊、GitHub、邮件的消息，维护全局上下文，判断任务归属后派给隔离会话里的 Worker。Worker 不直接回复用户，结果统一回报 Router。这是更加复杂的"AI 派活给 AI"，也是它比 Coworker 走得更远的地方。

任务来源：投递文件 vs 监听事件

一句话结论：Coworker 接受任意来源的任务，Super-agent 监听工作环境里的事件。

Coworker 接受任意来源的任务：只需要把任务文件投递到相应文件夹即可。“文件就是任务，文件夹就是状态机，脚本就是智能体”，在这种朴素的、高度解耦合的机制下，可以快速实现多智能体协作，也可以快速扩展系统能力。人提出的需求，将需求文件复制到任务目录即完成任务提交；定期扫描 github issue 并投递到任务目录也是一种任务提交方式。如果我们要增加一个任务源，譬如自动化测试的 bug 报告，只需投递到任务文件夹里即可，相关专家智能体会自动领取任务并处理 bug，这个流程后面还会介绍。

Super-agent 的做法是监听工作环境里的事件，先用程序规则排除明显无关的信息，再由模型结合上下文判断值不值得介入——比如群里有人在讨论一个故障，没人@它，它也会提前尝试复现、分析原因，甚至提交一个 PR 等你审查。从"自动"到"主动"，这是性质上的一步。

执行模型：串行管道 vs 并发会话

一句话结论：Coworker 一条管道同一时间只跑一个任务，Super-agent 让多个 Worker 在隔离会话里并发执行。

Coworker 的一个 Worker 一次专注一个任务，简单、可控、日志清晰；不同类型的任务由不同的 Worker 处理，互不干扰。单条管道内部仍是串行，同一类任务要排队。

Super-agent 的 Worker 可以同时推进 Bug 修复、代码审查、功能开发，必要时还能再调子 Agent。DeepSeek 公布的模拟实验显示，在约 300 条消息、20 项工作请求的场景下，Super-agent 的任务完成时间 P95 为 15.7 分钟，比 Session + 子 Agent 方案缩短约 47%。这是他们自家的模拟数据，非第三方实测，我们也没有复现过，仅供参考。

状态机：每一跳都有明确负责人

每一类任务，都有一个由文件夹表示的状态机，文件夹里有任务文件，任务文件在目录间流转，谁来完成每一跳是确定的：

流转	谁来完成
0draft → 1ready	人移动草稿，或任务分拣脚本自动移入
1ready → 2working → 3done	执行脚本（调度器按文件系统事件触发）
3done → 5approved	人审批；带 #auto-approve 标签的任务跳过这步，从 2working 直接进 5approved
5approved → 6git-pushed	执行脚本把文件移入 6git-pushed，再调用 git 同步脚本提交并推送

调度器只在队列里有待办时才启动子进程，不空转。每一步落盘，随时可以断点续跑、事后审计——这也是文件状态机最实际的好处：系统重启、脚本崩溃，都不会丢任务状态。

自动分诊：规则接入，AI 把关

进队前的分诊分两层：

1. 接入层（规则）：定时轮询配置好的 GitHub 仓库（默认每 10 分钟），自动认领未分配的 issue（每轮上限 5 个），存为任务文件。
2. 评估层（AI，默认每 30 分钟一轮）：agent 按两个维度打分——与项目的相关度（high / medium / low）、AI 修复的风险（low / medium / high）。被定义为低风险的场景很明确：文档和帮助文本修正、简单的参数解析问题、补命令别名、单个函数内的孤立逻辑错误、输入输出明确的小型特性。

判定线是硬编码的：只有"高相关 + 低风险"才进入执行队列，其余全部留给人审。每个 issue 的评估结果写入状态文件，不会重复评估；agent 调用失败自动重试，失败不计入状态。

做下来我们的体会是：这套分诊拦下的比放行的多，而这正是我们要的效果——能自动执行的任务，必须是"错了也不心疼"的那类。随着 AI 能力的提升，放行门槛也会逐步降低。

RWS 与 Coworker：一套在真实世界里运转的自我改进循环

一句话结论：RWS 让真实 AI 智能体在真实网站上"找茬"，发现的问题自动回流成 Coworker 任务，走完问题发现、修复、推送的完整循环。

RWS（Real-World Scenarios）是项目内置的测试智能体，用来测试 browser4-cli 在真实网站上的任务执行能力，发现并修复问题。

RWS 的思路和传统断言式 E2E 完全不同。 它不写"点击按钮后应该出现什么"，而是让真实的 LLM 智能体（dsh / opencode / claude / kimi / codex / Browser4）操作 browser4-cli 完成真实网站任务，并要求智能体始终保持"永久新用户"视角：一个第一次接触这个工具的人，能不能顺利完成？每个场景就是一个 Markdown 任务文件，标题即场景名，正文是编号指令（打开某站 → 搜索 → 总结）。

评估不靠断言，靠一份约 200 行的共享评估提示词：智能体先读 help 和 SKILL.md，再从安装、可发现性、文档、CLI 体验、任务执行、可靠性、UX 七个维度，产出四段结构化报告——任务结果、执行轨迹、问题清单、总体评估。场景库粗分四类：面向公开网站的 generic 场景、针对 browser4 产品能力的专属场景、插件场景、mock-site 场景，另有一组按难度分级的 use-case。编排层支持断点续跑、watchdog 崩溃重启、额度耗尽检测和连续失败熔断——跑的是真实模型，烧钱和断连都是要管的现实问题。dev 模式测本地源码，production 模式测已安装的发布版。

与 Coworker 的衔接是松散的，不是代码级的。 每次场景运行后，RWS 会把智能体报告里的问题逐条写入 coworker 的 issues/draft 目录（以 .issues.json 为准，再派生出含复现步骤、根因分析和评审复选框的 .issues.md）。通过评审的问题进入主任务管道：AI 智能体修复、人工批准、自动推送。

于是这个循环自己转起来了：真实场景暴露缺口 → 缺口自动成为任务 → AI 修复 → 场景复跑验证 → 能力增长 → 场景库加入更难的任务。用 AI 测试，发现问题；用 AI 修复，人工把关。

我们的判断是：这事实上形成了一套在真实世界里持续运转的递归自我改进体系（RSI）——能力边界由真实场景定义，改进由系统自己完成，改进成果再由真实场景确认。目前这个循环里暂时仍有人的干预——问题评审和最终审批由人值守。但这是现阶段的审慎选择，不是机制上的必需：循环的每一环——发现、分配、修复、验证——都已具备自动运转的能力，理论上可以做到不需要真人干预。

我们早走的那八个月

一句话结论：Coworker 首次提交于 2026 年 2 月 18 日，解决的是当时提需求的速度赶不上 AI 编程速度的问题。

• 2026-02-18，Coworker 首次提交进 Browser4 主仓库，包含任务管理脚本和流转目录
• 2026-05-19，RWS 首次提交进 Browser4 主仓库，包含测试脚本和场景库

Coworker + RWS 这套系统在 Browser4 项目上运行了几个月，预设场景都已跑通；截至 2026-11，评审队列里没有待修的 Critical / High 问题。在这套机制下，持续改进 Browser4 的软件质量、提高任务执行能力、提升场景覆盖范围、改进 Agent Experience、降低 LLM Token 消耗，可以仅通过设计场景、自我优化来实现。

说说 Coworker 待改进的地方

一句话结论：Coworker 是项目内置多智能体助手，解决 Browser4 项目批量需求实现和真实世界自我进化问题，尚未泛化成通用的多 Agent 协调系统。

• 全局协调者较简单。 Coworker 没有 Router 这样的角色，跨任务的上下文和优先级判断仍然靠人。
• 并发能力有限。 管道是串行的，没有多 Worker 隔离会话并发的机制。

如果你今天要一个能跑在生产仓库里的任务流水线，Coworker 是现成的；如果你关心的是多 Agent 自主协调的前沿探索，Super-agent 的原型值得认真读。两者不冲突，可以互相参照。

写在最后

做了大半年下来，我们的体会是：把一群 Agent 可靠地组织起来，挑战不在系统层面。真正的瓶颈在：

1. 人能不能准确理解需求
2. AI 能不能从真实环境中获取反馈并准确总结需求
3. 智能体能不能在无人值守模式下很好地完成一个编程任务，准确定义收敛边界

我们乐观地预计，未来 Browser4 能够形成一个在真实世界里持续运转的递归自我改进循环（RSI），自主网上冲浪，自主开发新插件和技能，自主发现和修复问题，自主优化任务执行能力。

---

Browser4 是开源项目，Coworker 的完整文档随仓库发布。