企业官网建设流程全解析

过去一年，AI 辅助写代码已经从“个人插件”快速进化成“团队基础设施”。但真正让工程团队兴奋又焦虑的，是 Agent 开始大规模接管代码评审环节。近期 Uber 披露的工程实践引发了大量讨论：通过 Agent 自动生成的 PR 已经占到总量的 70%，同时 AI 相关账单没有明显增长。这个数字背后，远不止“AI 写得快”这么简单，更关键的是一整套围绕成本、质量和流程控制的工程体系。

本文将围绕 Uber 这个实践做一次系统性拆解，先解释 Agent、PR、AI 成本这三个基础概念，然后分析“70% PR 接管率”和“AI 账单零增长”背后的技术逻辑，再提供一个接近真实场景的 Python Agent 示例，最后给出工程落地中常见的问题排查和最佳实践。无论你是技术负责人、后端工程师，还是正在调研 Agent 开发的初学者，这篇文章都能给你一套可参考的技术思路。

1. 背景：当 70% PR 由 Agent 生成，工程流程发生了什么

1.1 一个让工程师又爱又怕的数字

70% 的 PR 由 Agent 生成，乍一听像是一个“AI 替代程序员”的激进宣言，但实际上这更多是一次工程流程重构的结果。

PR，也就是 Pull Request，是代码从开发分支合并到主干之前必经的评审环节。一个 PR 里包含代码改动、提交说明、关联任务、评审意见、CI 检查结果等。过去，PR 完全由人类开发者发起和编写，评审人也由人类承担。现在，大量 PR 由 Agent 基于 Issue、设计文档或任务描述直接生成，人类工程师的角色逐渐从“写代码的人”变成了“审核 Agent 输出的人”。

这个转变对团队的意义非常明显：低级错误、格式问题、重复劳动、跨模块的机械性改动都可以交给 Agent 完成，人类工程师可以把精力集中在设计评审、架构取舍和疑难问题排查上。Uber 公开这个数字，并不是在说“我们不再需要工程师”，而是在说“我们把工程师从繁琐的代码生成中解放了出来”。

1.2 Agent、PR、CI：先理清三个基础概念

在深入文章主题之前，先快速对齐几个概念：

Agent 在 AI 工程语境下，通常指一个能够自主完成多步骤任务的程序。它不像传统聊天机器人那样只回答一次，而是能够感知环境、规划步骤、调用工具、执行操作，并在过程中不断调整。比如一个 PR 生成 Agent，它可能需要先读取 Issue、检索相关代码、编写实现、运行测试、提交代码、创建 PR、填写描述。

PR 的全称是 Pull Request，是 Git 协作中的核心环节。它是一组代码变更的集合，附带上下文说明和评审历史。PR 的质量直接影响代码库的可维护性。

CI 是持续集成（Continuous Integration），指每次代码提交后自动执行的构建、测试和静态检查流程。Agent 生成的 PR 通常需要经过严格的 CI 检查，才能进入人工评审阶段。

把这三个概念串起来，Uber 的实践可以简单概括为：Agent 负责生成 PR，CI 负责自动验证 PR 质量，人类评审者只关注那些 CI 无法判断的设计和架构问题。

1.3 为什么“AI 账单零增长”比 70% 更重要

如果只看“70% PR 由 Agent 生成”，很多人会以为 Uber 在无节制地调用大模型 API。但真正值得注意的，是“AI 账单零增长”。

这说明 Uber 不是简简单单把每个 PR 都交给大模型从头写一遍，而是建立了一套成本分层机制。比如，简单重复的改动交给规则引擎或小型模型处理，只有复杂任务才调用大型语言模型；很多静态检查直接走传统工具，完全不需要消耗 Token；大量的相似请求会走缓存和复用逻辑，而不是每次都重新生成。

对大多数团队来说，70% 的 PR 接管率短期内难以复制，但“AI 账单零增长”这个目标却非常值得学习。盲目引入 AI 开发工具，最直接的后果就是云账单失控。AI 产生的价值可能很高，但成本如果无法收敛，项目就很难长期推行。所以这篇文章后续也会专门分析成本控制的设计思路。

2. Uber Agent 实践的核心逻辑拆解

2.1 70% PR 不是“自动改代码”那么简单

要理解“70% PR 由 Agent 生成”这个数据，首先要意识到一个前提：Uber 的业务场景和代码库结构非常适合 Agent 处理。

