企业官网建设流程全解析

1. 先聊聊“70% PR 被 Agent 接管”这事背后的真实分量

最近看到 Uber 工程师分享的一个数据——内部已经有相当高比例的代码 PR 不是人亲手写的，而是 Agent 自动生成、自动测试、自动提交的。标题里那个“70%”很抓眼球，但说实话，第一次看到这个数字我的反应不是兴奋，而是怀疑：PR 这种需要理解业务上下文、遵守团队规范、通过代码评审的动作，Agent 真能接得住吗？

冷静下来仔细琢磨，这个 70% 说的并不是“Uber 70% 的功能代码都由 AI 从零写完”，而是“在特定的、适合自动化的任务场景里，Agent 完成了一个 PR 从代码生成到提交的完整链路”。这里面的差距非常大，比如修一个明确的 bug、补一个单元测试、升级一个依赖库、重构一段公共工具函数，这些任务的上下文边界清晰、验收标准明确，Agent 完成起来确实比人肉手写更高效。而需求探索、架构设计、跨模块协调这类模糊任务，现阶段依然是人的主场。

我为什么对这个话题这么感兴趣？因为过去一年我一直在做 Agent 开发相关的事，从最开始用开源的 agent 框架写玩具项目，到后来真正把它接入团队的日常开发流程，中间踩了无数坑。Uber 这个案例等于给整个行业做了一个验证——Agent 确实能从“帮你补全代码”进化到“替你完成一个完整的工作单元”。这篇文章我不打算复述那些公开报道，只想结合我自己在 agent 开发、PR 提交流程落地中的实际经验，拆一拆这件事背后的技术逻辑、工程化落地步骤，以及如果有一天你的团队也想把 70% 的 PR 交给 Agent，到底该怎么下手。

无论你是搞 AI Agent 开发的技术人，还是日常被 PR 评审折磨得头疼的工程师，这篇文章都值得读完。我会把 Agent 接管 PR 的架构设计、工具选型、实操配置、踩坑记录全部摊开讲。

2. Agent 接管 PR 的核心逻辑：它和传统自动化到底有什么不一样

2.1 传统 CI/CD 自动化 vs Agent：本质区别在于“从知道到做到”

团队里早就有一堆自动化工具，lint 自动检查、CI 自动跑测试、Dependabot 自动升级依赖，这些也都是“机器在做 PR 相关的事”。那 Agent 凭什么值得单独拿出来说？差别在于传统工具是预设路径的执行器，Agent 是能自己找路径的规划器。

举个实际例子。Dependabot 升级依赖库，它的流程是：发现新版 → 改文件 → 跑测试 → 提 PR。这四条路径全部是写死的，遇到编译错误、测试失败，Dependabot 只会机械地在 PR 里留言“有冲突”。而一个真正的 Agent 在升级依赖时，可以自主做这些事：先看 release note 确认破坏性变更，再搜索代码里所有相关调用点，逐个修改 API 用法，遇到类型错误自己翻文档修复，跑完测试发现还有问题继续迭代修改，最后把整个修改思路写进 PR 描述里。

这里最关键的技术点其实是“工具调用”和“自我修正循环”。普通自动化脚本是 if-else 的树，Agent 是大模型驱动的循环：观察当前状态 → 决定下一步 → 执行操作 → 观察结果 → 如果不对就调整策略再来一次。这就是 Agent 和规则引擎的分水岭。

2.2 70% 这个数字的边界：Agent 适合什么、不适合什么

结合我自己在 agent 开发中的实践，我总结了适合 Agent 接管的 PR 类型，大概有这几个特征：

第一，任务是局部性的。修改范围能明确圈定在某几个文件、某个模块之内，不需要理解整个系统的拓扑关系。典型的就是 bug 修复、单元测试补全、代码格式化、死代码清理。

第二，验收标准是可执行的。有测试用例能验证对错，有编译步骤能检验正确性，有 lint 规则能判断风格。Agent 可以在自己循环里反复试错，而不需要人来判断“这样做感觉对不对”。

