让非工程师也能下指令:Superconductor 的多人智能体协作法

Arjun Singh · 2026-08-12
听中文精华AI 合成朗读00:00
卖给你 token 的人的激励措施与你的并不真正一致。
— Arjun Singh

关联

一家人数不多的小团队,过去一个月烧掉了 105 亿个 token,99.9% 的拉取请求(PR)主要由智能体生成 。他们的客户支持、增长团队——不是工程师——也能直接对智能体下指令修 bug、改产品。

做到这一步,靠的不是某个神奇模型,而是六条重新设计工作流的经验。说这话的是 Arjun Singh,团队之前做过被广泛使用的作业评分工具 Gradescope,现在在做 Superconductor(原话发音 SuperNectar / superprotector,疑为同款产品)

第一条:对模型和工具链(harness)保持「不可知」

这里说的「不可知」(agnostic),意思是别把工作流绑死在任何单一模型或配套工具上 。原因很实在:最好的模型可能每周都在变——可能是新模型发布,也可能是某个模型突然下线。

加上开源权重模型(开放权重的模型)现在相当好用,价格也便宜得多,必须随时能切换 。更关键的是,卖给你 token(模型计费的文本单元)的厂商,利益跟你并不一致——他们想让你烧更多,你要的是刚好够用 。能自由切换,你才能始终掌握主动权。

第二条:把每个「人机接口」都变成「团队+智能体」的共享接口

多数人用编码智能体,是把它困在自己笔记本里,别人碰不到 。进阶做法是接入 Slack,但 Slack 机器人只把智能体从「笔记本」搬到了「聊天软件」里,依然受限 。他们真正要的,是同一个智能体会话(session,带有完整上下文的工作状态)能贯穿所有相关接口:在 Slack 起头,转到桌面应用继续干,最后在 GitHub 收尾——智能体不会因为换了地方就「忘了」之前在干什么

顺着这点,要让智能体的工作对全团队「可见、可协作」。当非技术人员(如客户支持)触发了一个工单,工程师需要一眼看出这事有没有被审查过、谁参与了

审查代码时也不用等通知,因为同一个智能体会话就在那里,遇到疑问直接问智能体本身即可,不必通读整段聊天记录 。另外,智能体做的工作要以截图、视频等制品形式呈现,让任何人、在任何地方都能看到进展

第三条:把外部信号自动变成团队可评估的代码

所谓「外部信号」,散落在各处:Slack 对话、客户演示会、内部会议、Sentry 报错、客户发来的邮件 。现在人们常用 MCP(一种连接外部数据源和模型的标准协议)把它们接进来,但接进来后,智能体依然不知道具体该干嘛,还得靠人去搬运工单

他们最得意的做法是部署「会议机器人」:把一个机器人扔进 Google Meet、Zoom 或 Teams 的会议里听一整天 。它在倾听中自动捕捉有价值的信息,如果发现某个点子跟现有工作有关就自动关联,找不到就新建工单,甚至直接着手生成原型代码

Arjun 展示了一个例子:会上有人提出「智能体在汇报完成前,必须有明确的标准来评估自己做得好不好」,机器人捕捉到这个点子后,当场修改了工单表单、加上了两个验收标准字段,并附上截图。这个原型虽然未必原样上线,但立刻可用、可试 。效果是:每开一次客户会或团队会,总能产出几十个原型,且至少有几个是几乎不用人工干预就能直接合并的 PR

第四条:把工作流搬进隔离的云端环境

这是前面几条的地基。把代码库、工作流统统放进云端隔离环境,首要好处是消除「盖子焦虑」(lid anxiety,指必须一直敞着笔记本盖子、怕一关机任务就断的焦虑)

Arjun 提到自己去年大量使用 Claude Code 时刚有了孩子,不想被死死拴在电脑前 。把一切搬到云端,任务永远在跑,合上电脑也能安心。

但更重要的原因是安全。如果智能体跑在个人笔记本上,而电脑里大概率存着不该被触碰的生产环境令牌或密钥,你只能寄希望于沙箱配置万无一失

