企业官网建设流程全解析

1. 三条新闻背后的同一条暗线：Agent 正在从"辅助"变成"主力"

2026年8月31日这一天，AI 圈子里有三条消息几乎同时刷屏：Uber 内部用 Agent 接管了 70% 的代码 PR、OpenAI 终止了与 Cursor 的合作、智谱开源了 GLM-5.3。单看每一条都是独立事件，但把它们摆在一起看，你会发现它们指向的是同一个趋势——Agent 正在从"帮人打下手"变成"独立干活的主力"。

先说 Uber 这条。70% 的代码 PR 由 Agent 接管，这个数字不是"AI 帮你写了几行代码补全"，而是从需求理解、代码生成、测试编写到提交 PR 的完整链路，Agent 都在参与。这意味着什么？意味着在 Uber 的工程体系里，Agent 已经不是一个"锦上添花的插件"，而是流水线上的一个正式工位。工程师的角色从"写代码的人"变成了"审代码的人"和"定规则的人"。

再说 OpenAI 终止与 Cursor 合作这条。Cursor 是过去两年最火的 AI 编程工具之一，它的核心能力很大程度上依赖 OpenAI 的模型。合作终止这件事，表面看是商业关系变化，深层看是模型厂商开始自己下场做 Agent 产品。当模型能力足够强的时候，"套壳"工具的生存空间会被压缩，因为模型厂商可以直接把 Agent 能力做进自己的产品里。这对做 Agent 开发的团队是一个明确的信号：光靠调用 API 做包装是不够的，你得有自己的编排逻辑和场景壁垒。

第三条，智谱开源 GLM-5.3。开源这件事在 Agent 时代的意义被放大了。因为 Agent 要真正落地到企业里，绕不开数据安全、私有化部署、成本控制这几个问题。一个能本地跑、能微调、能自己掌控的开源模型，对做 Agent 项目的团队来说，是"能不能上生产"的关键变量。GLM-5.3 的开源，让国内做 Agent 的团队多了一个不依赖外部 API 的底座选择。

把这三条串起来，我想说的是：2026 年的 Agent 已经不是概念了，它正在变成工程实践里的基础设施。如果你还在观望"Agent 到底能不能用"，那可能已经慢了一步。下面我按这三条新闻分别拆开讲，重点讲清楚每一条背后的技术逻辑、对从业者的实际影响，以及可以怎么落地。

2. Uber 的 70% PR 接管：Agent 在工程流水线里到底站在哪个位置

2.1 70% 这个数字是怎么算出来的，别被标题带偏

先泼一盆冷水。"Uber 用 Agent 接管 70% 代码 PR"这个说法，如果理解成"70% 的代码是 AI 写的、人不管了"，那是误读。更合理的理解是：在 Uber 的 PR 流程中，有 70% 的 PR 在提交前经过了 Agent 的处理——可能是 Agent 生成的初稿、Agent 做的代码审查、Agent 补的测试用例，或者 Agent 做的重构建议。

这个区别很重要。因为"接管"和"生成"是两回事。接管意味着 Agent 进入了工作流，但不等于人退出了。实际上，越是成熟的工程团队，越会把 Agent 放在"可验证"的位置上——Agent 产出，人审核，CI/CD 把关。70% 这个数字真正说明的是：Agent 已经跨过了"玩具阶段"，进入了能稳定产出可合并代码的阶段。

那为什么是 Uber 先跑出来？我的判断是三个条件同时满足了：一是代码库足够大、模式足够多，Agent 有足够的学习和适配空间；二是工程规范足够成熟，有完善的测试和 CI 体系来兜底；三是内部有动力去压降重复性工作的成本。这三个条件缺一个，Agent 都很难跑到 70% 这个量级。

2.2 Agent 接管 PR 的典型链路拆解

一个 Agent 要能接管 PR，它得走完下面这条链路。我把每一环的关键点和坑都标出来：

这张表里，我认为最容易被低估的是"代码定位"和"测试编写"。很多人以为 Agent 的难点在生成代码，其实生成是最容易的一环，因为大模型写代码的能力已经很强了。真正难的是：在一个几十万行的仓库里，准确找到该改的地方，并且改完之后不破坏别的东西。Uber 能做到 70%，说明他们在这两个环节上下了大功夫——大概率是做了仓库级的检索增强，以及一套严格的测试门禁。