大型互联网公司的代码库中，存在大量模式化的改动。比如接口参数调整、字段重命名、依赖升级、错误码统一、日志格式规范化、单元测试补全等。这类改动规则明确、影响范围可控，很多并不需要深度架构思考。Agent 通过学习历史 PR 的模式，完全可以自动生成类似的改动。

但这里有一个容易被忽视的关键点：Uber 的 70% 不是指“AI 自动合并了 70% 的 PR”，而是“AI 自动生成了 70% 的 PR”。最终代码是否合入，仍然要经过 CI 检查、风险控制流程和人工评审。

这种“AI 生成 + 人工评审 + 自动验证”的模式，本质上是把 Agent 当成一个无限供给的初级工程师：它可以快速产出候选方案，但质量控制仍然由工程体系兜底。对团队来说，这不是简单的工具替换，而是一次完整的研发流程再造。

2.2 AI 账单零增长的三层含义

“AI 账单零增长”是一个很简洁的表述，但它背后其实有三层含义。

第一层是路径选择的优化。Uber 不会所有问题都调用大模型。对于简单的代码格式化、import 排序、变量重命名等任务，直接用静态规则引擎或传统工具就能完成，完全不必产生模型调用成本。

第二层是模型调用的精准化。复杂的代码生成任务并不需要重复调用模型。Uber 的 Agent 系统会缓存已有结果、批量提交相似请求、合理控制上下文窗口长度，避免无意义的 Token 消耗。对长上下文任务还会做上下文压缩，只把相关代码片段送入模型，而不是把整个仓库塞进去。

第三层是观测和配额管控。在 Agent 大规模接入时，成本暴增往往不是因为模型太贵，而是因为缺少预算控制和可观测性。Uber 的做法相当于在每个 Agent 任务链路上都加了成本指标，一旦某个类型的任务成本超标，就会被自动降级到更经济的处理方式。对普通团队来说，这个思路比“省 Token”本身更有参考价值。

2.3 这个实践对普通团队有哪些参考价值

Uber 的体量和基础设施不是普通团队能直接复制的，但这一实践的底层逻辑完全可以迁移。

首先，任何团队都可以把“AI 生成的 PR”和“AI 自动合并的 PR”分开考虑。可以先从低风险的代码改动开始试点，比如生成单元测试、补全注释、升级依赖，这些任务即使生成质量一般，也不会造成严重事故。

其次，任何团队都应该建立“成本分层”意识。不是所有代码任务都需要调用最强模型，也不是所有任务都要调用模型。合理使用规则引擎、小模型、缓存和限流，是控制 AI 账单的关键。

最后，质量护栏不能省。Agent 生成的代码必须经过 CI、代码评审和灰度验证。不要因为 Agent 是机器生成的，就觉得它比人写的代码更可靠。相反，Agent 生成代码的不可预测性更高，更需要通过工具链来约束。

3. Agent 自动化 PR 流程的常见技术架构

3.1 Agent 在 PR 流程中的三个关键位置

一个完整的 PR 流程可以分为三个阶段：生成、验证、评审。Agent 在三个阶段都可以发挥作用。

在生成阶段，Agent 根据任务描述、Issue 内容和相关代码生成代码改动，并自动提交 Commit、创建 PR。这个阶段要解决的核心问题是“如何让 Agent 理解任务上下文”。常见做法是把 Issue 文本、相关文件路径、项目代码规范、已有代码风格都作为上下文输入。

在验证阶段，Agent 的作用是检查代码质量。它可以直接运行现有 CI 工具链，也可以基于大模型做代码 review，识别潜在的逻辑错误、安全漏洞和风格问题。这个阶段要解决的核心问题是“如何将 Agent 集成进现有 CI 流水线”。

在评审阶段，Agent 可以辅助人类评审者。比如自动生成评审摘要、标记可疑代码、检查是否满足模板要求。这个阶段要解决的核心问题是“如何让 Agent 输出对人类评审者真正有用的信息”，而不是简单罗列文件改动。

3.2 从任务拆解到代码生成的链路

一个成熟的 PR 生成 Agent，通常遵循这样的工作流：

第一步，任务解析。Agent 读取用户提交的 Issue 或任务描述，提取出核心需求、验收标准、涉及模块。

第二步，代码检索。根据任务描述，Agent 在代码库中搜索相关文件，理解现有实现逻辑，找出需要修改的位置。这一步通常依赖代码索引和语义搜索。

第三步，方案规划。Agent 决定如何改动代码，包括新增哪些文件、修改哪些函数、是否需要更新测试。这个规划过程可以由大模型完成，也可以由规则模板驱动。

