1. 三条新闻背后的行业信号拆解
1.1 为什么这三件事值得放在一起看
2026年8月31日这一天，AI圈同时冒出三条消息：Uber用Agent接管了70%的代码PR、OpenAI终止与Cursor的合作、智谱开源GLM-5.3。单看每一条都是独立事件，但放在一起看，它们指向的是同一个趋势——AI Agent正在从"辅助工具"变成"生产主力"，而围绕它的生态格局也在剧烈重组。
我关注这几个方向有一段时间了，说实话，Uber这个70%的数字比我预想的来得更早。代码PR这个场景之所以率先被Agent攻占，原因很直接：它有明确的输入输出、有自动化测试做验证、有版本控制做回滚。这三个条件凑齐，Agent就能形成闭环。相比之下，客服、运营、数据分析这些场景虽然也在上Agent，但验证环节没这么干净，落地速度就慢一截。
OpenAI和Cursor的分手则说明另一件事：当模型厂商自己开始做应用层，中间商的生存空间会被急剧压缩。Cursor本质上是在OpenAI的模型能力上做了一层交互封装，当OpenAI自己推出Codex这类命令行Agent工具时，这层封装的价值就被重新定价了。这不是谁对谁错的问题，是产业链位置决定的。
GLM-5.3开源则是第三条线——开源模型正在把Agent能力变成公共基础设施。以前你要搭一个能跑Agent的模型，要么用闭源API烧钱，要么自己训一个。现在开源模型的能力上来了，中小团队也能在自己的机器上跑Agent，数据不出内网，成本可控。
1.2 这三条线对普通开发者意味着什么
如果你是一个正在用Cursor写代码的开发者，OpenAI终止合作这件事短期内可能让你担心工具会不会变卡、功能会不会缩水。但实际影响没那么大——Cursor早就开始接入多家模型了，Claude、GPT、自家微调模型都在用。真正需要关注的是：你依赖的那个"AI帮我写代码"的入口，未来会不会被模型厂商自己收回去。
如果你是一个在搭Agent系统的团队，Uber的案例值得逐帧拆解。70%这个数字背后，是哪些类型的PR被接管了？哪些还留在人工手里？他们的Agent架构是怎么设计的？验证环节怎么做的？这些细节比数字本身更有参考价值。
如果你是一个关注成本的技术负责人，GLM-5.3开源意味着你多了一个可选项。以前Agent跑起来token消耗大，用闭源API月底账单吓人。现在开源模型能力追上来一截，你可以把一些非核心的Agent任务放到自部署模型上跑，核心任务再走闭源API，成本结构会健康很多。
2. Uber的Agent接管70%代码PR：拆解与复现思路
2.1 70%这个数字到底覆盖了什么
先说清楚，Uber说的"70%代码PR"不是指70%的代码由AI从零写出来。根据我看到的公开信息和行业惯例，这个数字更可能指的是：在代码变更流程中，Agent能够独立完成从修改到提交PR的完整闭环，且不需要人工介入修改的比例。
这里面有几个关键限定条件需要搞清楚：
- PR的类型分布：大概率集中在依赖升级、配置修改、简单bug修复、测试用例补充、日志埋点这类模式化程度高的变更上。涉及核心业务逻辑重构、架构调整、性能优化的PR，Agent很难独立完成。
- 验证标准：Agent提交的PR必须通过CI流水线，包括单元测试、集成测试、lint检查、类型检查。如果测试挂了，Agent需要能自己读报错、定位问题、重新修改，直到通过或者达到重试上限后转人工。
- 人工介入的边界：70%不需要人工介入，意味着30%的PR要么是Agent做不了直接转人工，要么是Agent做了但人工review时打回重做。
我自己的经验是，在一个中等规模的代码库里（10万行左右），如果CI覆盖率达到80%以上，Agent能独立完成的PR比例大概在40%-60%之间。Uber能做到70%，说明他们的CI覆盖率和Agent的自我修复能力都做得相当到位。
2.2 Agent接管PR的架构应该怎么设计
如果要复现Uber这套东西，核心架构大概分四层：
第一层：任务接入层。Agent需要知道"现在要做什么"。输入来源可能是Jira ticket、GitHub issue、监控告警、或者定时任务。这一层要做的是把非结构化的需求转成结构化的任务描述，包括：改哪个文件、改什么、预期行为是什么、怎么验证。
第二层：代码理解与修改层。这是Agent的核心。它需要能读代码库、理解上下文、定位到需要修改的位置、生成修改方案。这里的关键是上下文管理——一个10万行的代码库不可能全塞进prompt里，需要做检索增强。常见做法是用代码embedding做语义检索，找到相关文件和相关函数，再结合调用关系图做上下文扩展。
第三层：验证与修复层。Agent改完代码后，自动跑CI。如果挂了，Agent要能读报错日志，判断是语法错误、逻辑错误还是测试用例本身的问题，然后决定是重新修改还是转人工。这一层的重试策略很关键——重试次数太少容易放弃，太多容易陷入死循环。我见过比较合理的配置是：语法错误重试3次，逻辑错误重试2次，测试用例问题重试1次，超过就转人工。
第四层：PR生成与提交层。Agent把修改提交成PR，附带变更说明、测试结果、影响范围分析。这一层要做的是让PR看起来像人写的——commit message规范、变更描述清晰、关联到原始ticket。
2.3 实操中容易踩的坑
坑一：Agent改代码改出"蝴蝶效应"。一个函数改了签名，调用它的地方全挂了。Agent如果只盯着当前文件，很容易漏掉下游影响。解决办法是在修改前先做影响面分析，把调用链上的文件都拉进上下文。
坑二：测试用例是Agent自己写的，自己测自己。这会导致Agent写出的代码和测试用例互相"配合"，但实际业务逻辑是错的。解决办法是测试用例必须来自独立来源——要么是人工写的，要么是从历史PR里提取的，不能让Agent同时生成代码和测试。
坑三：Agent提交的PR太多，review的人看不过来。70%的PR由Agent提交，如果每个都要人工review，那人工工作量反而增加了。Uber的做法大概率是分级review——低风险的PR（依赖升级、日志修改）自动合并，中风险的PR（业务逻辑修改）人工抽检，高风险的PR（核心模块）必须人工全检。
提示：如果你在团队里推Agent接管PR，建议先从"依赖升级"这个场景切入。它模式固定、风险低、验证简单，最容易跑通闭环，也最容易让团队建立信心。
3. OpenAI终止与Cursor合作：生态位重组的逻辑
3.1 这件事的本质是什么
OpenAI和Cursor的关系，本质上是模型供应商和模型应用商的关系。Cursor用OpenAI的模型能力，包装成一个代码编辑器产品卖给开发者。这个模式在早期是双赢的——OpenAI拿到了API调用量，Cursor拿到了产品收入。
但当OpenAI自己推出Codex这类命令行Agent工具时，关系就变了。Codex直接面向开发者，提供"用自然语言写代码"的能力，这和Cursor的核心功能高度重叠。这时候OpenAI面临一个选择：继续给Cursor供模型，让它跟自己竞争；还是收紧合作，把用户往自己的工具上引。
从商业逻辑上看，OpenAI的选择不难理解。模型厂商往下游走，应用厂商往上游走，这是AI行业正在发生的双向挤压。Cursor也在做自己的模型微调，OpenAI也在做自己的编辑器，双方都在往对方的地盘渗透。
3.2 对开发者的实际影响
短期来看，影响有限。Cursor已经接入了多家模型，OpenAI只是其中之一。你打开Cursor写代码，它可能用Claude、可能用GPT、可能用自家模型，你感知不到区别。
中期来看，需要关注的是功能迭代速度。如果OpenAI不再给Cursor提供最新模型的优先访问权，Cursor在新模型适配上的速度可能会慢一拍。比如OpenAI出了个新模型，Codex第一时间用上，Cursor可能要等几周才能接入。
长期来看，开发者需要避免被单一工具锁定。我的建议是：不要把工作流完全绑在任何一个AI编程工具上。你可以用Cursor做日常开发，但同时保持对Codex、Claude Code、通义灵码等工具的熟悉度。工具会变，但"用自然语言描述需求、让AI生成代码、人工验证"这个工作流不会变。
3.3 从这件事看AI编程工具的选型逻辑
选AI编程工具，我一般看四个维度：
| 维度 | 关键问题 | 权重建议 |
|---|---|---|
| 模型能力 | 用的什么模型？更新频率如何？ | 30% |
| 上下文管理 | 能读多大的代码库？检索准不准？ | 25% |
| 工作流集成 | 和Git、CI、IDE的集成顺不顺？ | 25% |
| 数据安全 | 代码会不会被用于训练？能不能私有部署？ | 20% |
Cursor在模型能力和工作流集成上一直做得不错，但数据安全是它的弱项——代码要传到云端。Codex作为OpenAI自家工具，数据安全同样依赖OpenAI的政策。如果你对代码安全要求高，可以考虑自部署方案，比如用GLM-5.3这类开源模型搭一个本地的代码Agent。
4. 智谱开源GLM-5.3：Agent能力的基础设施化
4.1 GLM-5.3开源意味着什么
智谱开源GLM-5.3，最直接的影响是降低了Agent开发的门槛。以前你要搭一个能跑Agent的模型，要么用闭源API（成本高、数据出内网），要么自己训一个（技术门槛高、算力投入大）。现在有了一个能力不错的开源模型，你可以：
- 在自己的服务器上部署，数据不出内网
- 针对自己的业务场景做微调，提升特定任务的准确率
- 把Agent的推理成本从"按token付费"变成"按算力付费"，长期来看成本更低
从技术指标上看，GLM-5.3这一代在代码生成、工具调用、多轮对话上的能力比上一代有明显提升。尤其是工具调用（function calling）这个能力，对Agent来说至关重要——Agent要能调API、读文件、执行命令，靠的就是这个。
4.2 用开源模型搭Agent的实操路径
如果你手头有一台带GPU的服务器（比如一张24G显存的卡），可以按这个路径走：
第一步：部署模型。用vLLM或者TGI这类推理框架把GLM-5.3跑起来。24G显存大概能跑量化后的版本，推理速度够用。部署命令大概长这样：
python -m vllm.entrypoints.openai.api_server \ --model THUDM/glm-5.3 \ --dtype auto \ --max-model-len 8192 \ --gpu-memory-utilization 0.9第二步：搭Agent框架。Agent的核心循环是"观察-思考-行动"。你可以用LangChain、AutoGPT这类现成框架，也可以自己写一个轻量的循环。我倾向于自己写，因为现成框架抽象层太多，调试起来麻烦。一个最简的Agent循环大概是这样：
while not done: # 观察：获取当前状态 observation = get_current_state() # 思考：让模型决定下一步 action = model.generate(observation, tools) # 行动：执行模型选择的工具 result = execute_tool(action) # 更新状态 update_state(result)第三步：接入工具。Agent能做什么，取决于你给它什么工具。常见的工具包括：读写文件、执行shell命令、调用API、查询数据库。每个工具都要有清晰的描述，让模型知道什么时候该用哪个。
第四步：加安全护栏。Agent能执行命令，就意味着它可能执行危险命令。必须加护栏：危险命令（rm -rf、drop table）直接拦截，敏感操作（修改生产配置）需要人工确认，所有操作记日志。
4.3 开源模型跑Agent的注意事项
注意一：量化会损失能力。为了在消费级显卡上跑，通常要做量化（4bit或8bit）。量化后模型在简单任务上表现差不多，但在复杂推理和工具调用上会打折扣。如果要做生产级Agent，建议用FP16或BF16精度，显存不够就上多卡。
注意二：上下文长度是瓶颈。Agent跑起来后，对话历史、工具返回结果、代码上下文都会塞进prompt，很容易超长。GLM-5.3支持8K上下文，实际用起来要精打细算。我的做法是：只保留最近3轮对话，工具返回结果做摘要，代码上下文用检索而不是全量塞入。
注意三：推理速度影响体验。Agent是多轮循环，每一轮都要等模型输出。如果模型推理慢，整个Agent跑起来就卡。24G卡跑量化版GLM-5.3，大概每秒20-30个token，一个简单的代码修改任务可能要跑10-20轮，总耗时几分钟。这个速度做后台任务可以，做交互式编程就有点慢。
5. 从这三条新闻看Agent开发的当前格局
5.1 模型层：开源和闭源的差距在缩小
GLM-5.3开源这件事，加上之前Llama系列、Qwen系列的迭代，说明开源模型和闭源模型的能力差距正在从"代差"变成"版本差"。闭源模型仍然领先，但领先的幅度在收窄。对于Agent开发来说，这意味着你有了更多选择——核心任务用闭源模型保效果，边缘任务用开源模型降成本。
5.2 应用层：通用工具和垂直工具的竞争
OpenAI做Codex、Cursor做编辑器、Uber做内部Agent平台，这三件事代表三种不同的应用层策略。OpenAI是模型厂商往下做通用工具，Cursor是创业公司做垂直工具，Uber是大厂做内部工具。三种策略各有优劣：通用工具覆盖面广但深度不够，垂直工具深度够但容易被模型厂商降维打击，内部工具贴合业务但复用性差。
对普通开发者来说，做垂直场景的Agent仍然有机会。通用工具解决的是80%的通用需求，剩下20%的垂直需求（比如特定行业的代码规范、特定业务的自动化流程）通用工具覆盖不到，这就是机会。
5.3 基础设施层：Agent运行时的标准化
Agent跑起来需要一套运行时环境：模型推理、工具调用、状态管理、安全护栏、日志监控。目前这块还没有形成标准，每个团队都在自己搭。但趋势是Agent运行时正在从"手工作坊"走向"标准化组件"。LangChain、LlamaIndex这些框架在做抽象，vLLM、TGI这些推理框架在做性能优化，未来一两年应该会出现更成熟的Agent基础设施。
6. 实操建议：现在就可以做的事
6.1 如果你在用Cursor
检查一下你的工作流里有多少环节依赖Cursor的特定功能。如果只是"用自然语言生成代码片段"，那换任何工具都行。如果依赖了Cursor的特定插件或工作流，建议提前准备备选方案。同时，把Cursor的语言设置成中文这件事，在设置里搜"language"就能找到，不用折腾配置文件。
6.2 如果你在搭Agent
先从一个小场景跑通闭环，不要一上来就做通用Agent。选场景的标准是：有明确的输入输出、有自动化的验证手段、失败的成本可控。代码PR、数据清洗、报表生成、测试用例补充，这些都是不错的切入点。
6.3 如果你在选模型
做一个简单的对比测试：拿你实际的Agent任务，分别用闭源API和开源模型跑一遍，对比成功率、耗时、成本。如果开源模型在成功率上差距在10%以内，成本又低很多，那就值得切。如果差距超过20%，说明任务对模型能力要求高，还是用闭源模型稳。
6.4 如果你在关注成本
Agent的token消耗比普通对话大得多，因为有多轮循环和大量上下文。一个简单的代码修改任务，可能消耗几万token。如果用闭源API，成本会很快累积。建议的做法是：把Agent的任务分级，简单任务走开源模型，复杂任务走闭源模型。同时优化prompt，减少不必要的上下文。
7. 几个常见问题的排查思路
7.1 Agent执行到一半报错终止
这是最常见的问题。报错信息通常是"agent execution terminated due to error"。排查思路：
- 先看是模型输出格式错误，还是工具调用失败。模型输出格式错误的话，检查prompt里的格式约束是否清晰，或者加一个输出解析的重试机制。
- 工具调用失败的话，看是工具本身报错，还是参数传错了。工具本身报错要修工具，参数传错要优化工具描述。
- 如果两者都不是，可能是上下文超长了。检查一下当前prompt的token数，超过模型上限的话要做截断或摘要。
7.2 模型不调用工具，直接编答案
这是Agent开发里的经典问题。模型倾向于直接生成答案，而不是调用工具去获取信息。解决办法：
- 在system prompt里明确要求"必须先调用工具获取信息，再基于工具返回结果回答"
- 给模型展示few-shot示例，让它看到"调用工具→获取结果→回答"的完整流程
- 如果模型仍然不调用，可以在工具描述里加"当用户询问X时，必须使用此工具"
7.3 Agent陷入循环，反复做同一件事
Agent执行一个动作，得到结果，发现没达到目标，又执行同一个动作，如此循环。解决办法：
- 加一个动作历史记录，如果连续3次执行相同动作，强制中断
- 在prompt里加"如果上一次动作没有产生预期效果，尝试不同的方法"
- 设置最大循环次数，超过就转人工
7.4 开源模型工具调用能力弱
开源模型在function calling上的表现通常比闭源模型差一截。如果发现模型经常调错工具或参数格式不对，可以：
- 用few-shot示例教它正确的调用格式
- 把工具描述写得更详细，包括参数类型、取值范围、示例
- 如果还是不行，考虑用闭源模型做工具调用，开源模型做其他任务
8. 我个人在实际操作中的几点体会
搭Agent这件事，我踩过的坑比走过的路还多。最大的体会是：Agent的能力上限不取决于模型，取决于验证环节。模型再强，如果验证环节跟不上，Agent就不敢放手做事。Uber能做到70%，核心不是他们的模型比别人强多少，是他们的CI流水线足够完善，Agent改完代码能立刻知道对不对。
另一个体会是：不要追求100%自动化。70%已经是很高的比例了，剩下30%人工介入不是失败，是必要的安全边际。我见过一些团队非要追求全自动，结果Agent改出问题没人发现，最后回滚的成本比人工review高得多。
最后一个体会是关于工具选型的：不要被工具绑定。今天用Cursor，明天可能用Codex，后天可能用自部署的开源方案。保持工作流的可迁移性，比选一个"最好的工具"更重要。你的核心资产是"知道怎么让AI帮你干活"这件事本身，而不是某个具体的工具。
