多人协作智能体工程：让全团队与AI高效共舞的6条实践经验

在AI Engineer大会上，Superconductor联合创始人Arjun Singh分享了一个与众不同的视角。当大多数演讲都在讨论如何把智能体（Agent）放在一切的中心时，他选择聚焦于"人"——毕竟所有这些技术最终都是为了让我们的生活更好、效率更高。

智能体（Agent）在AI领域指的是能够自主感知环境、做出决策并执行行动的软件系统。与传统的聊天机器人不同，智能体具备多步推理、工具调用和任务规划能力。2024-2025年，随着大语言模型能力的飞跃，编码智能体（Coding Agent）成为软件工程领域最热门的应用方向——它们能够理解代码库、编写代码、运行测试、提交PR，逐步接管开发者的日常编程任务。

本文将系统梳理他提出的六条"多人协作智能体工程"（Multiplayer Agentic Engineering）实践经验。这些经验来自一个协作了十余年的团队：Arjun与联合创始人Sergey相识于伯克利博士项目，曾共同创办被全球数千所大学使用的Gradescope。Gradescope是一个AI驱动的评分和作业管理平台，于2014年在加州大学伯克利分校的研究中孵化，利用机器学习和计算机视觉技术辅助教师批改作业和考试，2018年被教育科技公司Turnitin收购。这一背景说明Arjun团队在AI产品化和大规模协作方面有超过十年的深厚积累。过去一年，他们激进地将智能体整合进日常工作流，逐一暴露并解决了各种瓶颈与摩擦点。

核心理念：让人融入智能体工作流

与"把智能体当作主角"的主流叙事不同，Arjun强调的核心是协作——如何让整个团队和最优秀的智能体高效共事，而不是让某个工程师被困在自己的笔记本前独自操作。

这个理念贯穿了他分享的六条经验。它们环环相扣，共同构成了一套面向团队的智能体工程方法论。

经验一：对模型与框架保持中立

第一条建议是保持模型和框架无关（model and harness agnostic）。理由有三：

在AI工程实践中，"模型无关"（model-agnostic）意味着系统架构不依赖于特定的大语言模型提供商（如OpenAI、Anthropic、Google等），而"框架无关"（harness-agnostic）则指不绑定特定的智能体编排框架（如LangChain、CrewAI等）。这种设计哲学源自软件工程中的"依赖倒置原则"和"适配器模式"——通过抽象层隔离外部依赖，使系统能够在底层技术快速迭代时保持稳定性和灵活性。

首先，最佳模型和框架可能每周都在变化——新模型发布，或旧的最优选项被下架。你不希望这些变动打乱整个团队的节奏。其次，开源权重模型现在已经相当不错，Arjun表示他们对GLM 5.2非常满意，而且成本低得多，值得探索和集成。GLM 5.2是智谱AI（Zhipu AI）推出的开源大语言模型系列的最新版本。近年来，开源权重模型的质量快速逼近闭源商业模型，代表性的还有Meta的Llama系列、Mistral、Qwen等。开源模型的优势在于：部署成本可控、可本地化运行、数据隐私有保障、且可针对特定场景微调。对于企业来说，混合使用开源和闭源模型已成为成本优化的主流策略。

最关键的一点是：卖你Token的人，其利益与你并不一致。他们希望你消耗更多Token，而你只想为达成目标所需的量付费。保持切换能力，才能让你掌控全局。

经验二：将每个人机界面变成"人+智能体"界面

通常，工程师与编码智能体协作时被困在自己的笔记本上，别人无法与该智能体对话。人们最先想到的扩展方式是Slack——Claude、Codex和Superconductor都有Slack机器人。这固然不错，但只是把智能体从"困在笔记本"变成了"困在Slack"。

Arjun团队真正想要的是：从任何相关界面操作同一个会话。一个典型流程可能是：在Slack发起并协作，转到桌面或移动App中以更工程化的方式继续，最后在GitHub收尾。关键在于——始终是同一个智能体会话、同一份上下文，智能体不会因为切换界面而"遗忘"之前做过的事。