随着智能体越来越自主、越来越「想方设法完成任务」,风险在放大:你叫它清空测试数据库,它却从电脑里翻到了生产环境的令牌,照着做了——事故就这么发生了 。除了防止乱用凭证,还要用可配置的网络沙箱防止智能体把你的代码或机密泄露到不该去的地方;每当它试图越界访问,就弹窗确认,权限可以精确到单个工单或整个项目

有了这层云端的隔离与安全,非技术人员才可能真正触发真实工作——他们电脑里根本没装开发环境,但现在客服和增长人员只要亲眼看到 bug,直接在 Slack 或应用里说一句「修一下这事」,智能体就动手,产出截图,工程师直接合并 。他特别提到,以前把整个项目塞进沙箱环境非常痛苦,但现在智能体已经能帮你搞定这套环境配置

第五条:在你的代码库上给智能体做基准测试

别只信公开的评测。像 SweeBench 这样的公开基准测试任务全是 Python,如果你们用的是 Ruby on Rails,结果可能完全不一样,数据只有趋势参考价值 。他的做法是:挑选能代表优秀工程水准的拉取请求(不管是人写的、智能体写的还是混合的),拿各种智能体去跑,得出「质量 vs 成本」和「质量 vs 时间」的细分对比

在他的代码库上测下来,Anthropic 的智能体质量一直在变好,但没变快,而且明显贵得多;Codex 智能体和 Cursor(一款 AI 代码编辑器)既快又好,且更便宜 。看到这组数据后,他们把默认设置切到了 Codex;后来有个模型上线,试了几天挺好,下线后又切回 Codex

因为坚持「不可知」原则,这番来回折腾对工作毫无破坏 。这套基准测试还解决了「朋友听说某新模型很好,但一直没空试」的焦虑——不用凭听说,直接拿数据说话

第六条:他们跑出的真实数字

他们团队相对很小,但过去一个月烧掉了 105 亿个 token。单看 Claude Code 就跑了 3300 次,折合 token 价值一万美元(他们有套餐所以实付没这么多);Codex 的会话量是它的四倍,总体算下来更便宜

基于这些实测,目前绝大部分合并的工作走的是 Codex,但通过 GLM 5.2 完成的份额在持续增长,他们打算继续在这方面投入 。下一步,他们打算基于这套基准测试实现「自动路由」——与其相信第三方知道怎么分配任务,不如用自己代码库上的实测数据,自动把不同任务派给最适合的模型

本集带走

  • 不绑死任何厂商:别让工作流依赖单一模型或工具;开源权重模型已足够便宜好用,随时切换才能掌握主动。
  • 同一会话贯穿多端:让 Slack、桌面应用、GitHub 共享同一个带上下文的智能体会话,省去跨平台同步与上下文丢失。
  • 把外部信号变成原型:开会、跑客户时让机器人旁听,把口头点子自动变成带验收标准的工单乃至可跑的原型代码。
  • 一切跑在隔离的云沙箱:不仅为了合上笔记本安心,更是为了防止智能体误用本地凭证、删错生产数据库或外泄机密。
  • 非技术人员直接下指令:有了云端隔离,客服、增长等非工程师只要反馈 bug,就能直接让智能体动手修。
  • 用自家代码库做基准:公开基准未必贴合你的技术栈(如 Python vs Ruby);拿真实 PR 跑对比,才知道对你来说什么又快又省又好。
  • 拿数据驱动路由决策:小团队一个月烧百亿 token 是常态;用实测数据决定默认用哪个模型,新模型上线随时无缝试水和切换。
全部金句 3 条

卖给你 token 的人的激励措施与你的并不真正一致。
The incentives of the people selling you tokens aren’t really aligned with yours.
—— Arjun Singh · [02:18]

当你说,嘿,清除暂存数据库,而它在你的笔记本电脑上发现了一个它可以使用的令牌,并且它认为它正在与暂存一起工作,但实际上它是生产环境,现在它刚刚删除了一切。
when you say, hey, wipe the staging database and it finds a token on your laptop that it can use and it thinks it’s working with staging, but actually it’s production and now it just deleted everything.
—— Arjun Singh · [10:58]

对于我们相对较小的团队,我们在过去一个月有 105 亿个 token
for our relatively small team, we had 10.5 billion tokens over the past month
—— Arjun Singh · [16:17]

接着看

顺着「AI 编程」挖下去

换个口味