第三，上下文是能被完整喂进去的。相关代码、相关文档、相关 issue 描述能通过 prompt 拼进模型上下文，不会出现“你去看一下某个老系统的设计文档，在 wiki 里自己找”这种需求。

反过来说，剩下那 30% 为什么 Agent 接不住？我见过太多失败案例，基本都是踩了这三个坑：一是任务需要跨三四个服务做数据流梳理，Agent 一进去就迷路；二是需求本身含糊——“优化一下这个页面的交互体验”，Agent 生成十版你都不满意；三是涉及强业务判断的，比如价格策略、合规逻辑、风控规则，这类决策人不敢放权，也不应该放权。

所以 70% 这个数字不是天上掉下来的，是 Uber 把自己的任务池做了精细化分类之后自然得到的结果。你的团队想复现这个数字，第一步就该是盘点自己任务池里有多少符合上述特征的“局部、可验证、上下文完整”的任务。

3. 实操落地：教你搭一套能自动提 PR 的 Agent 工作流

3.1 技术选型：直接用 Codex CLI 这类工具，还是自己搭 agent 框架？

聊 Agent 接管 PR，第一件事就是选型。市面上的方案大概分成三类，我按自己的使用体验说说优劣。

第一类是闭源全托管工具，比如 GitHub Copilot Workspace、OpenAI Codex 接入 GitHub 这类。它的优势是零配置，装好插件给个 issue 链接就能干活，自动 fork 仓库、自动建分支、自动提 PR，全流程平台帮你串好了。缺点是深度定制很受限，比如你希望 Agent 提 PR 前强制跑某个内部的静态扫描工具，这种场景闭源平台不好扩展。

第二类是开源 CLI Agent，典型代表是 OpenAI Codex CLI（注意区分，Codex CLI 是本地跑的命令行 agent，和云端 Codex 平台是两个东西）。这类工具给的是“半成品”：Agent 脑子（大模型）和手脚（shell 工具、文件编辑工具）都齐全，但需要你自己写 workflow 脚本，把“拉取 issue → 创建分支 → 执行代码生成 → 跑测试 → 提交 commit → push → 创建 PR”串起来。它的自由度介于托管和纯自研之间，我们团队目前就是用这条路。

第三类是自研 Agent 框架，基于 LangGraph、CrewAI、Dify、自研 workflow 引擎这类东西搭完整链路。优势是任何环节都能改，比如我们后来在 workflow 里加了一个“模糊需求追问”节点，Agent 在开始写代码前如果发现 issue 描述信息不足，会先在 PR 里留一个 pending 状态并 @ 对应负责人补充细节，这种逻辑只有自研框架才做得到。代价就是开发和维护成本高，一个能稳定跑生产的框架，背后至少需要两三个全职人力。

做选型时我给个参考建议：**团队少于 10 人，优先用 Codex CLI 这类开源命令行 Agent 加脚本串联；团队有平台工程背景，再考虑自研框架。**不要一开始就追求大而全，能让 Agent 先把 20% 的 PR 接走，比搭一个半年上不了线的完美框架重要得多。

3.2 工作流设计：从 issue 到 PR 的六个环节，哪些该放权给 Agent

我把自己在项目里跑通的 Agent 提 PR 流程拆成六个环节，每一个环节都有明确的“人机分界线”。

环节一：任务获取与解析。Agent 从待办列表里拉取一个任务（issue），先做语义解析：提取任务类型（bug 修复/功能开发/重构/测试补全）、涉及模块、验收标准。这里我强烈建议给 Agent 喂一个任务模板，让任务负责人按固定格式填需求，比如必须包含“预期行为”“当前行为”“复现步骤”“期望输出”四个字段。结构化输入对 Agent 的后续表现影响巨大——我实测下来，结构化任务的成功率比自由文本任务高 30% 以上。