2.3 想让 Agent 接管 PR，你的仓库得先"可被 Agent 理解"

这是我最想强调的一点。很多团队看到 Uber 的新闻，回去就想让自己的 Agent 也接管 PR，结果发现 Agent 老是改错地方、老是引入 bug。问题往往不在 Agent，而在仓库本身对 Agent 不友好。

什么叫"对 Agent 友好"？我列几个实操层面的判断标准：

• 目录结构清晰：Agent 靠路径和命名来理解代码归属，如果目录是utils1、utils2、misc这种，Agent 基本抓瞎。
• 有明确的模块边界：每个模块有 README 或者 docstring 说明职责，Agent 才能判断"这个改动该放哪"。
• 测试覆盖到位：Agent 改完代码，得有测试告诉它"你改坏了没有"。没有测试的仓库，Agent 就是个盲人。
• 提交历史规范：Agent 会参考历史 PR 来学习"这个项目怎么改代码"，如果历史提交都是"fix"、"update"这种，Agent 学不到东西。

提示：如果你打算让 Agent 介入 PR 流程，先花两周把仓库的目录结构和测试覆盖率整理一遍。这个投入的回报比调 Agent 的 prompt 高得多。

2.4 人在这条链路里的角色变了，但没消失

Agent 接管 70% 的 PR，不代表工程师没事干了。恰恰相反，工程师的工作重心发生了转移：

• 从"写实现"转向"定接口和约束"——你得把需求拆得足够清楚，Agent 才能执行。
• 从"写测试"转向"审测试"——Agent 写的测试可能覆盖了但没测到点子上，需要人来判断。
• 从"改 bug"转向"定规范"——Agent 反复犯的错，往往是因为规范没写清楚。

我自己的体会是，Agent 越强，对"把问题说清楚"的能力要求越高。以前你可以边写边想，现在你得先想清楚再让 Agent 写。这个转变对很多工程师来说反而是个挑战，因为"想清楚"比"动手写"难。

3. OpenAI 与 Cursor 分手：套壳工具的黄昏，还是 Agent 编排的黎明

3.1 合作终止的本质：模型厂商要吃掉应用层

OpenAI 终止与 Cursor 的合作，很多人第一反应是"Cursor 要凉了"。我觉得这个判断太简单。更准确的解读是：模型厂商和应用层工具之间的关系正在重新洗牌。

过去两年的格局是：模型厂商提供 API，应用层工具（Cursor、各种 Copilot）负责把 API 包装成好用的产品。这个格局成立的前提是"模型能力不够强，需要应用层做大量工程来补足体验"。但当模型本身越来越强、越来越懂代码的时候，模型厂商会发现：我自己直接做一个编程 Agent，体验可能比套壳工具还好，那我为什么要让你赚这个差价？

这对做 Agent 开发的团队是一个必须正视的问题：你的护城河到底是什么？如果只是"调用 API + 做个界面"，那模型厂商随时可以替代你。真正能活下来的，是那些在特定场景里积累了深度能力的团队——比如对某个垂直行业的代码规范了如指掌，比如有一套别人复制不了的编排逻辑，比如掌握了独特的数据。

3.2 Cursor 这类工具真正的价值在哪，别一棍子打死

虽然我说套壳工具有风险，但 Cursor 这类产品并不是没有价值。它的价值在于交互设计和上下文管理。一个好的编程 Agent，不只是模型强就行，还得解决这些问题：

• 怎么把当前文件、相关文件、历史对话、项目规范这些上下文，精准地喂给模型？
• 怎么让用户用最自然的方式表达意图，而不是写一堆 prompt？
• 怎么在模型输出后，做增量修改而不是全量重写？

这些是工程问题，不是模型问题。Cursor 在这上面做了大量工作，这也是它能火起来的原因。所以我的判断是：Cursor 不会因为失去 OpenAI 就死掉，但它必须找到自己的差异化定位——要么换模型底座，要么往更垂直的场景走，要么把编排能力做到极致。

