Anthropic 2026 趋势报告 + Codex 实践路径

作者：老李 / AI 时代的互联网架构师undefined

原报告：Anthropic《2026 Agentic Coding Trends Report》

实践参照：OpenAI《Harness Engineering: Leveraging Codex in an Agent-First World》

引导图：软件开发范式的三次跃迁

一、痛点：「AI 用了，但我们还在手动改 BUG」

「问君能有几多愁，恰似满屏红波浪。」

老李最近在做一个 Java 微服务架构的技术评审。一位资深工程师把自己的「AI 使用日志」发给他看：

• 每天用 AI 写代码：6 小时以上
• 完全放手让 AI 跑完一个功能：几乎没有

这不是个例。Anthropic 在 2026 年 1 月发布的趋势报告里，用一个数字戳破了行业泡沫：

开发者约 60% 的工作会用到 AI，但能完全委托给 AI 的任务，只有 0–20%。

这就是「协作悖论」——AI 已是日常伙伴，但距离「甩手掌柜」还差得远。问题不在模型能力，而在编排、验证、组织设计三个层面，工程团队还没跟上。

而 OpenAI 的 Harness Engineering 实践，刚好给出了一套穿越这条鸿沟的路径：用 Codex 从空仓库开始，5 个月 3 人团队写出百万行代码——不是靠「AI 更聪明了」，而是靠系统性地为 Agent 建造工作环境。

二、是什么：8 大趋势，3 个层次

「横看成岭侧成峰，远近高低各不同。」

报告把 8 条趋势分成三层：

一句话核心判断：

软件开发从「以写代码为中心」转向「以编排 Agent 写代码为中心」——人的判断、监督、验证依然不可替代。

三、为什么重要：工程师角色正在质变

「纸上得来终觉浅，绝知此事要躬行。」

报告里有一句 Anthropic 工程师的原话，老李觉得值得所有程序员反复读：

「我主要在已经知道答案应该长什么样的场景用 AI。这种能力是我以前『硬啃』软件工程练出来的。」

这揭示了一个残酷的真相：会用 AI 的前提，是你先得懂行。

工程师角色正在发生三个方向的质变：

Augment Code 案例（基于 Claude）：CTO 估计 4–8 个月的项目，两周完成。

Rakuten 案例：1250 万行 vLLM 代码库，Claude Code 单次运行 7 小时，数值精度对比参考实现达 99.9%。

四、架构图：Codex 多 Agent 工作流（Harness Engineering 模式）

「众人拾柴火焰高，独木难支大厦倾。」

OpenAI 内部的 Harness Engineering 实践，把理论框架变成了可复制的工程模式。其核心架构如下：

关键设计点：

• AGENTS.md 是 Agent 的「宪法」，写清楚代码规范、测试命令、禁止操作
• Worktree 隔离：每个任务独立 git worktree，App + 日志 + 指标各自隔离，互不干扰
• Ralph Wiggum Loop：Codex 自审 → Agent 同行评审 → 循环直到所有审核者满意 → 才提 PR
• 可观测性注入：把日志、指标、追踪直接暴露给 Codex，让 Agent 能用 PromQL/LogQL 验证自己的输出

五、实践路径：从「辅助」升级到「编排」的四步走

「不积跬步，无以至千里；不积小流，无以成江海。」

Harness Engineering 的实践告诉我们：早期进展慢，不是因为 Codex 不够强，而是因为环境还没准备好。真正的工程师工作，是为 Agent 建造工作环境。

Step 1 — 写好 AGENTS.md（环境定义，立刻可做）

这是整个体系的起点。OpenAI 的 AGENTS.md 本身也是 Codex 写的——这很有象征意义。

# AGENTS.md 最小模板（Java/Spring Boot 项目）

## 代码规范
- 遵循 Google Java Style Guide
- 所有 public 方法必须有 Javadoc
- 禁止直接操作生产数据库，统一走 Repository 层

## 测试命令
- 单元测试：mvn test
- 集成测试：mvn verify -P integration
- 测试通过后才允许提 PR

## 禁止操作
- 不得修改 pom.xml 的 parent 版本
- 不得删除 src/main/resources/application-prod.yml

## PR 规范
- 标题格式：[类型] 简短描述（feat/fix/refactor/test/docs）
- 必须附上改动影响范围说明

Step 2 — 建委托分级清单（风险控制）

把你的日常任务按「委托风险」分级：

Step 3 — 为 Agent 注入可观测性（让 Agent 能自验证）

Harness Engineering 最关键的一步：让 Codex 能直接查日志和指标，不依赖人工告诉它「跑起来了没有」。

# 为每个 worktree 启动隔离的本地可观测性栈（示例）
docker compose -f observability/docker-compose-worktree.yml up -d

