三处人为改坏的代码：两个比较符号，一个向上取整。推送后，GitHub 机器人自动开出三个 CI 失败 issue。
没人 @ 它。它自己判断，派给三个 Worker；两分十三秒，三个修复 PR 建好，合并后主分支 CI 全绿。
这是 1024 工程笔记 11 月 5 日实测。几场实测看下来，结论要收着：它能自己接活，离“把仓库交给它”还差一段。
先划清边界
10 月 31 日晚，DeepSeek Harness 团队发了《Super-agent 设计探索》，同日开源原型，MIT 协议。
文章开篇先把边界划清：这是架构思路探讨，不是现有产品介绍。DeepSeek
它要解决的不是“单个任务做得好不好”，而是“多件事同时来，谁来派活”。一个人通常只能同时跟进 3 到 5 个活跃 Session。DeepSeek
做法是把系统拆成两层：常驻的 Router 接人、派活，自己不执行；Worker 隔离上下文、带完整工具干活。单任务上限取决于模型，多任务上限取决于人的注意力。DeepSeek
两分十三秒，跑通了什么
项目是个订单价格小仓库，坏的是两个比较符号和一个向上取整。三个 Worker 只改源码，不改测试。
视频简介还有一句：这是研究原型，默认只看不动，测试者手动切到自动模式；Worker 用系统账号免审批执行命令。 换句话说，这是埋好雷的玩具项目，加满权限。哔哩哔哩
它证明“发现失败→建工单→派 Worker→开 PR”这条链路能跑通，不证明“它能接住真实需求”。
DeepSeek 自己的实验，测的也不是写代码：约 300 条消息里只有约 20 条是工作请求，编码用“只消耗时间的工具”代替，每种方案跑 5 次。DeepSeek
在这套合成负载里，Super-agent 的 p50 是 12.4 分钟，p95 是 15.7 分钟。DeepSeek
单会话在中性提示下，p95 是 29.5 分钟。DeepSeek
代价是 token。去掉直通后，Router 决策多约 30%，读缓存从 2323 万涨到 3177 万，增 37%。DeepSeek
真机里的另一面
有人搭了个迷你版，把周一早上的活丢进工作群；一半的活，一个 AI 排着干要 5 分钟，她的版本 1 分钟出头。小红书
最意外的是财务：没人 @ 它，它自己接了，48 秒回群，指出分母写成了表头那一格。小红书
第一次跑也翻车：两个 Worker 卡了十几分钟一声不吭，补了 Watchdog 才好。 迷你版是她写的，不是官方代码，时间按实验加了固定等待。小红书
有人让它在云服务器上处理两个 GitHub Issue，最后拿到三份 PR。 同一 Issue 后来补一句“改成中文”，原来的 Worker 接着干，又交了一份 PR。知乎
它现在能交什么
但原型就是原型。GitHub 上，它只有一个提交，没有 Release；README 第一句把话说死：不是官方产品。GitHub
部署文档：两个 preset 以操作者的 OS 用户、danger-full-access 运行，Worker 也能读你的 home 目录。GitHub
默认 observe，只记录“会怎么干”；主动接的单要切 auto 才会执行。 所以现在更适合观察它怎么接活，不适合把重要仓库交出去。知乎
想试，先记三个数
想试的话，别拿重要仓库。先在一个试验仓库开 observe，看它想接哪些活、判断错在哪。
再挑少量任务切 auto，记三个数：被合并的 PR 有多少、每个 PR 花了多少 token、每 100 单你要回来救几次场。
两分十三秒三个 PR 很抓人。但验收那一下，还是得你来点。
