AI编码代理内部原理：Uber 25%代码提交背后的架构与实战

作者提米哥

2026年第一季度，Uber的所有代码提交中，有25%来自Claude Code。不是试点项目，不是黑客松实验——是真正进入生产环境的提交。来自地球上最复杂、多服务、多语言的工程组织之一。

更惊人的是，Anthropic在2026年第二季度营收预计达到109亿美元，首次实现盈利。而SpaceX提交的S-1文件中悄悄披露，Anthropic签了一份每月12.5亿美元的算力合同，用于Claude的推理（inference）——不是训练模型。当一家公司每月花十亿美元只为给用户返回结果时，这项技术已经从“有前景的技术”变成了 关键基础设施。

对于开发者来说，这些信号意味着：AI编码代理不是未来，而是现在。理解它们真正工作原理的工程团队，才能从中获得超额价值。

本文就是那张深度技术地图。

AI编码代理到底有什么不同？

先分清两个概念：编码助手与编码代理。

编码助手（比如早期的Copilot或ChatGPT在代码场景下）工作在一个严格的请求-响应循环里：你给提示，它返回文本。它没有记忆，只能看到你粘贴的内容，不能运行代码，不能读文件系统，不能验证自己的建议是否能编译。本质上是一个超级智能的自动补全。

编码代理是完全不同的东西。关键差异在于 工具使用 + 自主循环。

一个代理可以：

  • 读取你实际的文件——而不只是你粘贴的片段
  • 执行shell命令、测试套件、构建系统
  • 搜索网络和文档，实时获取信息
  • 编辑文件、暂存更改、创建提交
  • 链式操作数十步，无需你确认
  • 纠正错误——当某一步失败时，像人类工程师一样自动调整方向

理念上的转变：从“回答代码问题的AI”变成了“真正干工程活的AI”。这对你如何交互、如何衡量产出、如何管理成本，都有着深远影响。

代理循环（Agentic Loop）：核心架构

Claude Code（以及类似的OpenAI Codex）的核心运行机制，被Anthropic工程团队称为 代理循环 ——一个三阶段循环，直到任务完成或你中断为止。

第一阶段：收集上下文

在碰任何代码之前，Claude首先要建立对代码库的心理模型。这个阶段包括：

  • 读取 CLAUDE.md 和 MEMORY.md（持久化指令文件）
  • 遍历目录结构，了解项目布局
  • 使用 glob 和正则搜索与任务相关的文件
  • 读取 git 历史，理解已有代码的意图
  • 获取你在提示中引用的文档网址

这个阶段主要由只读工具调用组成。模型通过把信息累积到上下文窗口中来构建工作记忆——这是一个我们马上要详细讲的关键资源。

第二阶段：采取行动

一旦上下文足够，Claude开始执行。根据任务不同，可能包括：

  • 写入或编辑源文件
  • 运行测试套件建立基线
  • 做精准的编辑
  • 运行构建命令检查编译错误
  • 使用 git diff 查看变更

行动不是静态的预定序列。模型根据上一步的输出决定下一步做什么。一个失败的测试输出会反馈到循环中，触发另一轮读取、编辑和重新运行。

第三阶段：验证结果

验证是区分好的Claude Code体验和糟糕体验的关键。当你给Claude一个可验证的成功标准（比如“测试套件通过”、“linter零警告”、“服务器在 /health 返回200”），它可以自动运行验证并循环回去修复剩余失败。

如果没有验证标准，代理就是在盲飞。它产生的输出看起来正确但不一定正确，而你就成了唯一的反馈机制。

关键洞察： 代理循环不是一条线性的管道。它是一个可以嵌套、分支和重试的控制流——就像工程师解决一个问题时的做法。你的角色是定义目标和验收标准，而不是指定每一步。

工具生态：代理如何操作你的代码库

代理循环由一组工具驱动，让模型拥有超越文本生成的能力。Claude Code内置的工具分类如下：

文件操作：读取文件、写入/编辑代码、创建新文件、重命名和重组。

搜索：按模式查找文件（glob）、用正则搜索内容、探索大型代码库。

执行：运行shell命令、启动开发服务器、调用测试运行器、使用git。

Web：搜索网络、获取API文档、实时查找错误信息。

代码智能：查看编辑后的类型错误和警告、跳转到定义、查找所有引用。

