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修复、测试用例补充、日志埋点这类模式化程度高的变更上。涉及核心业务逻辑重构、架构调整、性能优化的PRAgent很难独立完成。验证标准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.3Agent能力的基础设施化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帮你干活这件事本身而不是某个具体的工具。 AI Agent接管70%代码PR：从Uber案例到开源模型GLM-5.3的Agent开发实战
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修复、测试用例补充、日志埋点这类模式化程度高的变更上。涉及核心业务逻辑重构、架构调整、性能优化的PRAgent很难独立完成。验证标准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.3Agent能力的基础设施化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帮你干活这件事本身而不是某个具体的工具。