第四步，代码生成。Agent 按照规划生成代码 diff，尽量遵循项目现有的代码风格和接口设计。

第五步，自动验证。Agent 调用编译、单测、静态检查等工具，验证生成的代码是否能通过基础检查，不通过则迭代修复。

第六步，PR 提交。Agent 生成 Commit 和 PR 描述，关联任务编号，并把需要人工关注的改动点标注出来。

整个链路非常像人类开发者的工作方式，只是执行速度更快、并发度更高。这也是 Agent 能够大规模处理 PR 的技术基础。

3.3 关键设计：人工确认与自动化的分界线

很多团队在引入 Agent 时都会问一个问题：到底哪些环节可以完全自动化，哪些必须保留人工确认？

根据 Uber 这类实践的经验，可以将任务按风险分成三类：

低风险任务，比如依赖版本升级、代码格式化、日志规范调整，可以完全自动化，Agent 生成 PR 后直接进入标准 CI 流程。

中风险任务，比如新增单元测试、重构内部函数，Agent 生成 PR，但需要至少一个人类 reviewer 检查。这类任务出错不会直接导致生产事故，但会影响代码质量。

高风险任务，比如涉及支付、安全、数据迁移、核心链路改造，Agent 只能提供建议或辅助代码片段，最终实现必须由人类工程师完成，或者至少在 Agent 生成后经过严格的架构评审。

这个分界线的核心原则是：自动化程度越高，质量护栏越要完善。如果团队还没有建立良好的测试覆盖和 CI 体系，就不应该贸然让 Agent 接管高风险任务。

4. 实战：用 Python Agent 模拟 Uber 式 PR 流程

4.1 场景设定

为了把上面的概念落地，下面我们写一个简化版的 PR Agent 示例。场景设定如下：Agent 接收一个任务描述，自动检索相关代码文件，生成代码修改建议，并输出一份 PR 描述和评审建议。

这个示例不依赖真实的大模型 API，也不需要连接真实的 Git 仓库，而是模拟 Agent 的工作流程。你可以在此基础上接入 OpenAI API、Claude API 或开源模型，并替换成真实的 Git 操作。

技术栈选择：

• Python 3.10+
• 仅使用标准库，便于直接运行
• 通过类实现 Agent 基本架构，方便扩展

示例项目结构

pr-agent-demo/ ├── main.py ├── agent.py ├── tool.py └── mock_repo.py

4.2 定义仓库模拟模块

我们先用一个模块模拟代码仓库，方便 Agent 检索文件。

# 文件路径：pr-agent-demo/mock_repo.py """模拟一个简单的代码仓库，用于演示 Agent 检索代码。""" MOCK_REPO = { "user_service.py": """ def validate_user(username, password): if not username: raise ValueError("username is required") if len(password) < 6: raise ValueError("password too short") return True """, "order_service.py": """ def create_order(user_id, items): total = 0 for item in items: total += item["price"] * item["count"] return {"user_id": user_id, "items": items, "total": total} """, "user_service_test.py": """ def test_validate_user(): validate_user("alice", "123456") """, } class MockRepo: """提供检索和文件读取能力的仓库模拟类。""" def __init__(self): self.files = dict(MOCK_REPO) def search(self, keyword): """根据关键字返回相关文件路径列表。""" results = [] for path, content in self.files.items(): if keyword in content or keyword in path: results.append(path) return results def read(self, path): """读取文件内容。""" return self.files.get(path, "")

这一步对应真实项目中的代码索引和文件读取能力。在实际工程中，这里可以替换为grep命令、IDE 索引接口或向量检索服务。

4.3 实现工具模块

Agent 在实际工作中需要调用外部工具。这里我们创建一个工具模块，模拟静态检查、格式校验等操作。

# 文件路径：pr-agent-demo/tool.py """Agent 可调用的工具集合。""" import re def check_style(code): """极简代码风格检查：检测是否缺少空行或包含明显 TODO。""" issues = [] if "TODO" in code: issues.append("存在未处理的 TODO 标记") if "print(" in code: issues.append("包含调试用 print 语句") return issues def run_test(code): """模拟测试执行：检测函数中是否有 raise。""" if "raise" in code: return True return False

这种方法把静态检查从大模型中剥离出来。在真实场景中，这些工具可以直接调用pylint、flake8、black、jest、pytest等，完全不需要大模型参与，成本几乎为零。

4.4 编写 Agent 核心逻辑

下面是 Agent 的主逻辑类。这个类的工作流程是：

