如果一个编程 Agent 干活不错，很自然就会想到：那我同时开十个，是不是能快十倍？

理想中的画面是，一个修登录，一个补测试，一个改文档，剩下的去清工单。

实际情况可能是：两个改了同一个文件，三个在等 CI，还有一个拿着已经过时的代码，十分认真地修一个别人刚修完的问题。

模型回复很快，项目推进却没快多少。

OpenAI 最近公开的 Pando，碰到的就是这类“模型之外”的压力。北京时间 11 月 3 日 09:54，Greg Brockman 在 X 表示，团队正在考虑把这套 Git 后端提供给其他人，并征集兴趣。[1]

这里的新进展是对外提供的意向。技术文章此前已经发布；目前这句话也不等于服务已经开放注册，更不等于今天能直接安装一个官方 Pando 开源版。

图 1：根据 OpenAI 官方技术文章和开发者账号表述整理，属于其内部生产环境数据，不代表普通团队也能获得相同收益。

Pando 做的事情，和“再造一个 GitHub”不太一样

按照 OpenAI 的介绍，Pando 是新的 Git 仓库后端，服务于其 monorepo，也就是把大量项目代码放在一个大仓库中的开发方式。[2]

它的一个重点是保留 Git 协议和客户端兼容性，让工程师和 Agent 不必为了换后端，重新学习一套提交代码的方法。

官方披露，生产环境的中位 push 延迟降到了原来的约五分之一，开发者账号将其概括为下降约 80%；系统每天传输接近 1 PB 的 Git 数据。[2][3]

这两个数字很吸引人，不过先别急着拿自己几个人的小团队去对标。大仓库、大量分支和高频并行开发的负载，和个人项目不是一个量级。

真正有意思的是它暴露出的变化：当 Agent 把提交、拉取、分支操作的规模推高之后，原来还够用的底层系统，会先碰到自己的上限。

为什么模型更快了，团队却不一定更快

可以把一次代码交付拆成几段：理解需求、修改文件、跑测试、审查变更、合并、发布。

模型主要加速了其中一部分。剩下的步骤还得靠原来的系统和人接住。

比如以前一天只有十个改动，人工看一遍没问题。现在一天来一百个，即使每个改动的质量没有变差，审查队列也可能一下堆起来。

再比如，测试环境只能同时跑四组任务。你把 Agent 从四个加到二十个，可能只是让排队时间变长，并没有让机器多出四倍资源。

所以，我不太赞成只拿“生成了多少行代码”“一天提了多少个 PR”来衡量 AI 编程的收益。

这些是过程里的产出，不是用户真正收到的结果。

我更想看的是：从需求进入，到一项通过验收的变更合并，中间到底花了多久。

对普通团队来说，先别急着重写 Git

看到大公司重构底层系统，很容易产生一种冲动：是不是我们也得搭一套同款？

未必。你可能连真正堵在哪里都还没有记录。

我会先看几个很朴素的问题：

1. Agent 等模型的时间长，还是等测试的时间长？
2. 改动失败，主要是代码错了，还是任务范围没讲清楚？
3. 多个 Agent 有没有反复改同一片代码？
4. 人工审查花在业务逻辑上，还是花在清理无关修改上？
5. 合并之后的回滚和返工有没有增加？

如果答案是“需求经常变、任务互相踩、没人及时审”，换 Git 后端也解决不了多少问题。

先把任务边界和交付标准写清楚，可能比先购买更多模型额度有效。

模型接入可以统一，任务权限不能一锅端

这部分可以结合胜算云来做：把它作为模型调用层，按照官方 OpenAI 兼容 API 文档配置地址、Key 和账号中可用的完整模型 ID。现有的兼容调用代码，可以在这一层接入和比较模型。[4]

但模型接通之后，任务排队、文件范围、Git 分支、测试和人工审批，仍然是你自己的工程系统负责。