3.3 对做 Agent 项目的团队，这条新闻的三个启示

如果你正在做 Agent 相关的项目，这条新闻至少给你三个提醒：

第一，别把身家性命押在单一模型上。今天能合作，明天就可能终止。你的 Agent 架构应该支持多模型切换，把模型调用抽象成一层，换模型的时候不用重写业务逻辑。这一点在实操上就是：别在业务代码里到处写openai.chat.completions.create，而是封装一个统一的LLMClient接口。

第二，编排逻辑才是你的核心资产。模型会换代，API 会变，但你针对特定场景积累的编排逻辑——什么任务拆成几步、每步用什么 prompt、怎么验证结果——这些是别人抄不走的。把精力放在这上面。

第三，关注开源模型作为备选。这也是为什么第三条新闻（GLM-5.3 开源）值得单独讲。有一个能自己掌控的模型底座，在商业关系变化的时候，你才有底气。

3.4 一个实操建议：给你的 Agent 做模型抽象层

我见过太多项目，模型调用散落在各处，换一次模型要改几十个文件。这里给一个简单的抽象层设计思路，用 Python 举例：

from abc import ABC, abstractmethod class LLMClient(ABC): @abstractmethod def chat(self, messages, tools=None, **kwargs): pass class OpenAIClient(LLMClient): def chat(self, messages, tools=None, **kwargs): # 调用 OpenAI 接口 ... class GLMClient(LLMClient): def chat(self, messages, tools=None, **kwargs): # 调用 GLM 接口 ... class LLMFactory: @staticmethod def create(provider: str) -> LLMClient: if provider == "openai": return OpenAIClient() elif provider == "glm": return GLMClient() raise ValueError(f"Unknown provider: {provider}")

这样你的业务代码只依赖LLMClient接口，换模型的时候改一个配置就行。这个设计不复杂，但能救命。我自己的项目里，模型抽象层是第一天就要搭的东西，不是等到出问题了才补。

4. GLM-5.3 开源：Agent 落地企业的那块"自主可控"拼图

4.1 为什么开源模型对 Agent 项目特别重要

Agent 和普通的聊天机器人不一样。聊天机器人答错一句话，用户笑一笑就过去了。但 Agent 是要执行动作的——它可能改代码、可能调 API、可能操作数据库。这意味着 Agent 对模型的要求更高：不仅要能理解，还要能可靠地执行。

而企业级 Agent 落地，绕不开三个硬约束：

• 数据安全：企业的代码、文档、业务数据，不可能都往外部 API 送。
• 成本可控：Agent 的调用量比聊天大得多，按 token 计费的模式在高频场景下成本会失控。
• 可定制：每个企业的业务逻辑不一样，需要一个能微调的模型底座。

开源模型正好解决这三个问题。GLM-5.3 开源，意味着国内团队可以把它部署在自己的服务器上，数据不出内网，成本变成固定的算力成本，还能根据自己的场景做微调。这对做企业级 Agent 的团队来说，是一个实打实的利好。

4.2 开源模型跑 Agent 的现实差距与弥补思路

但我也得说实话：开源模型和顶级闭源模型之间，在 Agent 场景下还是有差距的。这个差距主要体现在复杂推理、长上下文、工具调用的稳定性上。Agent 任务往往需要多步推理和多次工具调用，任何一步出错，整个任务就失败了。

那怎么弥补？我的经验是三个方向：

第一，用编排补模型。模型不够强，就用更细的步骤拆解来补。把一个复杂任务拆成多个简单步骤，每步只让模型做一件小事，成功率会高很多。这其实就是 Agent 框架存在的意义。

第二，用验证补模型。模型输出后，加一层验证逻辑。比如代码生成后跑测试，SQL 生成后做语法检查，API 调用前做参数校验。验证层能拦住大部分错误。

第三，用微调补模型。如果你的场景足够垂直，用自己积累的数据做微调，效果往往能超过通用大模型。GLM-5.3 开源的价值就在这里——你能拿到权重，能自己微调。

4.3 本地部署 GLM-5.3 跑 Agent 的硬件与配置考量

