多人协作的 agentic 工程——Arjun Singh(Superconductor)

• 开场立论：逛一圈展台和演讲，所有人都在讲"把 agent 放到一切的中心"，但很少有人在讲「人」——"这一切归根到底是为了我们自己"。所以这 18 分钟讲的是人怎么嵌进 agent 工作流，而不是 agent 本身。→ 详细
• 题目里的「多人协作式 agent 工程（multiplayer agentic engineering）」意思很朴素：让整个团队和你最好的那几个 agent 一起干活，而不是一人配一个 agent、各干各的。→ 详细

• Arjun Singh 与联合创始人 Sergey 在伯克利读博时认识（他做机器人，Sergey 做计算机视觉），读博期间创办了 GradeScope——帮老师批改学生作业，全球几千所大学、几百万学生在用，后被收购。→ 详细
• 现在这家公司基本就是 GradeScope 的原班人马，一支"从第一个用户一路做到被收购"、共事十年以上的队伍。过去一年他们"非常激进地把 agent 塞进了自己的工作流"，把瓶颈和摩擦点全摸了一遍——今天讲的就是摸出来的东西。→ 详细 → 详细

• 他的原话：演讲简介里写的是五条经验，"我要发挥一下工程师本色，从 0 开始编号，再加一条"——所以实际是六条，编号 0–5。→ 详细
• #0 · 不要绑死在某个模型和某套 harness 上。（harness 指包住模型的那层"外壳"——Claude Code、Codex CLI、Cursor 这类工具，决定 agent 怎么读文件、跑命令、提代码。）→ 详细
• #1 · 把每一个人机界面，都变成「人 + agent」共用的界面。→ 详细
• #2 · 让 agent 的工作在团队里可见、可协作。→ 详细
• #3 · 把每一个外部信号，都变成你的团队能快速评估的代码。 ⚠️ 他在台上说这是"the third lesson（第三条）"，但因为他自己是从 0 起编号的，这条从头数其实是第 4 件事——如实照录，不替他改数字。→ 详细 → 详细
• #4 · 让工作流、代码库、项目都能在一个隔离的云端环境里跑起来。 他说前面三条其实全都依赖这个前提。→ 详细
• #5 · 在你自己的代码库上给 agent 做基准测试。→ 详细
• 顺带一处中英稿不一致：t004 英文原话是 "the second lesson"，中文译稿写成了「第三条」；t005 英文是 "The third lesson"，译稿写成「第三条经验（编号第三）」。按英文口述来数才对得上他的 0 起编号。→ 详细

▲ 图注：经验 #0 的三条理由：最好的模型/harness 每周都可能换、开放权重模型已经够用、卖你 token 的人跟你利益不一致。右下角贴了一条真实推文佐证——某公司的 Anthropic 账单即将从 40 万美元/年跳到 140 万美元/年，因为超过 150 个席位被强制转企业版、每个 token 按标准 API 价计费，「一夜之间 3.5 倍」。

• 三个理由。第一，最好的模型和 harness 可能每周都在变——可能是出了新的，也可能是原来最好的那个突然没了，"你不希望它把整个团队的节奏搅乱"。→ 详细
• 第二，开源权重模型现在相当能打——他们用 GLM 5.2 就挺满意，而且"便宜得多"；你得能去试、去接进来，而不用因此推翻整套工作流。→ 详细
• 第三条最狠，是这一节的落点："卖你 token 的那些人，跟你的利益并不完全一致。" 他把话讲透了——你做这些事是有目的的，你想让客户过得更好、让产品更好；而他们想的是多卖你点 token。"你可能确实愿意为该花的 token 买单，但你不想花超出这个量的钱。"能在方案之间随时切换，就是把主动权攥回自己手里。→ 详细
• 他在这里先声明了全场的立场：过程中会提到几个自家产品让这件事变简单的地方，但"不管你用不用我们的东西"，他更想留下的是那些他认为真正重要的点。→ 详细