环节二：代码库探索与上下文构建。Agent 需要先看懂相关代码。这一步最常见的坑是很多人图省事，把整个仓库的代码全部塞进 prompt，结果上下文爆炸、token 烧钱、模型注意力被噪音淹没。正确做法是用 code search 工具（比如 ripgrep）定位关键符号，再用文件读取工具逐层展开。Codex CLI 内部的 codebase indexing 机制做得还可以，会先建索引再回答具体问题。自研方案里可以接 tree-sitter 做 AST 分析，把函数调用关系图提前提取出来作为 Agent 的“地图”。

环节三：代码生成与修改。这是 Agent 的主场。注意一个关键点：不要在单次生成里试图完成整个 PR 的所有改动。正确姿势是让 Agent 把任务拆成多个小步，每步生成一个 diff，跑一次编译/测试，通过后再进入下一步。这本质上是在 Agent 内部再套一层“小步快跑”的开发方法论。

环节四：验证与自我修复。这是 Agent 能不能真正替代工程师的分水岭。Agent 生成完代码后，必须在沙箱环境里跑编译、跑单测、跑 lint，返回值非零就触发自我修复子循环：读报错日志 → 定位失败原因 → 修改代码 → 重跑，最多迭代 N 次（我一般设 5 次，超过就放弃并标记为需人工介入）。很多 agent 项目的 PR 被驳回，根源就是这个验证环节偷懒了——只做了“代码看起来没问题”的人工判断，没有做“机器确认没问题”的实证校验。

环节五：提交与 PR 生成。Agent 把最终代码提交到分支，push 后创建 PR，并自动生成 PR 描述：修改了哪些文件、为什么这么改、测试结果如何、有没有遗留风险。这一步非常影响评审效率——我见过太多 Agent 提的 PR 只写一句“This PR fixes the bug”，评审人还得自己 diff 代码猜思路。正确做法是在 prompt 里强制要求 PR 描述包含“背景”“改动点”“测试验证”“自评风险”四节。

环节六：人工评审与合入。PR 创建后并不自动 merge，而是进入正常的人工评审流程。这一步是真个链路的关键防线，70% 的自动化 + 100% 的人工把关，才能保证代码质量没有滑坡。

3.3 环境准备：沙箱、模型路由和权限最小化

这一节最重要，因为很多 Agent 项目挂在生产落地的第一道坎不是模型能力不够，而是基建没跟上。

第一，沙箱环境必须是隔离且可重建的。Agent 要跑任意代码，意味着它可能执行任何命令——编译、测试、安装依赖、甚至不小心 rm -rf。我们团队的做法是基于容器技术准备一个“Agent 沙箱镜像”，镜像里预装好编译链、依赖缓存、测试框架，每次 Agent 任务启动时新建一个容器实例（用 docker run 或者更轻量的 firecracker 微虚机），任务结束直接销毁。这样做的好处是：环境干净可复现，Agent 造出来的垃圾不会污染开发机；权限可控，容器内没有生产环境的密钥和数据库连接。

第二，模型路由要做分层。不同环节对模型能力的需求完全不一样，没必要所有环节都用最强的旗舰模型。我自己常用分层是：任务解析和代码修改这类高难度环节用强的推理模型（一次生成质量高，少几次迭代）；测试结果日志总结、PR 描述生成这类整理型任务用便宜的轻量模型；代码搜索和关键词提取甚至可以只用传统算法。这样整体 token 成本能降一个数量级。

第三，权限最小化。Agent 能做的事必须和它的职责严格对齐。能 push 到一个特定 feature 分支，但不能 push 到 main；能读取仓库代码，但不能读取生产数据库配置；能创建 PR，但不能直接 merge PR。权限控制在 Git 平台层面用 deploy key 的粒度控制，而不是直接把开发者的完整 token 给 Agent 用。这块如果图省事，后面出一次事故就得不偿失了。