# Codex 可以直接执行（已在 AGENTS.md 中声明权限）
# 查询启动延迟
curl -G 'http://localhost:9090/api/v1/query' \
  --data-urlencode 'query=histogram_quantile(0.99, service_startup_duration_seconds_bucket)'

# 验收条件直接写进 prompt：
# "ensure service startup completes in under 800ms"

Step 4 — 建立 Agent 自审循环（减少人工 Review 压力）

六、真实场景：一次限流重构，用 Codex 走完 Agentic Coding 全流程

「纸上得来终觉浅，绝知此事要躬行。」

下面是一个真实感场景，老李拿一个高频痛点来演示：电商订单服务限流方案从单机 Guava 升级到分布式 Sentinel。这个场景在互联网公司里几乎人人踩过，改动范围跨越多层，既有明确验收标准，又有业务风险——是测试 Agentic Coding 成色的好靶子。

背景与任务定义（人的工作）

团队有一个 Spring Boot 3.4 订单服务，当前用 Guava RateLimiter 做单机限流，在多实例部署下限流阈值被各节点独立计算，高峰期实际放行量是预期的 N 倍。需要迁移到 Sentinel 分布式限流，并接入 Prometheus 指标暴露。

老李作为架构师，人工定义的输入：

任务目标：

将 OrderController 的限流实现从 Guava RateLimiter 替换为 Sentinel 注解

暴露 /actuator/sentinel 指标端点，接入 Prometheus

验收标准（写进 AGENTS.md 的 Acceptance Criteria）：

1. mvn test 全通过（含 OrderControllerTest 限流行为测试）
2. 压测 200 rps，P99 响应时间 < 800ms
3. /actuator/prometheus 可见 sentinel_qps_total 指标
4. 不得修改 OrderService 业务逻辑层
5. 不得删除原 Guava 依赖（其他模块仍在用）

对应 Anthropic 趋势：

趋势1 SDLC 重写：工程师从「写实现」变成「写验收标准」

趋势4 智能监督：验收标准即监督协议

AGENTS.md 扩展配置（本次任务专用）

# AGENTS.md — 订单服务限流重构专项

## 任务边界
- 允许修改：OrderController、pom.xml（限流相关依赖）、application.yml（Sentinel 配置）
- 禁止修改：OrderService、OrderRepository、application-prod.yml
- 禁止删除：guava 依赖（scope 不变）

## 测试命令（Agent 必须全部通过才能提 PR）
mvn test -pl order-service
mvn verify -P integration -pl order-service

## 可观测性验收命令（Agent 自验证）
# 启动服务后执行，返回值 > 0 则通过
curl -s http://localhost:8080/actuator/prometheus | grep sentinel_qps_total | wc -l

## 限流行为验收（Agent 自动执行）
# 用 hey 压测，检查 429 比例是否在预期区间
hey -n 1000 -c 50 http://localhost:8080/api/orders

三 Agent 并行 Worktree 拆分（趋势2：多 Agent 协同）

并行价值：三个 worktree 同时跑，总耗时约等于最慢那个任务（测试 Agent），而不是三者串行之和。对应 趋势2：多 Agent 并行处理，性能收益来自上下文窗口的独立并发。

Codex 工作日志（节选，带理论标注）

以下是这次重构中 Codex Agent 的真实工作片段，老李加了理论标注：

① 实现 Agent — Worktree A

Codex Agent / Worktree A

读取 AGENTS.md ✓

读取 OrderController.java ✓

计划：

1. 在 pom.xml 中添加 sentinel-spring-webmvc-adapter
2. 将 @RateLimiter(name="orderCreate") 替换为 @SentinelResource(value="orderCreate", blockHandler="handleBlock")
3. 新增 SentinelConfig.java 注册流控规则
4. application.yml 追加 sentinel.transport.dashboard 配置

执行 mvn dependency:resolve ... ✓

修改 OrderController.java ... ✓

新建 SentinelConfig.java ... ✓

自检：grep -n "GuavaRateLimiter" src/main/java/ → 0 结果 ✓

自检：grep -n "OrderService" 改动 diff → 0 行 ✓ （未碰业务层）

提交给 Review Agent 审查

对应趋势1：Agent 自动执行「grep 检查禁止操作是否被触碰」，这是 SDLC 内嵌验证的具体形态。

② 测试 Agent — Worktree B

Codex Agent / Worktree B

运行 mvn test ...

FAIL: OrderControllerTest.testRateLimitExceeded

Expected: HTTP 429

Actual: HTTP 200

分析：Sentinel 默认规则未加载，需在测试上下文初始化 FlowRule

修复：新增 SentinelTestConfig.java，在 @BeforeEach 注册 FlowRule（QPS=10）

