过去一年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 负责生成 PRCI 负责自动验证 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.py4.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 的主逻辑类。这个类的工作流程是接收任务描述。调用仓库检索找到相关文件。读取文件内容。生成代码修改建议这里用关键字规则模拟 LLM 输出。调用工具链验证。生成 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 fPRDraft(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 ffeat: {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 逻辑完成。这就是成本控制的核心思路把能够规则化的任务交给传统工具大模型只负责需要理解和生成的复杂环节。真实项目中这个原则可以进一步扩展。比如代码格式化直接交给blackimport 排序交给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 质量不稳定问题现象常见原因解决思路代码逻辑正确但风格混乱没有给模型提供项目代码规范作为上下文在 Prompt 中加入编码规范、历史 PR 示例生成的代码无法编译Agent 没有实际运行编译工具链在质量检查阶段强制加入编译、单测步骤缺少必要的异常处理任务描述中未包含质量要求在 Agent 的任务模板中固化异常处理和边界检查要求6.2 AI 成本持续上涨问题现象常见原因解决思路同一个问题反复调用模型缺少缓存或记忆机制增加结果缓存、相同任务去重输入 Token 消耗过高上下文包含无关文件优化代码检索策略裁剪上下文简单任务也调用大模型任务路由不合理建立任务分级机制简单任务走规则或小模型6.3 人工评审成为新瓶颈问题现象常见原因解决思路评审者不愿看 Agent 生成的 PRPR 描述不清晰自动生成结构化 PR 描述突出风险点评审意见反复绕回同一类问题Agent 没有学习评审反馈收集历史评审意见反馈进 Agent Prompt 或模板大量 PR 排队等待评审自动化生成速度远大于人类评审速度为 Agent 生成 PR 设置配额控制并发数量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 大规模接入带来的风险会大于收益。如果你接下来想继续深入可以按以下路线学习掌握 Python 代码检索与分析基础包括文件读取、AST 解析、静态检查工具使用。学习 RAG 原理了解如何把大型代码库高效索引并检索给模型使用。研究 Agent 框架比如 LangGraph、AutoGen、Spring AI 等理解任务规划、工具调用和多 Agent 协作的通用模式。动手做一个完整的 PR 自动化机器人接入真实 Git 仓库和 CI 流水线把本文的示例改造成可运行的小工具。AI 辅助开发的方向还在快速演变但有一点是确定的真正能落地的 Agent 工程一定是“AI 能力 工程体系 成本控制”三者结合的结果。单纯追求模型的“聪明程度”反而容易忽略流程设计的重要性。希望这篇文章能帮你建立这方面的整体认知。