3.4 真实落地案例：我是怎么把测试补全类 PR 交给 Agent 的

讲个我们团队的实际案例，场景是“给核心工具模块补单元测试”。这个任务是最适合 Agent 玩的场景之一：上下文明确（工具函数就在那几个文件里）、验收标准清楚（覆盖率达标、测试通过）。

我设计的 workflow 是这样的：

第一步，我先用脚本扫描代码仓库，按一定优先级规则筛选出覆盖率低于 40% 的工具函数，生成一个“待补测试”清单，每个任务带功能描述、现有代码路径、当前覆盖率、函数签名。

第二步，Agent 逐个处理清单项。它先读源码理解函数逻辑，再分析边界条件和异常分支，然后用测试框架生成对应的单元测试代码。这里重点提醒一下：生成测试代码最容易出现“假测试”问题——测试全绿，但断言根本没验证核心逻辑，比如只测试函数能跑不报错，不验证返回值正确。我现在的 prompt 里明确写了“每个测试必须有 value 断言，禁止只做 happy path 冒烟测试”，效果立竿见影。

第三步，Agent 在沙箱里跑完测试后，自动生成一个 PR，PR 描述里带覆盖率变化对比、测试用例清单、边界条件说明。人工评审人只需要重点看测试断言的质量，不需要一行行读测试代码本身。

这个流程跑顺之后，我们团队测试补全类 PR 的自动化率超过了 80%，剩余人工介入的主要是那些工具函数本身逻辑太怪、边界条件模糊的场景。这一个小场景的落地经验，让我对 Uber 那个 70% 有了更深的认同——自动化率不是靠一个万能 Agent 实现的，是靠把任务切碎、把每个碎片的验收标准定义清楚、再逐个击破实现的。

4. Agent 开发中的配置与优化细节：不花大钱也能把 70% 落到自己团队

4.1 Prompt 工程：给 Agent 写“岗位说明书”而不是“命令”

很多 Agent 项目效果差，问题不是模型不行，而是 prompt 写得像命令而不是说明书。我总结了一套给 Agent 写 system prompt 的模板，核心包括四块。

第一块是角色定位，比如“你是一名资深后端工程师，负责维护 XXX 仓库的工具函数模块”。这里角色越具体越好，因为模型会根据角色自动调整代码风格和决策倾向。

第二块是工作流程约束，明确告诉 Agent 每一步做什么、顺序是什么、什么情况下要停下请求帮助。比如“修改代码前必须先搜索相关符号的调用关系”“测试跑挂时最多自查 5 次，超出后停止并汇报”。

第三块是质量标准清单，把代码评审时最常被打回的几条写成显式规则。我自己清单里常驻的有：不要删除未明确废弃的公共 API；新增代码必须带类型注解；禁止直接把搜索到的 stack overflow 代码原样粘贴；所有分支条件都要考虑 null/空集合的边界。

第四块是输出格式要求，规定 PR 描述的结构、commit message 的写法、代码注释的语言和风格。这块能大幅减少人工评审的认知负担。

4.2 任务上下文注入：让 Agent 只看该看的代码

上下文注入的精细程度直接决定 Agent 输出的质量。我的做法是构造一个“任务上下文包”，结构大概是：任务描述、相关文件路径列表、每个文件的关键函数签名和说明、仓库的架构简图（文字描述）、团队代码规范摘要。Agent 启动时，先拿这个包作为基础，再自行搜索补充细节。

这里有个技巧值得分享：**优先用命令行工具做符号检索，而不是把整个文件内容读进上下文。**比如我先用rg "functionName" -l找文件，再用sed -n '100,200p' file.go看指定区间，而不是cat整个文件。控制好上下文窗口的使用方式，既省钱又能减少模型被无关代码干扰的概率。这跟我以前做 AI 应用的经验一样——给模型的输入质量，决定模型的输出质量。

4.3 质量评估自动化：用一个“评审 Agent”守最后一道门