如果你打算本地部署 GLM-5.3 来跑 Agent，有几个实操层面的点要注意：

这里我想特别提醒一点：Agent 场景对推理延迟很敏感。因为一个 Agent 任务可能要调用模型十几次，每次延迟 2 秒，加起来就是几十秒。所以本地部署的时候，吞吐和延迟的平衡比单纯追求模型效果更重要。有时候用一个稍小但更快的模型，体验反而更好。

4.4 开源 + Agent 的组合，正在改变谁能做 AI 产品

GLM-5.3 开源这件事，放到更大的背景里看，意义在于它降低了做 AI 产品的门槛。以前做 Agent 产品，你得有模型能力，或者至少得能稳定拿到 API。现在有了开源模型，一个中小团队也能搭起自己的 Agent 系统，不用看别人脸色。

这对整个生态是好事。因为 Agent 的价值最终要靠场景来体现，而场景是分散的、多样的。大厂不可能覆盖所有场景，中小团队在垂直场景里反而更有优势。开源模型给了他们入场券。

5. 把三条新闻拼起来：2026 年做 Agent 项目的实操框架

5.1 从"用 Agent"到"管 Agent"，能力要求变了

看完这三条新闻，我最大的感受是：Agent 的竞争已经从"能不能做出来"变成了"能不能管好"。Uber 的 70% 不是靠一个神奇的 Agent 实现的，而是靠一套完整的工程体系——仓库规范、测试门禁、审核流程、监控告警。OpenAI 和 Cursor 的分手，本质是 Agent 产品在商业层面的重新定位。GLM-5.3 开源，则是给 Agent 的"管理"提供了更多底层选择。

所以如果你现在要做 Agent 项目，光会调 API、会写 prompt 是不够的。你还需要懂：怎么设计 Agent 的工作流、怎么给 Agent 加约束、怎么评估 Agent 的表现、怎么在成本和效果之间找平衡。这些是"管 Agent"的能力。

5.2 一个可落地的 Agent 项目分层架构

基于上面的分析，我给一个我自己在用的 Agent 项目分层架构，供参考：

第一层：模型层。封装多个模型（闭源 + 开源），提供统一的调用接口。这一层的目标是"可替换"。

第二层：编排层。负责任务拆解、步骤调度、状态管理。这一层是核心，也是你的差异化所在。常见的编排模式有 ReAct、Plan-and-Execute、多 Agent 协作等，选哪种取决于你的任务特点。

第三层：工具层。把 Agent 能调用的能力（搜索、代码执行、API 调用、数据库操作）封装成标准工具。这一层的关键是"安全"——每个工具都要有权限控制和参数校验。

第四层：验证层。对 Agent 的每一步输出做验证。代码跑测试、SQL 做检查、API 调用做 dry-run。这一层决定了 Agent 能不能上生产。

第五层：观测层。记录 Agent 的每一步决策和结果，方便排查问题和优化。没有观测层的 Agent 系统，出了问题你都不知道从哪查。

这个架构不复杂，但每一层都有讲究。我见过很多项目，模型层和编排层混在一起，工具层没有权限控制，验证层直接省略，结果就是 Demo 很惊艳、上生产就崩。

5.3 给不同阶段团队的三条建议

最后，针对不同阶段的团队，我给三条不同的建议：

如果你还在探索阶段，别急着搭复杂架构。先用最简单的 ReAct 模式跑通一个具体场景，验证 Agent 到底能不能解决你的问题。这个阶段最重要的是"快速试错"，不是"架构完美"。

如果你已经跑通了 Demo，重点转向"可靠性"。加验证层、加观测层、加错误处理。这个阶段的目标是让 Agent 从"偶尔能用"变成"稳定能用"。

如果你要上生产，重点转向"成本和可控性"。考虑开源模型、考虑缓存、考虑限流。这个阶段的目标是让 Agent 在成本可控的前提下稳定运行。

Agent 这个方向，2026 年已经过了"要不要做"的阶段，进入了"怎么做扎实"的阶段。Uber、OpenAI、智谱这三条新闻，本质上都在说同一件事：Agent 正在变成基础设施，而基础设施的竞争，拼的是工程能力，不是概念。