除了核心循环，Claude Code还支持扩展层：

  • MCP（模型上下文协议）服务器 —— 连接到外部服务（数据库、问题跟踪器、可观测性平台）
  • 技能（Skills） —— 自定义、按需的指令集，用于特定领域的工作流（类似于宏）
  • 钩子（Hooks） —— 在特定工具调用前后运行的shell脚本（例如每次写入后自动格式化）
  • 子代理（Subagents） —— 独立上下文窗口，用于委托子任务（下面会讲到）

设计理念是：Claude的基础能力默认是狭窄的——它只能做工具明确允许的事情——而你刻意地扩展它。这既是产品决策，也是成本控制机制。

上下文窗口：最关键的工程约束

如果你问Claude Code资深用户最重要的一点，他们会说：上下文窗口是你最宝贵的资源，而且它消耗得比你想象中快得多。

上下文窗口装着一切：

  • 你的初始提示
  • 每一条助手回复
  • Claude读过的每个文件（完整内容）
  • 每个shell命令及其完整输出
  • 整个对话历史

一个简单的调试会话，读10个中等大小的源文件，运行测试套件三次，再探索几个依赖的实现，可以轻松消耗 50,000–100,000个token。随着上下文填满，模型性能会明显下降：它开始忘记早期的指令，做出不一致的编辑，甚至自相矛盾。

实用的上下文管理策略

1. 不同任务使用全新会话。 不要尝试在同一会话中重构模块并实现新功能。重构带来的上下文污染会损害功能开发。

2. 使用子代理进行探索。 当你需要Claude先研究代码库再行动时，把探索任务委托给一个Explore子代理（它运行在自己的上下文中），这样搜索结果就不会冲爆你的主对话。

3. 保持CLAUDE.md简洁。 这个文件在每个会话开始时加载。每一行都会在每次任务中消耗token。Anthropic团队的规则：如果移除一行不会让Claude犯错，就移除它。

4. 限定文件引用范围。 不要直接说“看看整个auth模块”，而是引用具体文件：@src/auth/token_refresh.py。

5. 实时监控上下文使用量。 安装一个自定义状态行（Claude Code原生支持），像油量表一样实时追踪token消耗。

CLAUDE.md —— 新的开发者配置文件

每个成熟的软件项目都有配置文件：.gitignore、package.json、pyproject.toml、.eslintrc。这些文件编码了所有贡献者都遵守的项目级约定。CLAUDE.md是这个家族的最新成员——用于AI代理行为的配置文件。

当Claude Code启动一个会话时，它会在做任何其他事情之前读取项目根目录下的 CLAUDE.md。这个文件是你与代理之间持久化、版本控制的沟通渠道。把它看作给一个新承包商的简报：这是项目，这是我们怎么工作，这是规则。

一个精心编写的CLAUDE.md示例

# 项目：payments-service

## 架构
- Python 3.12，FastAPI，SQLAlchemy async
- PostgreSQL 16 via asyncpg
- 全部使用 async/await —— 不允许同步数据库调用
- 使用仓库模式：数据库层不能直接导入到路由中

## 代码风格
- Black格式化，行长度 88
- 使用 `from __future__ import annotations`
- 所有公开函数需要类型注解
- 类型注解中禁止使用 `Any`，除非绝对必要

## 测试
- pytest 配合 pytest-asyncio
- 运行测试命令：`make test`
- 优先使用单元测试而非集成测试；使用 `respx` 模拟 HTTP
- 禁止使用 `unittest.mock.patch` —— 使用依赖注入替代

## 工作流
- 每次代码更改后必须运行 `make lint && make typecheck`
- 先写失败的测试，再实现
- 提交信息格式：`type(scope): description` (Conventional Commits)

## 禁止事项
- 不要使用同步的SQLAlchemy会话
- 不要添加新依赖，除非先和我确认
- 不要用 `# type: ignore` 来压制类型错误

注意这个文件不是什么：它不是Python教程，也不是每个Python开发者都知道的标准约定。它只编码了项目特有的规则——这些规则Claude可能需要推测，而且可能猜错。

/init 命令可以通过分析你的代码库生成一个初始的 CLAUDE.md。用它作为基础，然后无情地修剪。

子代理编排：多代理模式

Claude Code最强大但最被低估的功能之一，是它对子代理编排的原生支持。子代理是独立的Claude会话，每个有自己的上下文窗口、系统提示、工具限制，以及（可选的）不同模型。

内置子代理

Claude Code内置三个子代理，会自动激活：

Explore（探索）：使用Claude Haiku（又快又便宜），只读权限，用于代码库搜索而不污染主上下文。