▲ 图注：经验 #1 的一句话就在页面正中：「每个人都有 Slack bot，这还不够。」——要把每一个人机界面都改造成人和 agent 共用的界面，同一个会话能从任何入口接着聊。

• 现状：人用编码 agent 时坐在自己笔记本前，agent 也被困在那台笔记本里，别人没法跟它说话。大家第一个想到的扩展入口是 Slack——Claude 有 Slack bot，Codex 有 Slack bot，他们也有："挺酷的，你可以说'嘿 Codex bot，去做某某事'，它就去做了，而且别人也能跟它对话。"→ 详细
• 但他立刻否掉了这个中间解："我们只是把它从'困在某个人的笔记本里'变成了'困在 Slack 里'。" 确实有很多工作发生在 Slack，比什么都没有强，但显然不是所有工作都在 Slack 里发生。→ 详细
• 他们要的是：能从任何相关界面接着操作同一个 session（session ＝ 一次连续的对话＋工作会话，带着完整上下文）。可以是 Slack、他们的 App、GitHub，也可以是别的地方。他举的流程是：在 Slack 里发起并协作 → 到桌面端/移动端 App 这种更偏工程师的环境里继续推进 → 最后在 GitHub 上收尾。→ 详细
• 关键那句：全程是同一个 agent session——"agent 不会因为你从 Slack 换到 GitHub 就忘了之前干过什么，同一个 session，同一套上下文。"→ 详细

▲ 图注：经验 #2：让 agent 干的活在团队里*看得见、能协作——左边是聊天里的过程与介入记录，右边是同一份工作在应用里的产物视图。*

• App 视图里能看到一个 ticket 上都有谁参与过：Sergey 建了这个 ticket，Arjun 一直在跟同一个 ticket 对话，做增长的同事也进来了；顶部直接列出谁会收到这个会话的通知、谁看过。→ 详细
• 他强调这一点在"工作由非技术同事发起"时尤其重要：客服同事建了个 ticket，跑得还挺好——"但我想知道：这东西到底有没有工程师把过关？" 一眼就能看清都有谁介入过。→ 详细
• review（代码评审）时可以直接插一句问 agent："嘿，你当时为什么这么做？" 因为是同一个会话，不用干等 Sergey 收到 GitHub 通知再回你——"答案几乎肯定就在这个 thread 里，但我也不想把整个 thread 从头读一遍，那我直接问 agent 就行了。"→ 详细
• 让工作可见最常用的方式是 artifact（工作留痕）：不管这件事从哪儿开始、在哪儿结束，agent 都会用截图、视频或别的形式把它做的事展示出来，而且你在哪个界面都能看到——不用再纠结"那个东西在哪来着？我是得去 GitHub 看图还是去 Slack 看图"。→ 详细

▲ 图注：经验 #3 列的「外部信号」来源：Slack、会议、bug 追踪器、销售电话、bug 报告、功能请求——右边是这些信号汇进同一张图被消化成候选工作项。

• 什么算"外部信号"（他一口气列了一串）：一段 Slack 对话、你和客户开的会、一次 onboarding 通话、一次销售电话、内部团队会议、Sentry（线上报错监控工具）或 bug 追踪系统里的条目、客户报的 bug、一封邮件、一个功能需求。→ 详细
• 他点出病灶：这些东西全都已经存在了，只不过分散在各个系统里。大家用 MCP（一种让 agent 接外部系统的标准插口）把它们接起来，于是编码 agent 能去查邮件、查 Notion——"但问题是，它怎么知道该做哪件事？" 结果还是得有人从这儿捞一条，告诉它"去处理第 48 封邮件"或者"去处理 6000 号 ticket"。"这依然需要大量的人工协调。"→ 详细
• 他们的做法是提供好几种方式，自动把信号吸收进来、判断优先级、然后直接动手处理——把人从"搬运工"那个位置上撤下来。→ 详细
• 一个现场细节：这一段本来要做 live demo，但"这里的 Wi-Fi 有点不给力"，于是改放前一天录的实录。→ 详细