1. 接收任务描述。
2. 调用仓库检索，找到相关文件。
3. 读取文件内容。
4. 生成代码修改建议（这里用关键字规则模拟 LLM 输出）。
5. 调用工具链验证。
6. 生成 PR 描述。

# 文件路径：pr-agent-demo/agent.py """PR Agent 核心实现。""" from mock_repo import MockRepo from tool import check_style, run_test class PRDraft: """PR 草稿数据结构。""" def __init__(self, title, files, description, issues): self.title = title self.files = files self.description = description self.issues = issues def __repr__(self): return f"PRDraft(title={self.title}, files={self.files})" class CodePRAgent: """一个简化版 PR 生成 Agent。""" def __init__(self, repo: MockRepo): self.repo = repo def analyze_task(self, task: str) -> str: """从任务描述中提取关键字。""" # 实际项目中，这里可以调用大模型进行语义解析 if "validate" in task or "校验" in task: return "validate_user" if "order" in task or "订单" in task: return "order_service" return "" def retrieve_files(self, keyword: str) -> list[str]: """检索相关代码文件。""" return self.repo.search(keyword) def read_file(self, file_path: str) -> str: """读取文件内容。""" return self.repo.read(file_path) def generate_code(self, file_path: str, task: str) -> str: """ 生成代码修改建议。 真实项目中这里调用大模型，本文用规则模型模拟。 """ code = self.read_file(file_path) if "validate_user" in file_path: # 模拟给校验函数增加空密码判断 code = code.replace( 'if len(password) < 6:', 'if not password:\n raise ValueError("password is missing")\n if len(password) < 6:' ) elif "order_service" in file_path: # 模拟给订单函数增加空商品列表判断 code += '\n if not items:\n raise ValueError("items is empty")\n' return code def run_quality_gate(self, code: str) -> list[str]: """运行质量检查工具。""" issues = [] issues.extend(check_style(code)) if not run_test(code): issues.append("测试执行失败") return issues def create_pr(self, task: str) -> PRDraft: """ 生成一个 PR 草稿，包含修改文件列表和描述。 """ keyword = self.analyze_task(task) if not keyword: return PRDraft("未识别任务", [], "Agent 无法理解该任务", ["任务解析失败"]) file_paths = self.retrieve_files(keyword) if not file_paths: return PRDraft("未找到相关文件", [], "Agent 没有找到相关代码", ["文件检索失败"]) changed_files = [] all_issues = [] description_lines = [] for file_path in file_paths: # 只处理 .py 文件 if not file_path.endswith(".py"): continue new_code = self.generate_code(file_path, task) issues = self.run_quality_gate(new_code) all_issues.extend(issues) changed_files.append(file_path) description_lines.append(f"- 修改 `{file_path}`，处理任务：{task}") if issues: description_lines.append(f" 检查发现潜在问题：{'；'.join(issues)}") title = f"feat: {task}" description = "\n".join(description_lines) if description_lines else "无有效修改" return PRDraft(title, changed_files, description, all_issues)

这段代码的核心价值在于展示一个 Agent 的完整骨架：任务解析、检索、生成、验证、PR 输出。真实项目中，generate_code可以替换为模型调用，retrieve_files可以替换为向量检索，run_quality_gate可以替换为真正的 CI 脚本。

4.5 运行入口与结果验证

下面写一个主入口文件，演示如何运行这个 Agent。

# 文件路径：pr-agent-demo/main.py """运行示例 PR Agent。""" from agent import CodePRAgent from mock_repo import MockRepo def main(): repo = MockRepo() agent = CodePRAgent(repo) # 模拟一个任务 task = "用户校验函数需要增加空密码判断" pr = agent.create_pr(task) print("=== PR 标题 ===") print(pr.title) print() print("=== 修改文件 ===") for f in pr.files: print(f) print() print("=== PR 描述 ===") print(pr.description) print() print("=== 质量检查 ===") if pr.issues: for issue in pr.issues: print("-", issue) else: print("未发现明显问题") if __name__ == "__main__": main()

运行命令：

cd pr-agent-demo python main.py

预期输出示例：

=== PR 标题 === feat: 用户校验函数需要增加空密码判断 === 修改文件 === user_service.py user_service_test.py === PR 描述 === - 修改 `user_service.py`，处理任务：用户校验函数需要增加空密码判断 - 修改 `user_service_test.py`，处理任务：用户校验函数需要增加空密码判断 === 质量检查 === - 测试执行失败