Plan（计划）：继承自父模型，只读权限，计划模式的研究阶段。

General-purpose（通用）：继承自父模型，所有工具权限，用于需要修改的复杂多步任务。

Explore代理值得仔细了解。当你让Claude“先理解认证流程再修复这个bug”时，Claude可以直接在你主会话中读取文件——但这会用上下文预算装进一堆可能不相关的搜索结果。相反，它会生成一个Explore子代理，读取所需文件，建立理解，然后向主会话返回一个摘要。原始文件内容永远不会出现在你的主上下文中。

编写自定义子代理

自定义子代理定义为带YAML前置元数据的Markdown文件。下面是一个安全审查子代理的例子：

---
name: security-reviewer
description: 审查代码变更中的安全漏洞、注入风险、认证问题和密钥泄露。
在审查PR或新端点时调用。
model: claude-opus-4-7
tools:
  - Read
  - Bash(git diff, git log)
permission_mode: plan
---

你是一名高级应用安全工程师。被调用时，你将：
1. 运行 `git diff HEAD~1` 查看最近更改
2. 检查SQL注入、XSS、SSRF和认证绕过模式
3. 扫描硬编码的密钥或凭据
4. 按严重程度（严重/高/中/低）报告发现，并给出修复建议

保持简洁。只报告真正的问题，而不是风格挑剔。

把这个保存到项目的 .claude/agents/security-reviewer.md。Claude会在上下文提示需要安全审查时自动调用它，或者你可以显式调用。

多代理并行模式

对于大型重构任务，你可以把工作分解成并行的子代理：

# 在你的主Claude Code会话中：
# "把这个重构拆成3个并行任务：
#  1. 更新所有测试到新的API签名
#  2. 更新所有路由处理器
#  3. 更新数据库层
# 每个任务生成一个通用代理，等三个都完成时报告。"

这个模式能极大加速大型可分解的任务，同时保持每个子代理的上下文窗口干净专注。

将AI编码代理集成到CI/CD流水线中

Claude Code不仅是个本地开发者工具。它自带一个生产级的GitHub Actions集成，能实现真正强大的自动化。

设置Claude Code GitHub Actions

# .github/workflows/claude-code.yml
name: Claude Code Agent

on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]
  issues:
    types: [opened, assigned]

permissions:
  contents: write
  issues: write
  pull-requests: write

jobs:
  claude:
    if: contains(github.event.comment.body, '@claude')
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          claude_args: |
            --model claude-sonnet-4-6
            --max-turns 15
            --append-system-prompt "严格遵循CLAUDE.md中的约定。所有任务完成前必须先运行测试。"

有了这个工作流，团队中任何人可以在GitHub issue上输入 @claude 实现issue中描述的排序功能，代理就会自动：读取issue、探索代码库、实现功能、运行测试套件、打开Pull Request——全自动。

每次提交自动PR审查

# .github/workflows/claude-review.yml
name: 自动代码审查

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            审查这个PR：
            1. 逻辑错误和边界情况
            2. 缺少的错误处理
            3. 性能问题（N+1查询、不必要的循环）
            4. 安全问题（注入、认证绕过、密钥泄露）
            5. 测试覆盖缺口

            不要评论代码风格——我们有linter做这个。
            将审查作为PR审查发布，附带行内评论。
          claude_args: "--model claude-opus-4-7 --max-turns 5"

定时维护代理

# .github/workflows/daily-maintenance.yml
name: 每日维护代理

on:
  schedule:
    - cron: "0 6 * * 1-5"  # 工作日早上6点

jobs:
  maintain:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            执行每日维护：
            1. 检查依赖安全公告（运行：pip-audit 或 npm audit）
            2. 更新所有只有补丁版本号增加的依赖
            3. 运行完整测试套件确认没有破坏任何东西
            4. 如果所有测试通过，打开一个标题为 "chore: 自动依赖更新 [日期]" 的PR
          claude_args: "--model claude-sonnet-4-6 --max-turns 20"

Token经济：成本、企业定价与优化

我们来谈谈钱——因为这是很多工程团队感到意外的地方。

直到2025年底，Anthropic企业客户采用固定席位定价，包含慷慨的用量。2025年11月，Anthropic转向API token定价，意味着你的团队在Claude Code中消耗的每个token都按公布的API价格计费。OpenAI在2026年4月对Codex也做了同样的转变。

Simon Willison在自己的30天使用数据上运行了 ccusage，发现如果按API价格算，他需要支付 1199.79美元 —— 而他只需要为Max订阅付100美元。使用编码代理的企业团队，每月账单高达四到五位数。

