📌 本文为原创调研文章，发布于本站：haifeiWu.github.io
2026 年行业的主线很清楚：AI 从"能对话"转向"能干活"。各家大厂不约而同把重心从模型探索挪到了工程化交付，共识可以压缩成一个公式：
Agent = Model + Harness：模型只负责约 20% 的"思考"，剩下 80%（可靠性、上下文管理、工具调用、评测闭环）全得靠工程层兜底。
这篇调研的素材来自国内外大厂工程博客的一手实践（Uber、Meta、Stripe、Airbnb、Netflix、Google Cloud、Anthropic、美团、字节跳动、阿里云、腾讯云），每个主题按「概括 → 怎么做 → 最佳实践」三段展开，尽量写到能直接上手的颗粒度。
趋势一：AI Coding 规模化与"软件工厂"#
概括#
| 公司 | 数据 | 关键做法 |
|---|---|---|
| Meta | 50% 代码改动来自 DevMate | 把 AI 从编辑器补全下沉为源码控制工作流的基础设施层 |
| Uber | 70% PR 来自 agent，AI 支出却持平 | 四层模型 + 成本公式 + 托管 agent 舰队 |
| 美团 | 某团队 90%+ 代码 AI 辅助，31 万行重构零排期 | “人人对齐→人机对齐"治理方法论 |
三家的结论是一致的：AI Coding 不会自动收敛复杂度。没有统一规范约束，不同人用 AI 写出来的代码风格各异，系统反而腐化得更快。所以"工程治理"成了比"用哪个模型"更核心的问题。
怎么做#
美团 31 万行 AI 重构走的是四步路径（可以直接复用到任何团队）：
- 盘清技术债：核心开发圈定高危边界 → 让 AI 做穷举扫描 → 人来判断"什么重要”；
- 制定 AI 友好的研发规范：对齐分层原则、建模方式、依赖边界；
- 规范固化为 AI 可执行的 Rule/Skill：不落进工具链的规范就是一纸空文；
- 建立 Pre-PR 机制：提交前 AI 自查 + 自动生成 PR 文档，人工 CR 只看业务语义。
Uber 的"软件工厂"路径：
- 用四层使用模型（从专用到通用）组织 agent 会话，层越高，对成本/质量/模型的控制力越强；
- 用六项相乘的成本公式分解支出，找出能独立优化的项；
- 战略方向是收敛：从"交互式开发者工作流"走向全托管 managed agent（代码评审、自愈 CI、E2E PR、on-call 分诊）。
最佳实践#
- 规范要"人人对齐"再"人机对齐"：顺序错了，AI Rule 写得再好也会被不同人解释成不同版本。真正的瓶颈在人，不在工具。
- 主 R 打样 → SOP 分发：先让一个人跑通一个模块的完整迁移，把步骤沉淀成 AI 可执行的 SOP，再全组并行，省得每个人自己摸索。
- 技术债借业务需求"顺带"消化：把技术债拆成日常需求里的顺带动作，重构不必排专项。
- Pre-PR 不能省：AI 编码提速之后，CR 会变成新瓶颈，AI Coding 省下的时间最后全被 CR 吃回去。
趋势二：上下文工程（Context Engineering）#
概括#
Anthropic 说得很直接：上下文工程是提示工程的自然演进。提示工程研究的是"怎么写好一段指令"，上下文工程管的是"持续管理进入有限上下文窗口的 token 集合"。背后的原因是 context rot：上下文越长，模型召回越差。说穿了，上下文是边际收益递减的有限资源，模型有"注意力预算"。
Uber 的实测也能佐证：给足上下文，38 秒答对；不给，20 分钟、开 2 个子代理、错 3 次，结论还是错的。
怎么做#
Anthropic 给了四类上下文管理技术，顺序很重要，因为每一步都会改变下一步的输入：
- Write（写入）：把关键状态写到上下文之外的持久存储（NOTES.md、记忆工具）；
- Select（选择）：决定哪些信息源进入上下文窗口；
- Compress（压缩）：先结构化关键事实，再压缩上下文；
- Isolate（隔离）：当领域或 agent 冲突时，隔离各自上下文。
长任务（token 超过窗口）的三种技术：
- Compaction（压缩续接）：临近窗口上限时总结历史、开个新窗口接着干；关键在"保留什么/丢弃什么"，先调 prompt 把召回率做上去，再迭代提升精确率；最轻量的压缩是清除已完成的工具调用原始结果；
- 结构化笔记（agentic memory）：agent 定期写 NOTES.md / 待办，跨窗口持久化进度；
- 子代理架构：子代理各自深挖几万 token，只回传 1000–2000 token 摘要给主 agent。
Uber 的上下文工程实践：
- 构建 AI Context Graph（2400 万节点、8000 万边、30+ 系统），让 agent 用自然语言查询定位信息；
- CLI 工具解析：把 1000+ MCP 工具投影成 shell 命令，调用时才动态解析，不做 schema 预载；
- Code-mode：把多轮轮询（比如 SQL 查询）压成一个脚本循环，只把摘要带回上下文，token 省 50%~90%。
最佳实践#
- 指导原则：找"能达成目标的最小高信号 token 集合"。最小不等于短，要足够但不多余。
- 系统提示词写"正确的高度"：太硬（if-else 式脆逻辑）和太虚（泛泛而谈）都失败；用分节组织（
<background_information>、<instructions>、## Tool guidance）。 - 工具要少而精：工具集臃肿是头号失败模式。“如果一个人类工程师都无法确定该用哪个工具，就别指望 AI”，所以同时暴露的工具限制在 10–15 个，按领域分组、用子代理隔离。
- Just-in-time 检索优先于全量预载：维护轻量标识（文件路径、查询、链接），运行时按需加载。
- 上下文源头必须治理：技术失效的根因往往是"事实源本身错误或冲突"，所以上下文要受治理、带版本。
趋势三：评测驱动开发（Eval-Driven Development）#
概括#
Airbnb 给的定义：EDD 是 GenAI 版的 TDD，写 prompt 之前先写评测，然后对着评测集迭代，CI 里用分数门槛做门禁。他们有个核心洞察：LLM 输出是非确定的，“正确"与否很主观，往往得靠"AI 评 AI”，而评委这一环自己也会失效。
Airbnb 的五条 EDD 原则：
- 提前定义目标和门禁（优化什么、上线前必须满足什么）；
- 让真实错误引导指标（不要凭空造指标）；
- 评测器少而锋利：3–5 个校准好的 LLM-as-judge 胜过 20–30 个嘈杂的；
- 指定最终决策人（人对"好/坏"有分歧时拍板）；
- 持续协作（产品伙伴反复回答"X 比 Y 好还是差"）。
怎么做#
三种评测方法，分层使用：
- 程序化检查（第一道过滤）：JSON schema 校验、长度/空值、关键词/正则、经典 ML 指标（Precision/Recall/F1）、语义相似度。快、便宜、抓明显错误；
- LLM-as-Judge（虚拟评委）：用更强的模型按 rubric 评另一个模型的输出；
- 人工评测（金标准）：标注 ground truth、高风险场景、解决评委分歧。
虚拟评委的五条构建规则：
- 每个维度一个评委（不要"上帝评委"）；
- 评委模型 ≠ 生成模型；
- 给 few-shot 示例；
- 显式输出 schema；
- 评分标准清晰（人能一致套用的 rubric，LLM 才能套用）。
校准虚拟评委（不校准比没有更糟，纯给你虚假信心）：
- 造 50–100 条金标集，必须包含坏样例；
- 让虚拟评委跑金标集；
- 测一致性（Cohen’s kappa / Krippendorff’s alpha），目标 high 80s–90s%；
- 分析分歧 → 改 rubric、补 few-shot → 循环；
- 随失败模式演化定期重校准。
评测 agentic 系统要分三层（只看最终答案，坏路径就被盖住了）：
- Step-level：单次工具调用/推理步骤对不对；
- Trajectory-level：整体路径是否合理高效；
- Session-level：最终是否达成用户目标。
做法：利用 agent 的 trace（application root 下的 span 包含子 agent、工具调用、输入输出），用 DFS/树遍历把 trace 重建出来，针对特定 agent/subagent 做范围化评测。
最佳实践#
- “看数据"是唯一铁律：先把原型跑 100 个例子，逐条读输出和 trace，把错误归类，再动手建评测——这个习惯比任何框架都管用。
- 从 50–100 行起步，失败快、迭代便宜；低于 50 行，分数波动无意义；再分 dev 集和 held-out 测试集。
- 一次只变一个变量：先固定模型变 prompt，再固定 prompt 变模型，最后两个都固定，去变 serving 配置。
- CI 门禁：动 prompt 或 LLM 代码的 PR，用分数阈值（如 85%）卡住，并打印失败样例。
- 生产镜像评测：每天抽 5% 线上流量跑程序化检查+虚拟评委，每周人工复盘。
- 专家标注有分歧就停：先把人的分歧解决了，再谈自动化。
趋势四：规格驱动开发（Spec-Driven Development）#
概括#
SDD 的思路是把可执行规格当作唯一事实源，取代"代码是事实源”，这是从"vibe coding"走向"agentic engineering"的关键一步。流程不复杂：先写详细 Markdown 规格（目标、验收标准、技术约束、实现注记），再让 agent 执行。
怎么做#
- 规格结构：goals / acceptance criteria / technical constraints / implementation notes 四段；
- 并行 agent：用 Git worktree 隔离多个 agent 同时工作（一个后端、一个前端、一个测试），各自在独立工作区写，人工 review 后合并；
- 工具选型按规模：1–3 个 agent 用裸 Markdown 传参就够了；规模大了再上 board 编排、slash 命令强制、IDE 原生方案。
最佳实践#
- 规格里把"验收标准"写清楚，agent 才能自测自检；
- 并行写代码时必须隔离工作区（worktree），避免互相覆盖；
- 规格本身要版本化、受治理，不然又退化成上下文源头冲突的问题。
趋势五：MCP 工具接入与 Token 膨胀治理#
概括#
MCP 已经成了 agent 连接外部工具/数据的开放标准，取代自定义集成代码。但"直接用"有坑：标准 MCP 会把所有工具 schema 预载进每个会话。Uber 实测，装 100+ 工具就占 5万–7万 token，而且每轮都重发一遍。
怎么做#
- CLI 工具解析：把 MCP 工具投影成 shell 命令，调用时动态解析（Uber 用这招把 1000+ 工具清出了上下文）；
- 工具搜索：让模型按需搜索工具目录、只加载需要的工具；
- Code-mode：把多轮轮询压成一个脚本，中间过程不进上下文；
- Schema Negotiation（MCP 未来方向）：模型先看高层能力摘要，需要时再请求完整 schema。
最佳实践#
- 同时暴露的工具控制在 10–15 个；按领域分组、部署子代理隔离；
- 用 just-in-time 加载 + 缓存常用数据；增量取数（先取摘要/ID）；
- 工具 schema 跨工具复用；不要把大输出在后续 prompt 里反复贴；
- 生产环境还需要：异步任务编排（poll-and-notify 而非同步）、MCP server 健康检查、上下文生命周期管理（创建/更新/清理 + TTL）、短期会话内存和长期持久记忆分开。
趋势六：模型路由与成本优化#
概括#
通用最佳实践：小模型干简单活，旗舰模型干复杂活，成本能降 5–10 倍。Uber 把"子代理默认用更便宜的小模型"称为最有影响力的杠杆：主模型负责拆解与评估，子代理去执行定义明确、输入明确的任务。
怎么做#
Uber 的基准驱动模型选型（对所有托管 agent 都是同一套四步）：
- 用 agent 的真实工作建 benchmark；
- 在能服务任意模型（前沿/开源）的统一 harness 上跑；
- 切到帕累托最优（成本/完成任务、质量、可靠性三者权衡）的模型，并且持续切（前沿每几周就移动）；
- 用聚合洞察测试和部署模型路由策略。
成本公式（六项相乘，逐项独立测量/优化）：
总支出 ≈ 用户数 × 每用户会话 × 每会话轮次 × 每轮请求 × 每请求 token × 每 token 价格
前两项是"采用与参与"（要做大），中间三项是优化主战场（agent 为自己干活的额外开销）。
最佳实践#
- 交互式默认设置：初始会话模型 + 子代理模型两个默认值决定了 token 分配，其中子代理默认最值钱；
- 自动压缩阈值：哪怕模型有 1M 上下文，也在 400K 就触发压缩；
- 推理强度默认 Medium：输出 token（含推理）按输入 token 数倍计费，这是最高成本类别；
- Prompt 缓存 TTL 按"轮次间隔"选：交互会话用 1 小时 TTL，子代理用 5 分钟；
- 可见性反哺优化：状态栏放个实时成本计数器，再用会话分析仪表盘标记反模式。
厂商最佳实践速览#
| 厂商 | 核心实践 | 关键词 |
|---|---|---|
| Uber | 软件工厂：成本公式、上下文图、code-mode、managed agent | 全托管 agent、帕累托选型 |
| Meta | DevMate 嵌入源码控制工作流 | 基础设施层、50% 代码 |
| Stripe | “不能对 agent 耳语”：被动提示失败 | agent 只读上下文、字面、没耐心 |
| Airbnb | 评测驱动开发（EDD） | 看数据、50–100 行起步、校准评委 |
| Anthropic | 上下文工程 | 最小高信号 token、compaction、笔记、子代理 |
| Netflix | 自建 AI Platform 在自有基础设施 serve 大模型 | 工程化能力 > 建模能力 |
| Google Cloud | agentic 落地：客服/安全/文档处理 | 五层架构、不可靠微服务模式 |
| 美团 | 31 万行零排期 AI 重构 | 人人对齐→人机对齐、Pre-PR、SOP 分发 |
| 字节跳动 | Agent 实践手册、TARS、Trae Agent | 自研 Doubao-Seed |
| 阿里云 | 通义灵码 AI IDE | 工程感知、长期记忆 |
| 腾讯云 | RAG/WorkFlow/Multi-Agent 平台 | 记忆工程、毫秒级 Runtime |
落地行动清单#
个人层面（三件立竿见影的事）：
- 给足上下文：提问带文件路径/代码片段/日志/目标，别让 agent 靠猜；
- 脚本替代多轮对话：让 agent 写脚本一次跑完，只看结果（对应 code-mode）；
- 简单活别用最强模型：子任务/机械活交给小模型。
团队层面（按优先级）：
- 规范"人人对齐"→ 固化为 Rule/Skill（美团）；
- 建立 Pre-PR + AI CR 机制，人工只审业务语义；
- 从 50–100 行开始建评测集，校准 3–5 个虚拟评委，接入 CI 门禁（Airbnb）；
- 收敛工具到 10–15 个，按领域分组、子代理隔离（Anthropic）；
- 建自己的上下文图 / 事实源治理（Uber）。
主要来源#
- eng.uber.com — Running a Software Factory Efficiently at Uber Scale
- stripe.dev — You can’t whisper at an AI agent
- airbnb.tech — Eval-driven development: lessons from evaluating GenAI at scale
- anthropic.com/engineering — Effective context engineering for AI agents
- engineering.fb.com（经第三方访谈转述）、research.netflix.com
- Google Cloud — AI agent trends 2026 report
- tech.meituan.com — 用 Agent 评测思路管理 AI Coding：31 万行代码 AI 重构实践
- 腾讯云开发者社区、阿里云开发者社区、字节跳动《Agent 实践手册》