• 场景：他们在大会展台有个位置，前一天一整天都开着「会议 bot」——你只要把 bot 拉进 Google Meet、Zoom、Teams 或者随便什么会议，它就一整天在那儿听。他展示的是一场 4 小时的 Google Meet。→ 详细
• 它一边听一边生成了一大堆条目，而且如果发现已经有相关的工作在做，就直接关联过去，不会重复建一份新的。这些条目里有一部分是路人在测试这个 bot、故意让它干点奇怪的事或有意思的事，"但相当一部分其实是真的好点子"——来自别人看他们在做什么、提问、然后冒出的新想法。→ 详细
• 他挑出来讲的那个例子：清单里最后一条想法，是有人随口说了一句——"我用编码 agent 的时候，希望它在告诉我'做完了'之前，先有一套明确的标准来判断自己这活到底干得好不好。" 他特别强调："bot 自己就把它捡起来了，我们没有任何人做任何手工操作。"→ 详细
• 接下来发生的事：bot 自己建了 ticket，然后就开工了。Arjun 只说了一句"嘿，把你做的东西截个图"，就拿到了成果截图——它把他们产品的建单表单改了，加上了两个新的「验收标准（acceptance criteria）」字段（验收标准＝"做成什么样才算做完"的判定条件）。→ 详细
• 他给的效果口径不是"省了多少人力"，而是节奏：这套东西把"散落在各处的成百上千个想法"收拢起来，让你能跟上客户的诉求和他们的思考节奏往前跑。每次开客户 onboarding 通话或团队会议，几乎都能收获几十个已经做成原型的新点子；更重要的是，在几乎不用人插手的情况下，至少有几个是能直接 ship 的 PR。 原话是："我们聊天，东西自己冒出来，我们看一眼，然后就发出去了。太有意思了。"→ 详细

• 展示完那个自动改出来的表单，他主动问了一句并自己回答："那我会原封不动地把这个直接 ship 出去吗？不会，多半不会。"→ 详细
• 但他紧接着给出这东西的真实价值："这是一个新点子，而且是具体的"——可以拿它去折腾，可以打开实时预览，实际看看这是不是真的提升了效果。也就是说，产出的定位是一个能上手评估的候选物，不是一个待合并的最终方案。这正好是经验 #3 那句话的落点：变成"团队能快速评估的代码"，而不是"可交付的代码"。→ 详细 → 详细

▲ 图注：经验 #4 的三条好处：消除「合盖焦虑」——可以合上笔记本走人、只给 agent 它真正需要的权限、让非技术同事也能触发真实开发。下方那句吐槽很传神：「写 AI 代码的人正半开着笔记本穿过机场、办公室和溜冰场。」

• 前提：前面三条全都依赖工作流、代码库、项目能在一个隔离的云端环境里跑起来，"这样 agent 就不会被困在某个人的机器上了"。→ 详细
• 第一个理由是消除「合盖焦虑（lid anxiety）」——你得能随时合上笔记本。画面很具体：有人抱着开着盖的笔记本在办公室里跑、在机场跑，Twitter 上还有人开车回家的路上把笔记本用手机热点连着放在车里。→ 详细
• 这基本就是他动手做这件事的直接原因：去年他大量用 Claude Code 干活时孩子才六个月大，"我永远不想去纠结'我现在能不能离开笔记本'这种问题"；搬到云上之后"活始终在跑"。但他明说这不是最重要的理由——最重要的在下一节（他说上一场演讲也提到了）。→ 详细

▲ 图注：他放的那条新闻标题：「『我违反了给我的每一条原则』：一个 AI agent 删掉了一家软件公司的整个数据库——这可能不是 AI 的错。」——用来论证权限收窄不是洁癖，是止损。