人工评审前，我强烈建议加一个“评审 Agent”环节。它不负责写代码，只负责审查 Agent 生成的 PR。审查维度包括：改动范围是否超出任务描述、有没有无意中修改不相关文件、变量命名是否规范、异常处理是否完备、和现有代码风格是否一致。

我是怎么做的呢？在 CI 流程里加一个“review-agent” job，代码 push 后自动触发，把 diff 送到评审 Agent 那里打分，低于 70 分直接打回并附修改意见，高于 70 分再转人工评审。人工评审的负担一下子就减轻了，而且评审 Agent 不会像人那样因为赶时间而走马观花。

有人可能担心这么搞 Golang、Java 这类静态语言环境还行，动态语言是不是不好判断？其实不用太焦虑，评审 Agent 主要做的是风格一致性和明显逻辑缺陷的判断，这部分对语言不敏感，模型能力完全够。而且它可以被持续调优——你今天发现它漏掉了一类问题，就把对应规则写进它的 system prompt，它之后一直能记住。

4.4 成本控制：如何让 70% 的自动化不至于把预算烧穿

Agent 自动提 PR 爽是真爽，贵也是真贵。我把这部分单独拿出来讲，是因为看到过太多“Agent 试用两周后因为账单太吓人被砍掉”的项目。成本控制有几个实用策略。

一是模型分层，前面已经说过了，任务解析用便宜模型、代码修改用优秀模型、评审总结用便宜模型，整体成本能降不少。

二是缓存命中。同一仓库反复探索是常态，要把代码检索结果、函数签名提取结果做缓存。尤其是仓库索引，一次构建好之后，后续任务直接复用，能省掉大量重复 token。

三是回收机制。Agent 自我修复循环是最烧钱的地方，每多迭代一轮就多一轮 token 消耗。所以一定要给迭代次数设上限，比如 5 次没搞定就转人工，不要让它无限死循环。人的一次零散介入，远没有几十轮模型调用贵。

四是本地化模型辅助。很多任务（变量命名建议、简单的格式化、错误信息解读）根本不需要云端大模型，用本地跑的量化小模型就能完成。把这类请求拦截在本地，也能省一部分成本。

5. 实战中的常见问题与排查技巧实录

5.1 问题一：Agent 生成了测试但断言质量太差

这是我在测试补全类任务里遇到的最常见问题。表现就是测试全绿、覆盖率达标，但仔细一看，断言全是“不等于 null”“调用后无异常”这类假阳性验证，真正的业务逻辑几乎没覆盖。

排查思路：开始我以为是模型能力问题，换了不少模型都没改善。后来意识到是 prompt 里缺少对“断言质量”的显式要求。后来在 agent 工作流的“评审 Agent”环节加了一条规则：遍历测试断言，检查有没有对返回值做具体断言（比如 assertEquals、assertContains），发现“弱断言”直接打回。这个措施上线后，测试补全的质量有了明显提升。

5.2 问题二：并发任务导致代码冲突

Agent 能并行处理多个任务后，冲突问题立刻来了。两个 Agent 同时改同一个模块，后一个 push 的时候发现冲突。

我们的解法分两层。第一层简单粗暴：文件目录锁。Agent 任务开始前，扫描它涉及的文件路径，如果在“正在编辑”清单里，就先等一会儿。这是很朴素的互斥方案。第二层是流程约束：任务池的分配尽量按“模块维度”分发，同一模块的任务不要同时开两个 Agent 处理。这两层配合之后，冲突概率下降了一个量级。

5.3 问题三：Agent 幻觉出根本不存在的 API

Agent 写代码时信誓旦旦地用了一个不存在的库函数，编译直接报错。这是我早期项目里最让人头大的问题。