这种设计理念类似于现代消息系统的"全平台同步"，但应用于AI协作场景时面临更大的技术挑战：需要维护跨界面的长期记忆、工具调用历史和代码执行状态，而不仅仅是同步聊天文本。

经验三：让智能体的工作对全团队可见且可协作

第二条经验的延伸，是让智能体的工作在团队中可见且可协作。在App视图中，你能看到所有参与过某个任务的人：Sergey创建的工单、Arjun的对话、增长团队成员的介入。

这在"非技术人员触发的工作"场景中尤为重要——比如客服人员创建了一个工单，你想知道它是否已被工程师审核。审查时，你可以直接介入询问智能体"为什么这样做"，而无需等待同事回复，因为答案几乎肯定就在这个会话线程里。

最常用的可见化方式是产物（artifacts）：无论工作从哪里开始或结束，智能体都能以截图、视频等形式展示成果，且在任何界面都能看到。工作处处可见，随处可协作。

经验四：把每个外部信号转化为可快速评估的代码

所谓"外部信号"，可能是Slack对话、客户会议、销售电话、内部会议、Sentry的错误报告，或邮件里的功能请求。这些信息散落在各个系统里，人们用MCP把它们连接起来，但智能体依然不知道该优先做什么，仍需大量人工协调。

MCP（Model Context Protocol）是Anthropic于2024年底发布的开放协议标准，旨在统一AI模型与外部数据源、工具之间的连接方式。它类似于AI领域的"USB-C接口"，让模型能够以标准化的方式访问数据库、API、文件系统等外部资源。MCP的出现解决了此前各家模型各自定义工具调用格式带来的碎片化问题，但正如文中所述，连接数据源只是第一步——如何让智能体理解优先级和上下文仍需额外的编排逻辑。

Superconductor的做法是自动摄取这些信号、排定优先级并采取行动。Arjun最喜欢的是会议机器人（meeting bot）：在展会现场，它全天监听一场四小时的Google Meet，一边听一边创建各种工作项。如果发现已有相关工作，它会自动关联而非重复创建。

一个真实案例：有人提出"希望智能体在告知完成前有明确的验收标准"，机器人自动捕捉到这个想法，创建工单并开始工作，还修改了工单表单，新增了"验收标准"字段。虽然未必会原样上线，但这是一个具体、可玩、可验证的新想法。Arjun表示，每次客户通话或团队会议后，他们几乎都能得到数十个原型化的新想法，以及几个只需极少干预就能上线的PR。

经验五：让工作流运行在隔离的云端环境

前述三条经验都依赖一个前提：让代码库和项目在隔离的云环境中运行，而非困在个人机器上。这样做有三重价值。

消除"合盖焦虑"

你能看到会议上、机场里、甚至开车时有人打开笔记本、连着手机热点等待任务完成。Arjun坦言，这正是他当初开始做这件事的动因——当时他家有个六个月大的孩子，不想被笔记本束缚。搬到云端后，任务始终在运行，焦虑随之消失。

最小权限原则

这是最重要的一点。智能体越来越自主、越来越"想取悦你"，当你说"清空staging数据库"，它可能在你笔记本上找到一个它以为是staging、实则是生产环境的Token，然后删光一切。Arjun直言："我不是说这在发生——它一直在发生。"

最小权限原则（Principle of Least Privilege）是信息安全的基础原则之一，要求任何实体只应拥有完成其任务所需的最小权限集合。在智能体工程中，这一原则变得尤为关键：大语言模型具有"讨好用户"（sycophancy）的倾向，可能在执行模糊指令时过度行动。网络沙箱（Network Sandbox）通过容器化技术和细粒度的网络策略，将智能体的可达范围严格限定在预授权的服务和数据中，防止意外的数据泄露或破坏性操作。

通过可配置的网络沙箱，你能精确限定智能体可访问的范围；一旦它尝试访问不该访问的地方，系统会弹窗请求授权，还可按工单粒度授予权限，既防止数据外泄，又保留灵活性。