• 他的主张：只应该给 agent 它真正需要的权限。现状是一堆开发者各自在笔记本上跑 agent，而这些笔记本上——"除非你的卫生习惯好到无可挑剔"——多半装着一堆你压根不想让大模型或 agent 碰到的东西。→ 详细
• 他把大家的处境压成两个阵营：要么你在不停地点「批准」；要么你在祈祷你的自动批准流程、你的 YOLO 模式（"你自己看着办"模式——关掉逐步确认、让 agent 不用问就直接执行）、你的沙箱配置全都是对的，别去读你笔记本上那些它不该读的东西。→ 详细
• 失败场景讲得很具体：agent 正变得越来越自主、越来越足智多谋，"它们一心想让你满意，想把你交代的事办成"——于是当你说"把这个数据库清掉"，它在你笔记本上翻到了一个能用的 token，它以为自己连的是 staging（预发布环境，给人测试的副本），结果那是 production（生产环境，真实客户在用的那套），然后它就把东西全删了。他补了句很克制的话："我不是说这种事天天在发生，但确实还是会发生。"→ 详细
• 他要的回报不是安全指标，是安心感："能让任何人放开手去跑实验、跑想法、跑原型、甚至跑真实代码，还完全不用担心这类问题，这份安心真的太值了。"→ 详细

▲ 图注：网络沙箱的实际配置界面：按 agent 逐条允许/拒绝出站域名——防的不是它改坏东西，是*把东西传出去。*

• 不只是"别让 agent 拿到它不该有的凭证"，还得保证它没办法把代码、项目、密钥或内容偷偷传到不该去的地方。→ 详细
• 做法是可配置的网络沙箱：由你定哪些地址允许访问，越界就弹出来问一句"要放行吗"（典型场景：你正好在接一家新的第三方服务、需要查它的文档），放行粒度可以只针对这一个 ticket，也可以对整个项目。效果口径还是"安心 + 授权成本低"：大家放手干活、要新权限时授权容易，"同时我们也不会因为让 agent 跑在 YOLO 模式下就泄露一堆重要数据"。→ 详细

• 他把这条称作"关键"：非技术的人电脑上压根没配开发环境——所以在旧世界里他们只能提需求、等人做。→ 详细
• 他们的现实是：做客服的、做增长的同事真真切切地在改进产品——他们跟用户聊天、看到 bug、自己踩到坑，然后去 Slack 或者应用里说一句"把这个修了"。agent 就真把它修好了，还附上截图；工程师接手一看，合并进去。→ 详细 → 详细
• 他给了反事实对照：要是没有这套东西，他们就得去 Linear（工单/项目管理工具）提个单，等 Linear 那边慢慢排到，再由 PM 分诊。 "这里完全不用。你张嘴要，事就办完了。"→ 详细

• 他自问自答："那为什么直到最近大家都没这么干？因为以前太痛苦了——把整套项目在这种沙箱环境里跑通，过去真的非常非常折磨人。" 变量是 agent 变强了。→ 详细
• 他们自己做了个环境配置助手能帮你改造项目，但他明说"不管你用不用我们的东西，我都强烈建议你把项目弄成这种跑法——你完全可以让 Claude Code 或者 Codex 帮你做"。→ 详细