不要因为几名 Agent 用同一个服务入口，就顺手给它们同一套仓库写权限和部署凭证。

一个比较克制的起步方式是：先让模型提出修改计划，人看完之后再进入执行。下面的请求只要求规划两项任务，不让模型写文件、跑 Shell 或合并代码。

importjsonimportosimporturllib.request prompt=('为两个独立工单写修改计划，不执行任何操作。''工单 A：为登录校验补边界测试，只允许建议修改 tests/auth/。''工单 B：更新 API 文档，只允许建议修改 docs/api/。''分别列出文件范围、依赖、验收条件和需要人工确认的问题。''发现必须改动范围外文件时，标记需确认，不自行扩大范围。')request=urllib.request.Request('https://router.shengsuanyun.com/api/v1/chat/completions',data=json.dumps({'model':os.environ['SSY_MODEL'],'messages':[{'role':'user','content':prompt}],'stream':False,}).encode('utf-8'),headers={'Authorization':'Bearer '+os.environ['SSY_API_KEY'],'Content-Type':'application/json',},method='POST',)withurllib.request.urlopen(request,timeout=90)asresponse:result=json.load(response)print(result['choices'][0]['message'].get('content'))

运行前设置自己的环境变量，实际请求可能计费。示例中的两个工单是为了说明拆分方式，本文没有在真实仓库上执行它们。

更重要的是，提示词里的“只允许”只是告诉模型怎么规划。真正执行时，还得由应用检查实际改动文件，不能把模型的自觉当成权限控制。

让 Agent 分工，至少把三件事拆开

第一件是任务上下文。一个修改登录校验的 Agent，不需要顺手读完整个公司的资料库。上下文越宽，越不容易看清它到底依据什么做决定，也更难评估不必要的数据外发。

第二件是工作目录。独立分支和 worktree 可以减少不同任务对工作区的直接干扰，但要记住：worktree 不是安全沙箱。网络、数据库、共享服务和系统权限，不会因为换了目录就自动隔离。

第三件是验收。任务完成不能只看 Agent 回复了一句“已修复”。至少还要看到变更差异、相关测试结果，以及它有没有越过约定的文件范围。

图 2：适合小规模起步的交付流程建议，不是 Pando 的内部架构图。

如果再往前走一步，可以记录每项任务的请求次数、token 用量、等待时间和返工次数。不要把接口超时当成免费重来，更不要让多个 Agent 在失败时互相触发无限重试。

胜算云这一层能帮你接入文档所支持的模型接口；是否更便宜、更快，仍然要看你账号的模型、路由和实际账单，本文不做没有测试依据的承诺。

我的看法：AI 编程接下来更考验交付组织，而不只是写代码

我觉得 Pando 值得关注，不是因为每个团队都需要一套超大规模 Git 后端。

它提醒我们，Agent 的能力往前走之后，原来的协作流程会被放大检验。过去靠几个人随口协调能解决的问题，一旦换成几十个并行任务，就得变成明确的规则和可检查的记录。

有人负责提出变更，就得有人或系统负责验收；生成速度上去，测试和审查的吞吐也得跟上。

所以，下一次准备再多开几个 Agent 之前，不妨先问一句：它们交上来的东西，我们真的接得住吗？

能稳定合并一个有用的小改动，比同时生成十份没人敢合并的代码，更像真正的提效。

来源与接入说明

1. Greg Brockman：考虑向其他人提供 Pando，2026-11-03 09:54（北京时间）
2. OpenAI：Scaling Git at OpenAI
3. OpenAI Developers：Pando 的官方介绍
4. 胜算云 OpenAI 兼容 API 文档
5. AIHOT：Greg Brockman 对应条目

本文包含胜算云产品接入介绍。Pando 的性能数字为 OpenAI 自述；本文没有测试 Pando，也没有声称其已经对外开放。示例不执行代码修改，配图为说明图。

CSDN 标签：AI 编程、Git、OpenAI、Agent、软件工程、胜算云