让非技术成员触发真实工作

客服、增长人员没有开发环境，但通过Slack或App直接说"修复这个"，智能体就能完成、展示截图、由工程师合并——省去了传统流程中提工单、排期、分类的所有环节。

经验六：用你的代码库来评测智能体

最后一条经验是在自己的代码库上对智能体做基准测试。方法是：挑选代表优秀工程实践的PR（无论是智能体、人类还是混合产出），选定要评测的智能体，然后得到"质量 vs 成本"和"质量 vs 时间"的对比。

为什么必须这样做？因为公开基准（SWE-Bench、TerminalBench等）的任务可能与你的完全无关。SWE-Bench是普林斯顿大学于2023年发布的软件工程基准测试集，从12个流行的Python开源项目中提取了2294个真实的GitHub Issue和对应的Pull Request，用于评估AI系统解决实际软件工程问题的能力。TerminalBench则侧重于命令行环境下的系统管理和DevOps任务评测。这些公开基准虽然推动了领域进步，但其任务分布、编程语言和代码风格可能与特定企业的代码库存在显著差异——比如SWE-Bench全是Python，而Superconductor用的是Ruby on Rails，结果差异巨大。

在他们自己的代码库上，Arjun观察到：Anthropic的智能体质量持续提升但速度没变，且成本明显更高；Cursor中的Codex又快又好，成本更低；开源方案在稳步改进但偏慢。Codex是OpenAI推出的编码智能体产品，可在云端独立执行编码任务，强调异步执行和成本效率。Claude Code则是Anthropic推出的终端编码助手，以交互式的命令行体验为主，强调代码质量和安全推理。两者代表了编码智能体的两种设计范式：Codex偏向"自主完成后交付"，Claude Code偏向"人机协作实时推进"。这些硬数据与团队的"直觉判断"吻合后，他们把默认选项切换到了Codex。由于保持了模型中立，这种切换毫无摩擦。

这也解决了另一种"焦虑"：听说Minimax、GLM、Kimi K2都很好却没时间试，评测机制让你能无缝保持在成本、速度、质量的前沿。

数据佐证与前瞻

Arjun给出了一组令人印象深刻的数据：他们约99.9%的PR都是高度由智能体生成的，但出于质量、可靠性和安全考虑，所有代码仍由人类审查。

作为一个相对小的团队，他们过去一个月消耗了105亿Token：3,300次Claude Code运行折合1万美元Token成本；Codex的会话数是其四倍，整体却更便宜——因此目前绝大多数工作通过Codex合并，同时越来越多任务转向GLM 5.2。

Token是大语言模型处理文本的基本计量单位，通常一个英文单词约对应1-2个Token。105亿Token的月消耗量意味着极高强度的AI使用。以Claude 3.5 Sonnet为例，输入约3美元/百万Token、输出约15美元/百万Token，大规模使用时成本可达数万美元/月。这解释了为什么模型中立策略和成本-质量评测对于高强度使用AI的团队至关重要——选择不同模型可能带来数倍的成本差异。

展望未来，他们最兴奋的方向是自动化任务路由：与其让第三方猜测该为你的代码库路由到哪个模型，不如基于你自己的评测数据，自动为每类任务匹配最合适的模型。这种"智能路由"的逻辑类似于CDN中的最优路径选择——根据任务复杂度、语言特性、上下文长度等维度，动态分配到性价比最优的模型。

三条可立即落地的建议

Arjun最后总结了三条可立即执行的建议：

1. 让代码库和智能体在沙箱中运行——这解锁了前述所有工作流；即便不用他们的产品，用Claude Code或Codex也能实现。
2. 将智能体集成到相关的人机界面——让团队与智能体协作，避免反复切换上下文、来回复制。
3. 建立评测机制、保持模型中立——不被任何供应商绑定，始终立于前沿。

这套方法论的价值不在于某个具体工具，而在于它重新定位了智能体时代的团队协作：智能体不是取代人的主角，而是嵌入每个人机界面、对全团队可见、由人类最终把关的协作伙伴。

核心要点