• 做法三步：① 先挑出一批代表优秀工程水准的 pull request（PR ＝ 代码合并请求）——agent 写的、人写的、人机混合的都行，无所谓；② 选好你想用、想评测的那几个 agent；③ 拿到一份基于自己代码库的质量 vs 成本、质量 vs 时间拆解。→ 详细
• 为什么不能只看公开榜：SWE-bench 全是 Python，而他们是 Ruby on Rails——"两边的评测根本不是一回事。趋势上确实有可比性，但结果可能差得非常非常远。"（SWE-bench、Terminal-Bench 都是业界通用的编码能力评测榜。）→ 详细
• 他现场展示的结论（他反复声明"这只是我们自己的代码库，我不是在下什么普适结论"）：Anthropic 的 agent 一直在稳步变好，但速度基本没长进；Codex 系列和 Cursor 相当快、效果也不错；开源那批随时间越来越好，但偏慢。从成本看，Anthropic 那套对他们明显贵太多，Codex 对他们就便宜。→ 详细
• 数据直接改了行为：结果"正好跟我们的直觉体感对上了——我们本来就想再拿点硬数据"，于是把默认切成了 Codex。他补充说他们仍然在用不同模型，"它们各有各的适用场景，我们也喜欢这种多样性"。→ 详细
• 中立带来的实际收益是切换零成本：后来 Fable 出来了、效果很好，他们那几天把默认切成它；然后它下线了，就切回 Codex——"因为我们对模型是中立的，这些来回切换对我们的工作完全没造成什么实质干扰。"（英文字幕把这个名字拼成 "Fiable"，中文译稿按发音订正为 Fable。）→ 详细
• 他还点了一种很多人有的情绪：朋友说"听说 MiniMax 不错、GLM 也行、Kimi K2 很强，但一直没空试，身边所有人都说必须试，说它又好又快又便宜"——焦虑一阵，终于抽出两个小时去试，结果发现"其实在我们这儿根本不好使，那我这两小时不是白花了"。有了自己的基准，这种焦虑被消掉，"让你非常顺滑地一直待在最前沿"。→ 详细

• "我们现在基本上 100%——严格说 99.9%——的 pull request 都是大量由 agent 生成的。"→ 详细
• 但人工 review 一条没松：他明确说质量、可靠性和安全性都非常重要，所以所有东西还是要人过一遍眼——"agent 会全程帮忙，但每一处都经过人工 review"。→ 详细
• 成本账（原话数字，一个不改）：就他们这么个不大的团队，过去一个月用掉了 15 亿 token；跑了 3,300 次 Claude Code，按 token 计价折合每天 1 万美元——但他们买了套餐，所以并不是真的掏了这 1 万美元；Codex 的会话数是它的四倍，总体反而更便宜。所以目前绝大多数工作是通过 Codex 合并进去的，同时越来越多的活儿开始跑在 GLM 5.2 上，他们打算在这上面加大投入。→ 详细

• 他们最兴奋的下一步是自动路由。他先反问了一句很到位的话："你们大概听过'把任务路由给合适的模型'这类说法，但一个第三方凭什么知道该怎么给你的代码库做路由？"→ 详细
• 而在自己代码库上跑过基准，你就知道"在你的项目上、对哪类任务、哪个模型最好使"——他们接下来要基于这份数据帮你自动完成路由。→ 详细

▲ 图注：收尾三条建议原页：① 先把你的代码库 + agent 在沙箱里跑通；② 把 agent 接进所有人机界面，让它们能一起干活；③ 做基准测试、变成模型无关。

• 第一，把你的代码库和 agent 放进沙箱里跑起来——"它能解锁一大堆玩法和工作流，我今天讲的这些，还有更多。"→ 详细
• 第二，把 agent 接进人本来就在用的那些界面里，让团队和 agent 能一起干活，不用来回切上下文、把上下文复制来复制去。他说自家产品当然是他认为最好的做法，"但也有很多人是自己攒的、拿胶带糊出来的"——总之想办法把这件事做成，"不然摩擦成本真的太高了"。→ 详细
• 第三，找到一种做基准测试的办法，让自己变成模型中立的，这样你不会被任何一家绑死，"可以一直待在成本、速度、质量这条前沿曲线上最合适的位置"。→ 详细

• 现场：他们在大会展区有展台，欢迎过去聊；他演讲后也会在会场后方接受提问。→ 详细
• 注册网址与邮箱：⚠️ 这里正是文首那处公司名冲突的落点，两栏对不上，本报告照抄不合并、也不另行编造域名。
  • 英文字幕原文（t017）：注册用 superagent.com，邮箱 arjun@superagent.com。
  • 中文译稿同一处：写的是 superconductor.com 与 arjun@superconductor.com。
  • 视频标题和英文字幕开头（t001）用的又是 Superconductor。用之前请自己核实。→ 详细