因为user_service_test.py中引用了validate_user却没有引入模块，所以测试检查会失败。这里真实反映了 Agent 生成代码后，必须经过质量验证才能进入下一步。

下面我们修复一下测试文件，让 Agent 生成的代码能够通过验证。

# 文件路径：pr-agent-demo/mock_repo.py 中 user_service_test.py 内容调整为 def test_validate_user(): from user_service import validate_user validate_user("alice", "123456")

重新运行后，质量检查会变成：

未发现明显问题

这个例子虽然简单，但已经覆盖了 Agent 工作的五个核心步骤：任务解析、代码检索、代码生成、质量检查、结果输出。你可以将它继续扩展为一个真实可用的 PR 机器人。

5. 控制 AI 成本的关键设计

5.1 按需调用，绝不无脑请求大模型

在 AI Agent 系统中，大模型调用是最昂贵的环节。控制成本的第一原则就是：能不调用就不调用。

上面的示例代码中，check_style和run_test都没有使用大模型，而是用普通 Python 逻辑完成。这就是成本控制的核心思路：把能够规则化的任务交给传统工具，大模型只负责需要理解和生成的复杂环节。

真实项目中，这个原则可以进一步扩展。比如代码格式化直接交给black，import 排序交给isort，基础 bug 检测交给pylint或sonarqube，只有在这些工具无法判断的语义层面问题，才调用大模型。

这里需要特别说明一下 SonarQube 的作用。SonarQube 是一套静态代码质量扫描平台，可以对本地代码进行重复率、复杂度、潜在 bug、安全漏洞等维度的扫描。在 Agent 生成的 PR 合入前，通过 SonarQube 扫描可以大幅减少低级问题漏网的概率。它和基于大模型的代码评审并不冲突：前者负责确定性规则，后者负责语义理解，两者各司其职，成本却能差出几个数量级。

5.2 相似请求走缓存和模板

大量 Agent 任务其实是相似的。比如“给所有 Controller 层补充参数校验”“更新所有equals方法实现”等，都存在高度模式化。

工程上可以建立两层缓存：

第一层是结果缓存。如果同一个任务、同一个代码文件、同一个模型参数已经生成过结果，直接复用。这不仅节省 Token，还让代码风格更稳定。

第二层是模板缓存。针对常见的任务类型，准备好代码生成模板，Agent 只需要填入具体变量，不需要每次都让模型从零生成。例如，为“新增 CRUD 接口”设计固定模板，Agent 只需要确定对象字段即可。

5.3 合理控制上下文长度

大模型的计费通常与输入 Token 数量相关。如果每次调用都把整个项目代码塞进上下文，成本会迅速失控。

更合理的做法是：先把代码检索结果做裁剪，仅把与任务直接相关的函数、类、文件片段送入模型。如果你的 Agent 需要理解项目整体结构，可以先把全局结构用文字描述，再按需读取具体文件。

这本质上是一种 RAG（检索增强生成）的思路。检索步骤越精准，送入模型的 Token 越少，生成质量反而可能更高，因为模型不会被无关代码干扰。

5.4 建立成本观测与配额机制

最后，任何 Agent 系统上线前都应该先建立成本观测。

建议在每次模型调用时记录：

• 任务类型
• 模型名称
• 输入 Token 数量
• 输出 Token 数量
• 调用耗时
• 是否命中缓存

然后按任务类型聚合，找出哪些任务消耗成本最高，哪些任务可以用更经济的方式替代。如果某个高频任务的成本超过预期，就应该迭代 Prompt 或模板优化，而不是简单换一个更贵的模型。

6. 常见问题与排查思路

6.1 Agent 生成的 PR 质量不稳定

6.2 AI 成本持续上涨

6.3 人工评审成为新瓶颈

6.4 Git 冲突与 PR 积压

实际团队中非常容易遇到“Agent 生成大量 PR，但主干代码不断变化，导致 PR 发生冲突”的场景。这跟人类开发者提交大量 PR 遇到的情况一样，但 Agent 的提交速度会让这个问题成倍放大。

常用解决办法是：

• 控制 Agent 的并发任务数，不要一次铺开太多分支。
• Agent 创建 PR 后，立即在干净的主干分支上进行一次模拟合并，提前发现冲突。
• 如果冲突积累较多，不要让 Agent 在旧分支上反复修复，而是定期重新刷新分支基线。
• 借助 CI 脚本在 PR 标题或标签中标记“自动生成”，让评审者优先处理高风险改动。

6.5 模型响应超时或不可用