估算你的成本

下面是一个用于Claude Code成本估算的Python计算器：

# Claude Sonnet 4.6 近似价格
# （在生产中使用前请到 anthropic.com/pricing 确认当前价格）
SONNET_INPUT_COST_PER_MTok = 3.00   # 每百万输入token 3美元
SONNET_OUTPUT_COST_PER_MTok = 15.00  # 每百万输出token 15美元

# Opus 4.7（用于复杂任务）—— 发布前请确认这个数据
OPUS_INPUT_COST_PER_MTok = 15.00
OPUS_OUTPUT_COST_PER_MTok = 75.00

def estimate_session_cost(
    avg_context_tokens: int,     # 平均每个会话的输入token数
    avg_output_tokens: int,      # 平均每个会话的输出token数
    sessions_per_day: int,       # 每天有多少Claude Code会话
    model: str = "sonnet",       # "sonnet" 或 "opus"
    working_days: int = 22       # 每月工作日数
) -> dict:
    """
    估算一名工程师每月的Claude Code成本。

    参数：
        avg_context_tokens: 每个会话平均输入token数
        avg_output_tokens: 每个会话平均输出token数
        sessions_per_day: 每天Claude Code会话数
        model: "sonnet" 或 "opus"
        working_days: 每月工作日数
    """
    if model == "sonnet":
        input_rate = SONNET_INPUT_COST_PER_MTok / 1_000_000
        output_rate = SONNET_OUTPUT_COST_PER_MTok / 1_000_000
    else:
        input_rate = OPUS_INPUT_COST_PER_MTok / 1_000_000
        output_rate = OPUS_OUTPUT_COST_PER_MTok / 1_000_000

    sessions_per_month = sessions_per_day * working_days
    monthly_input_cost = avg_context_tokens * sessions_per_month * input_rate
    monthly_output_cost = avg_output_tokens * sessions_per_month * output_rate
    total = monthly_input_cost + monthly_output_cost

    return {
        "monthly_input_cost": round(monthly_input_cost, 2),
        "monthly_output_cost": round(monthly_output_cost, 2),
        "total_monthly_cost": round(total, 2),
        "sessions_per_month": sessions_per_month,
        "cost_per_session": round(total / sessions_per_month, 4)
    }

# 示例：一名工程师每天在Sonnet上运行8个会话
# 每个会话：~40K 输入token，~4K 输出token
result = estimate_session_cost(
    avg_context_tokens=40_000,
    avg_output_tokens=4_000,
    sessions_per_day=8,
    model="sonnet"
)

print(f"每月估计成本: ${result['total_monthly_cost']}")
print(f"每月会话数:     {result['sessions_per_month']}")
print(f"每个会话成本:   ${result['cost_per_session']}")
# 输出：
# 每月估计成本: $323.84
# 每月会话数:     176
# 每个会话成本:   $1.84

成本优化策略

  1. 路由到正确的模型。 普通实现任务用Sonnet，复杂的架构推理用Opus，仅探索用Haiku子代理。模型路由可以将成本降低60–80%。
  2. 在CI/CD中限制最大轮数。 自动化流水线中设置 --max-turns 10，防止代理在模糊任务上无限循环。
  3. 提升CLAUDE.md质量。 精准的CLAUDE.md减少来回纠正的循环。每消除一次迭代大约节省10K token。
  4. 将探索任务路由到Haiku子代理。 使用Haiku驱动的Explore子代理进行代码库搜索（成本大约Sonnet的0.25倍），只向主会话返回摘要。
  5. 设置团队预算和警报。 使用Anthropic Console的用量监控功能，为每个团队设置月上限和警报阈值，避免月底被账单吓到。

两个改变一切的拐点

为了理解为什么AI编码代理在现在爆发，而不是两年前ChatGPT刚发布时，你需要了解两个特定的拐点。

2025年11月：能力拐点

2025年11月之前，基于LLM的编码工具在生成代码方面令人印象深刻，但在自主完成工程任务方面不可靠。它们会幻觉API、忘记对话早期设定的约束、无法在工具错误后恢复而无需人类干预。

2025年11月，GPT-5.1和Anthropic的Opus 4.5发布——这是首批能可靠地端到端完成真实多步工程任务的模型，配合各自的代理框架。改进体现在长上下文一致性、工具使用可靠性、以及错误恢复推理上。实际结果是：工程师开始信任输出，并将其纳入生产工作流。