后面总结经验，根因是 Agent 的训练数据里见过这个 API，但在当前项目环境里它并不存在。解决方式第一条是：强制 Agent 在写完代码后必须实际跑一次编译，没有跑编译验证的代码不允许提 PR。第二条是在 prompt 里加约束：“当前项目使用的依赖版本列表如下……请只使用这些依赖提供的 API”。第三条是给 Agent 提供“参考 API 文档”的工具调用能力，让它写代码之前先查一下。

5.4 问题四：PR 描述和实际改动不符

Less common but very annoying——Agent 在 PR 描述里写“修复了登录 bug”，但 diff 里改了五六个文件，有一半和登录没有关系。

这背后的问题是“意图漂移”。Agent 在本来的任务路径上走了几步之后，发现了一个“顺手能改”的问题，就没管住自己顺手改了。解法很有效：在提交前加一个 diff 审计步骤，对比“任务描述中声明的改动范围”和“实际 diff 涉及的文件”，超出声明范围的部分一律回退。这条规则现在在我们的工作流里是硬性的。

6. Agent 接管 70% PR 之后，工程师该往哪个方向转型

这个部分我想聊聊更深的思考。很多工程师看到“Agent 接管 PR”的消息会焦虑，担心自己的饭碗是不是要没了。我自己的体会是：担心大可不必，但转型是必须的。

Agent 接管的是“怎么写代码”这个执行层面，而它替代不了的恰恰是“决定写什么、为什么这样写、写成什么样算好”这些更高层的东西。工作重心正从“自己写代码”转向“定义任务和验收标准”：把模糊需求拆成 Agent 能理解的精确任务、定义“可验证的完成标准”、在评审时判断 Agent 的产出是否符合业务意图、在 Agent 反复失败时定位卡点并修正流程。

这其实很像工业革命时期的手工艺人转型——最优秀的传统工匠不会拒绝蒸汽动力，而是学会用蒸汽动力放大自己的手艺。同理，今天最优秀的工程师不是抵制 Agent，而是学会把 Agent 当成一个能力极强但需要管理的初级开发，你负责当好它的“技术负责人”。

我自己的日常工作流里，已经有相当比例的 PR 不是一字一句敲出来的。大部分时间是做任务拆解、写详细需求说明、检查 Agent 的产出、修正 workflow 里的问题环节。老实说，这种工作方式比纯手写代码更有成就感，因为你从“手搓每一行”变成了“设计一套系统让产出效率整体提升”，这是完全不同的能力维度。

7. 写在最后：从 Uber 的 70% 到你自己团队的第一步

Uber 那个 70% 的 PR 自动化率，不是哪天突然冒出来的，而是在 agent 开发、流程重塑、质量护栏不断迭代中逐渐逼近的。如果你想在自己的团队里做同样的事，我给的最小可行路径是：挑一个边界清晰、验收标准可量化的任务场景（比如单元测试补全、依赖升级、死代码清理），选一个开源 CLI Agent 工具，搭好沙箱和权限控制，把“生成代码 → 跑验证 → 提 PR”这条最小链路跑通，然后持续用真实数据优化。

我自己实际操作下来最大的体会是：**Agent 不是魔法，是一套需要你精心设计的流水线。**它的核心价值不是“自动写代码”这几个字，而是把编码过程中大量重复的、可验证的、确定性高的环节自动化，把人的注意力解放出来，放到真正需要业务判断和架构思考的地方。

如果你也在做 agent 开发、也在尝试把 Agent 接入日常开发流程，记住这些踩坑经验会让你少走很多弯路：prompt 要写岗位说明书而不是命令，验证环节不能省，权限要给最小化，任务要按可验证性切分。别指望一步到位 70%，先把一个场景吃透，再复制到下一个场景。

最后分享一个我近期踩出来的小套路：把 Agent 提的 PR 打回原因单独建一个标签统计，跑一个月你会发现，反复打回的原因就那么几个。把排前三的规则写进 Agent 的 system prompt，下个月的打回率能立竿见影地下降。这种“用数据喂流程、用流程养 Agent”的循环，才是提升自动化率最靠谱的路子。