重新运行 mvn test ... 全部通过 ✓

执行 hey 压测 200 rps ...

P99 = 743ms ✓（< 800ms 验收线）

429 比例 = 18.3%（符合 QPS=200 * 限流率预期）

自验证通过，提交 Review Agent

对应趋势4：Agent 发现测试失败 → 自主分析原因 → 修复 → 重跑，全程未打扰工程师。这正是「AI 审查 AI」的质控闭环。

③ 可观测性 Agent — Worktree C

Codex Agent / Worktree C

配置 SentinelMeterBinder @Bean ... ✓

application.yml 追加 management.endpoints.web.exposure.include: prometheus,sentinel ✓

自验证（AGENTS.md 中声明的命令）：

curl http://localhost:8080/actuator/prometheus | grep sentinel_qps_total | wc -l

→ 返回: 3 ✓（> 0，通过）

生成 Grafana Dashboard JSON（sentinel-order-dashboard.json）

面板：QPS 趋势、拒绝率、P99 延迟

提交 Review Agent

对应趋势3：可观测性 Agent 不只是「配置完就走」，而是用自验证命令确认指标真实可用——这是长时 Agent 自主运行的可信基础。

Ralph Wiggum Loop：Agent 交叉审查（趋势4 精华）

老李注：这个 Agent 交叉审查环节，把「三个专业 Agent 各自有盲区」的问题结构性消除了。测试 Agent 不懂 Bean 生命周期，可观测性 Agent 不跑压测——但两者联合审查，覆盖面远超单 Agent。

人工介入点：只审架构决策（趋势4 的「人只看关键决策」）

Agent 提 PR 后，老李作为架构师只审以下三个问题：

整个人工审查时间：17 分钟。 三个 Agent 并行跑完的时间：约 40 分钟。

对比传统方式（一个工程师全程手写 + 人工测试 + 人工验证指标）：估计 2–3 个工作日。

对应趋势6：生产力收益不只是速度，而是「以前要 PO 排进下个 sprint 的任务，现在当天就能完成」。这正是 Anthropic 报告说的「27% 以前根本不会做的工作变得值得做」——Nacos 持久化那个 backlog item，下次直接交给 Agent。

七、三条洞见

「吾日三省吾身。」

洞见一：AI 带来的是「产出量增加」，不只是「速度加快」

Anthropic 内部研究发现：工程师每个任务类别时间净减少，但产出量净增加更多。约 27% 的 AI 辅助工作，属于以前根本不会去做的任务。

Harness Engineering 印证了这一点：那个团队用 Codex 做了大量「以前不会排进 sprint」的工作——自动化 UI 回归测试、服务启动性能验证、内部 DevTools 脚手架——每件单独看都「不值得」，合在一起形成了护城河。

给团队的行动：把「以前因人力不够而搁置的技术债和优化项」拿出来，重新评估 ROI，现在很可能划得来。

洞见二：「协作悖论」的突破口是「为 Agent 建造工作环境」

Harness Engineering 的原话值得刻进工位：

「早期进展慢，不是因为 Codex 不够强，而是因为环境还没准备好。我们的首要工作是让 Agent 能做有效的工作——深度分解目标、构建基础能力块，再用这些块解锁更复杂的任务。」

给个人的行动：不要问「这个 AI 够不够强」，要问「我给 AI 的工作环境准备好了吗」。

洞见三：安全是 Agentic 时代的基础设施，不是事后补丁

Codex CLI 的沙箱默认断网，文件操作限制在当前目录树，命令执行需要显式批准——这不是限制，这是让工程师敢放手的前提条件。

给团队的行动：在 Agent 能触碰生产环境之前，Worktree 隔离 + 断网沙箱 + AGENTS.md 禁止操作清单必须到位。

七、结论：从「用 AI 写代码」到「为 AI 建造工作环境」

「知之者不如好之者，好之者不如乐之者。」

老李读完这两份材料，有一个判断越来越清晰：

Anthropic 报告告诉你「去哪儿」，Harness Engineering 告诉你「怎么走」。

核心结论是三句话：

1. 协作悖论的根源不是模型能力，而是工程环境。Codex 跑不好，大概率是 AGENTS.md 没写好、测试命令不对、可观测性没接入。
2. 人的稀缺资源是注意力，不是代码。Harness Engineering 3 人 5 个月 100 万行代码，靠的是把人的注意力集中在「环境搭建」和「关键决策」，而不是「盯着 AI 逐行改代码」。
3. 从 L2 到「完全委托」只差一步：让 Agent 能自己验证输出。接入日志、指标、测试，让 Agent 用 PromQL/LogQL 问「我的改动对了吗」——这才是委托比例从 20% 跳到 80% 的关键跃迁。

方法论速查表