随后是六个月的加速采用——Simon Willison称之为“11月拐点”。

2026年4月：收入拐点

2026年4月是另一种拐点：商业模式到位的那一刻。Anthropic和OpenAI都发布了新前沿模型（Opus 4.7、GPT-5.5），API价格更高——同时将企业客户锁定在基于token的计费上。

那些一直在慷慨的固定费率合同下运行编码代理的企业客户，在续约时发现必须支付全价API价格。Uber的预算故事、微软取消Claude Code许可、以及Anthropic接近盈利——都可以追溯到这一结构性变化。

对于工程师来说，收入拐点发出一个明确信号：这些工具正在产生足够可衡量的价值，以至于客户愿意为其支付溢价API价格。这与“这是一个引人注目的demo”的信号截然不同。

为代理优先的工作流设计工程模式

采用AI编码代理不仅仅是安装一个工具——而是重新设计工作流。以下是一贯产生最佳结果的模式：

1. 验证优先的提示设计

# 弱提示——没有可验证的成功标准
"修复登录bug"

# 强提示——代理可以自主反馈循环
"用户报告登录在会话超时后失败。
问题在 src/auth/ 中。检查token刷新逻辑。
先写一个失败的测试来重现问题，修复它，然后确认测试通过。
覆盖：过期token、即将过期时的刷新、并发刷新请求。"

区别在于代理能否关闭自己的反馈循环。可验证的标准让代理循环自主运行到完成。

2. 先探索 → 计划 → 再编码（永远不要先编码）

抵制让Claude立刻开始编码的冲动。使用计划模式（在提示前加 /plan）强制进行只读的探索和计划阶段，然后再写任何文件。这个单一实践能消除最常见的失败模式：Claude用正确的代码解决了错误的问题。

3. 测试驱动的代理工作流

在实现之前先写（或让Claude写）一个失败的测试。这给代理一个清晰的自动化验证门。循环变成：

写失败测试 → 运行测试（RED） → 实现 → 运行测试（GREEN） → 提交

这模仿了传统的TDD，但代理驱动测试和实现。

4. 大任务分解为独立会话

对于需要超过约30分钟工作的任务，在开始前显式分解：

"在开始之前，把这个功能拆分成最小的一组独立任务，
按依赖顺序排列。我希望每个任务都作为单独的Claude Code会话运行。"

这避免了任务中途上下文溢出，并创建了自然的检查点，你可以从那里重新启动。

未来展望：AI编码代理将走向何方

每月12.5亿美元的推理账单不仅仅是一个财务数据点——它是计算投入方向的信号。有几个趋势值得密切关注：

模型硅片专用化。 通用GPU对推理工作负载来说从根本上效率低下。随着模型架构稳定，可以期待类似TPU对训练所做的那样，出现推理优化的ASIC。成本每token和延迟的阶跃式降低将使编码代理的运营成本大幅下降。

多代理群体用于大规模工程。 今天Claude Code中的子代理编排模式是一个“工程群体”的预览：一个高层编排器分解大型功能，分派给几十个专业代理并行工作，然后合成结果。如今的瓶颈是编排可靠性和上下文同步——而这两个都是活跃的开发方向。

扩展到软件工程之外。 编码代理之所以首先成功，是因为反馈循环（编译、测试、lint）异常紧凑和客观。可以期待类似的代理扩展到数据分析、金融建模、基础设施配置，以及任何具有结构化验证标准的知识工作领域。

双向模型蒸馏。 随着企业部署模式成熟，生产使用中的反馈循环将塑造微调的、特定领域的模型变体——更小、更便宜、更快，专门针对特定代码库或工程领域。

结论

AI编码代理不是一个附在现有工作方式上的生产力倍增器。它们是一个不同的范式——开发者的主要输出从写代码转变为指定目标、定义验收标准、并审查自主工程协作者的工作。

支撑这一转变的架构——代理循环、工具编排、上下文窗口管理、子代理并行、CI/CD集成——是可以学习和掌握的。现在投入理解这些系统的工程师，将在技术成熟时获得复利回报。

Uber的25%提交比例，到2027年将显得过时。那些理解架构、智能管理成本、并建立健壮的代理优先工作流的团队，将最先抵达那里。

准备好开始了吗？ 从你今天的待办事项中挑选一个任务。为你的项目写一个 CLAUDE.md。写一个失败的测试。交给代理。看看循环会带你到哪里。

微信联系：timidamen

类似文章