Agent 系统依赖外部模型服务时，偶尔会遇到类似“the agent execution provider did not respond in time”的超时错误。虽然这通常不是代码逻辑问题，但对生产环境影响很大。

建议措施：

• 所有模型调用都设置超时时间和重试机制。
• 对不可重试的幂等性操作，统一走离线队列。
• 对关键路径，准备规则引擎或本地模型作为降级方案。
• 记录超时发生的时间和任务类型，评估是否需要更换服务商或调整并发。

7. 最佳实践与工程建议

7.1 从低风险任务开始试点

不要一开始就把 Agent 放到核心支付链路或数据迁移任务上。建议从以下任务开始：

• 单元测试补全
• 代码注释生成
• 依赖版本升级
• 静态代码规范修复
• 错误日志标准化

这些任务出错影响面小，更容易获得团队信任。

7.2 设计完整的 PR 模板

Agent 生成的 PR 必须要有结构化描述，建议模板中包含：

## 任务背景 简要描述这个 PR 要解决的问题 ## 变更内容 - 文件列表和主要修改点 ## 测试验证 - 本地测试结果 - CI 执行状态 ## 风险说明 - 需要人工重点关注的逻辑 - 可能的兼容性影响

清晰的结构化描述能大幅降低评审成本，也让 Agent 的“产出”真正可追踪。

7.3 建立安全边界与权限控制

Agent 涉及代码写入时，必须严格遵循最小权限原则。

建议做到：

• Agent 只拥有创建分支、提交代码、创建 PR 的权限，不直接拥有主干合并权限。
• 涉及生产环境的配置修改，需要额外审批流。
• 数据库变更类 PR，禁止 Agent 直接操作生产库。
• 所有 Agent 生成的内容都保留完整审计日志。

这里需要强调的是，Agent 只是效率工具，权限边界最终仍然要由工程团队控制。不要让 Agent 拥有它不需要的高权限，否则一旦出现漏洞或越权行为，影响范围会非常大。

7.4 定期复盘 Agent 的错误模式

团队可以定期复盘 Agent 生成的 PR 中，哪些被人类评审者打回，哪些在生产环境引发问题。将这些错误模式整理成新的 Prompt 约束或静态检查规则，形成正向循环。

例如，如果经常发现 Agent 忽略了空列表的边界条件，就在 Prompt 中加入“所有列表参数必须校验空列表”；如果经常忘记添加超时控制，就把“外部调用必须设置超时”固化为静态检查规则。

7.5 保持人与 Agent 的合理分工

最后一条建议，也是最重要的一条：不要追求 100% 自动化。

人类工程师的优势在于架构思考、业务理解和风险判断。Agent 的优势在于执行速度、模式识别和大规模重复操作。理想的团队形态是：Agent 负责生成和初筛，人类负责决策和质量兜底。

如果某个环节完全自动化导致质量下降，就把它切回半自动模式。技术是服务于团队的，而不是反过来。

8. 总结与学习路线

这篇文章从 Uber 的工程实践出发，梳理了 Agent 在代码 PR 流程中的位置、成本控制思路和工程落地路径，并提供了一个完整的 Python 示例。核心收获可以归纳为几点：

第一，Agent 接管大量 PR 并不等于 AI 替代程序员，它更多是把人类从重复劳动中解放出来，让人工评审聚焦在真正重要的问题上。

第二，控制 AI 成本的关键在于分层设计：规则引擎处理简单任务，小模型处理中等任务，大模型只处理最复杂的理解和生成任务。

第三，Agent 进入生产流程之前，必须建设好质量护栏、权限边界和成本观测。没有这三样东西，Agent 大规模接入带来的风险会大于收益。

如果你接下来想继续深入，可以按以下路线学习：

1. 掌握 Python 代码检索与分析基础，包括文件读取、AST 解析、静态检查工具使用。
2. 学习 RAG 原理，了解如何把大型代码库高效索引并检索给模型使用。
3. 研究 Agent 框架，比如 LangGraph、AutoGen、Spring AI 等，理解任务规划、工具调用和多 Agent 协作的通用模式。
4. 动手做一个完整的 PR 自动化机器人，接入真实 Git 仓库和 CI 流水线，把本文的示例改造成可运行的小工具。

AI 辅助开发的方向还在快速演变，但有一点是确定的：真正能落地的 Agent 工程，一定是“AI 能力 + 工程体系 + 成本控制”三者结合的结果。单纯追求模型的“聪明程度”，反而容易忽略流程设计的重要性。希望这篇文章能帮你建立这方面的整体认知。