如果一个编程 Agent 干活不错很自然就会想到那我同时开十个是不是能快十倍理想中的画面是一个修登录一个补测试一个改文档剩下的去清工单。实际情况可能是两个改了同一个文件三个在等 CI还有一个拿着已经过时的代码十分认真地修一个别人刚修完的问题。模型回复很快项目推进却没快多少。OpenAI 最近公开的 Pando碰到的就是这类“模型之外”的压力。北京时间 11 月 3 日 09:54Greg 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看到大公司重构底层系统很容易产生一种冲动是不是我们也得搭一套同款未必。你可能连真正堵在哪里都还没有记录。我会先看几个很朴素的问题Agent 等模型的时间长还是等测试的时间长改动失败主要是代码错了还是任务范围没讲清楚多个 Agent 有没有反复改同一片代码人工审查花在业务逻辑上还是花在清理无关修改上合并之后的回滚和返工有没有增加如果答案是“需求经常变、任务互相踩、没人及时审”换 Git 后端也解决不了多少问题。先把任务边界和交付标准写清楚可能比先购买更多模型额度有效。模型接入可以统一任务权限不能一锅端这部分可以结合胜算云来做把它作为模型调用层按照官方 OpenAI 兼容 API 文档配置地址、Key 和账号中可用的完整模型 ID。现有的兼容调用代码可以在这一层接入和比较模型。[4]但模型接通之后任务排队、文件范围、Git 分支、测试和人工审批仍然是你自己的工程系统负责。不要因为几名 Agent 用同一个服务入口就顺手给它们同一套仓库写权限和部署凭证。一个比较克制的起步方式是先让模型提出修改计划人看完之后再进入执行。下面的请求只要求规划两项任务不让模型写文件、跑 Shell 或合并代码。importjsonimportosimporturllib.request prompt(为两个独立工单写修改计划不执行任何操作。工单 A为登录校验补边界测试只允许建议修改 tests/auth/。工单 B更新 API 文档只允许建议修改 docs/api/。分别列出文件范围、依赖、验收条件和需要人工确认的问题。发现必须改动范围外文件时标记需确认不自行扩大范围。)requesturllib.request.Request(https://router.shengsuanyun.com/api/v1/chat/completions,datajson.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,},methodPOST,)withurllib.request.urlopen(request,timeout90)asresponse:resultjson.load(response)print(result[choices][0][message].get(content))运行前设置自己的环境变量实际请求可能计费。示例中的两个工单是为了说明拆分方式本文没有在真实仓库上执行它们。更重要的是提示词里的“只允许”只是告诉模型怎么规划。真正执行时还得由应用检查实际改动文件不能把模型的自觉当成权限控制。让 Agent 分工至少把三件事拆开第一件是任务上下文。一个修改登录校验的 Agent不需要顺手读完整个公司的资料库。上下文越宽越不容易看清它到底依据什么做决定也更难评估不必要的数据外发。第二件是工作目录。独立分支和 worktree 可以减少不同任务对工作区的直接干扰但要记住worktree 不是安全沙箱。网络、数据库、共享服务和系统权限不会因为换了目录就自动隔离。第三件是验收。任务完成不能只看 Agent 回复了一句“已修复”。至少还要看到变更差异、相关测试结果以及它有没有越过约定的文件范围。图 2适合小规模起步的交付流程建议不是 Pando 的内部架构图。如果再往前走一步可以记录每项任务的请求次数、token 用量、等待时间和返工次数。不要把接口超时当成免费重来更不要让多个 Agent 在失败时互相触发无限重试。胜算云这一层能帮你接入文档所支持的模型接口是否更便宜、更快仍然要看你账号的模型、路由和实际账单本文不做没有测试依据的承诺。我的看法AI 编程接下来更考验交付组织而不只是写代码我觉得 Pando 值得关注不是因为每个团队都需要一套超大规模 Git 后端。它提醒我们Agent 的能力往前走之后原来的协作流程会被放大检验。过去靠几个人随口协调能解决的问题一旦换成几十个并行任务就得变成明确的规则和可检查的记录。有人负责提出变更就得有人或系统负责验收生成速度上去测试和审查的吞吐也得跟上。所以下一次准备再多开几个 Agent 之前不妨先问一句它们交上来的东西我们真的接得住吗能稳定合并一个有用的小改动比同时生成十份没人敢合并的代码更像真正的提效。来源与接入说明Greg Brockman考虑向其他人提供 Pando2026-11-03 09:54北京时间OpenAIScaling Git at OpenAIOpenAI DevelopersPando 的官方介绍胜算云 OpenAI 兼容 API 文档AIHOTGreg Brockman 对应条目本文包含胜算云产品接入介绍。Pando 的性能数字为 OpenAI 自述本文没有测试 Pando也没有声称其已经对外开放。示例不执行代码修改配图为说明图。CSDN 标签AI 编程、Git、OpenAI、Agent、软件工程、胜算云