- 2026H2 的 Agent 工程化实践进入"具体怎么干"阶段，5 个一线团队 + 1 套方法论提供了可量化的实践数据
- 核心发现: 所有团队都在解决同一个问题——让 Agent 在真实业务中稳定产出，而非只在 Demo 中好看
- 本文以对比表格为主，聚焦各团队在 Skill/Workflow/经验闭环/质量门禁四个维度的设计取舍
一、团队全景
| 团队/项目 | 背景 | 规模 | 核心指标 | 公开来源 |
|---|---|---|---|---|
| 腾讯 Vibe Flowing | 海外网络运营团队, AI 原生平台 | 非开发人员也能参与 | Anydev 3 分钟可用 | 腾讯技术工程 |
| 腾讯企业微信 | iOS 客户端, 9000+ 源文件 | 前端团队 | 94% AI 代码生成率 | 企业微信团队 |
| 阿里云 e2e delivery 2.0 | 云产品交付, 从 1.0"人操作 Agent"进化 | 项目级多 Agent 协同 | 单应用→项目级规模 | 悟壳/阿里云开发者 |
| 腾讯云 Skill 膨胀治理 | 自动修复系统 Skill 治理 | 单 Agent 工具 | 1500→300 行 | 郑姝雅/腾讯云开发者 |
| AgentLoop | 千问 AI 平台, Agent 经验闭环 | 模型无关 | SWE-bench +7.2pp | 马云雷 |
| 图工程 14 步 | ThinkInAI, 通用方法论 | 框架无关 | — | OpenCode Dynamic Workflows |
二、Skill 治理: 四个团队的四种策略
Skill 是所有团队的共同痛点——写完容易，维护难，膨胀后模型不听话。
| 维度 | 腾讯云 Skill 膨胀治理 | 企业微信红线机制 | Vibe Flowing Skills 预装 | e2e 2.0 Harness 物料 |
|---|---|---|---|---|
| 核心问题 | 自动修复导致 400→1500 行膨胀 | 需求定位上下文 10M+ token | 非开发人员能参与构建 | 多 Agent 共享标准 |
| 解决思路 | 分层 + 外置 + 正向指令 + 刹车 | YAML 单一真源 + 分层加载 | 代码即配置(装饰器注册) | App-Adr/App-Desc/App-Research 三件套 |
| 行数/粒度 | ≤500 行, 超则分拆 | ~6 Critical + ~30 Standard | 能力包粒度, 每 Skill 一个操作 | 分 develop/test 两包 |
| 防膨胀机制 | 行数预算 + 语义去重 + 单次上限 + 定期压缩 | 触发即停 + 模板化报告 | 组件化 + Storybook 减少重复 | 统计&Loop 飞轮反哺 |
| 核心原则 | 能外置不外置, 能正向不否定 | 脚本能判定的不走 LLM | CLI 替代脚本, 减少 token | 原则→宪法→规则→判例四层 |
取舍规律: Skill 不是越厚越好。企业微信 36 条红线覆盖 9000+ 文件项目, 腾讯云 300 行比 1500 行更好。关键是把"需要 LLM 判断"的部分压缩到最小, 其余通过脚本/CLI/外置参考解决。
Skill 膨胀 4 个根因 (腾讯云经验)
| 根因 | 机制 | 缓解措施 |
|---|---|---|
| Lost in the Middle | 开头 73% 遵循, 中间降 30-50% | 禁令写在最前 20-50 行 |
| 隐性冲突 | 规则间张力导致"静默择一", 失败 23-47% | 标注适用范围, 逐对检查 |
| 训练偏差 | 模型本能倾向(追加建议/关联概念/有用性) | 正向指令替代否定, 场景表格 |
| 上下文淘汰 | 多轮对话中早期指令被截断 | 关键规则重复首尾(三明治) |
三、流水线/Workflow 设计: 三种节奏
| 维度 | 企业微信 8 阶段 | e2e 2.0 五阶段 | Vibe Flowing SDD 三阶段 |
|---|---|---|---|
| 设计哲学 | 原子化, 每步输入/产出/退出标准均可机器校验 | 正反向双链路, 可追溯/可验证/可优化 | 命名约定即工作流, 轻量 |
| 阶段数 | 8 | 5 | 3 |
| 阶段详情 | 设计稿→拆解→定位→实现→编译验证→模拟器验证→沉淀→提交 | 需求对齐→概设→详设&拆解→执行→检查 | draft_ → ready_ → done/ |
| 验证方式 | 编译(退出码+3轮自修复) + 模拟器(截图+A/B/C诊断+视觉对齐) | 研发自检 Agent | CodeBuddy 记忆 + 人工评审 |
| 复杂度 | 高 (适合大型客户端) | 中 (适合云产品交付) | 低 (适合运营平台) |
| 上下文消耗 | 五步定位法 300x 压缩到 ~30K | Spec 文件夹 + Session Log 持久化 | SDD 文件, 每文件独立 |
| 跨会话传承 | TECH_SPEC.md §0-§9 + subtasks.json + timeline.txt | specs/ 文件夹 + App-Desc | AGENTS.md + anydev_rule.md |
取舍规律: 阶段越细, 控制越强, 但编排成本越高。企业微信追求 94% 生成率必须 8 阶段精细管控; Vibe Flowing 允许多人参与, 轻量约定更实用。关键不是阶段数量, 而是每阶段的退出标准是否可机器校验。
上下文压缩: 从 10M 到 30K
企业微信的五步定位法是目前公开最有效的上下文压缩方案:
| 步骤 | 方法 | 产出 |
|---|---|---|
| 意图消歧 | 硬关键词 + 设计稿归类 | 需求范围确认 |
| 模块定位 | 三级知识库金字塔(L1 overview/L2 wiki/L3 Figma→API 映射) | 目标模块 |
| rg 搜索 | 5 维搜索矩阵(事件方法/功能语义/OC 命名/协议代理/回调通知) | 代码位置候选 |
| 调用链追踪 | 构建调用链 | 影响范围 |
| 验证确认 | 编译/运行验证 | 定位确认 |
从 ~10M+ token 原始代码 → ~30K 精确上下文 (300x 压缩)。
四、经验闭环: 三个飞轮
| 维度 | AgentLoop 经验自进化 | e2e 2.0 统计&Loop 飞轮 | 企业微信 TECH_SPEC.md |
|---|---|---|---|
| 核心理念 | 从执行轨迹自动挖掘可复用经验 | 检查→发现问题→反哺优化 | 跨会话结构化传承 |
| 数据源 | 运行时 Trace | 4+1 检查维度 | 每次需求完成 |
| 沉淀形式 | 经验库(压缩到原始 4%-6%) | Harness 物料改进 | §0-§9 结构化文档 |
| 注入方式 | 运行时自动召回 | 全局反哺 | 新人/AI 5 分钟恢复现场 |
| 效果量化 | SWE-bench +7.2pp, Token -58% (部分场景) | 项目级持续改进 | — |
| 适用场景 | 高频重复任务 | 大型项目持续交付 | 任何需要恢复上下文 |
取舍规律: 闭环的核心是"从运行结果中学到东西"。AgentLoop 完全自动化但不区分价值高低; e2e 2.0 通过检查维度结构化扫描; 企业微信依赖人工编写 TECH_SPEC.md。自动化程度越高, 噪音过滤越重要。
AgentLoop Bench 数据
| Bench | 注入前 | 注入后 | Token 变化 |
|---|---|---|---|
| StarOps 指标查询 | 7.1% | 36.1% | -6.8% |
| OpenClaw/PawBench | 24.53% | 30.67% | -58.16% |
| SWE-bench Verified | 67.2% | 74.4% (+7.2pp) | 362M→536M |
反直觉: Token 不一定增加。低 Token 场景 + 精准经验注入, 可以减少模型试错消耗。
五、质量门禁: 五种设计
| 维度 | 企业微信 | e2e 2.0 自检 Agent | Vibe Flowing DB 管控 | 图工程验证器 | Harness 门禁 (TAB) |
|---|---|---|---|---|---|
| 时机 | 编译后 + 模拟器运行时 | 编码后, 独立会话 | DB 变更前 | 节点边缘 | 代码审查前 |
| 方式 | 退出码 + 截图 + A/B/C 诊断 | 多角色检查(产品/研发/安全) | flow-db-exec 统一入口 | 对抗式/多视角/评审团 | 7 道软硬门禁 + 基线对比 |
| 判定 | PASS/FAIL | PASS/CONDITIONAL/FAIL | 高危硬拦截/中危确认/低危执行 | 节点级别 | 逐级门禁 |
| 修复 | 3 轮自修复上限 | 独立视角不共享上下文 | — | 失败隔离不级联 | 基线对比反作弊 |
| 最优场景 | 客户端编译 | 大型项目多视角审查 | DB 安全 | 图架构中边缘把关 | CI/CD 准入 |
取舍规律: 门禁的位置决定效果。越早拦截成本越低, 但误报率越高。企业微信把验证放在编译后(拦截率高), e2e 2.0 用独立 Agent 做质检(视角独立)。最关键的发现: 门禁不是越多越好, 而是每个门禁都必须是可量化的机器判定。
六、拓扑选择: 从链到图
图工程 14 步提供了从线性到图的完整路径。各团队的实际拓扑:
| 团队 | 隐含拓扑 | 关键特征 |
|---|---|---|
| 企业微信 | 线性 8 阶段流水线 | 串行, 每步严格依赖上步产出 |
| e2e 2.0 | 正反向双链路 | 正向生产 + 反向改进, 类似菱形 |
| Vibe Flowing | 星型 + 约束 | 中央 Agent + 插件式 Skills |
| AgentLoop | 循环式 | 观测→挖掘→注入, 外挂飞轮 |
| TAB | 13 阶段接力赛 | 串行但集成测试前置到审查前 |
| 百度网盘 AICR | 并行审查 + 聚合 | 3 路并行→聚合→核实→复核 |
核心规律: 拓扑复杂度与团队规模正相关, 但收益有边界。企业微信 8 阶段严格串行已足够支撑 94% 生成率——说明对于确定性流水线, 图架构是过度设计。只有当并行/条件路由/失败隔离真实需要时, 才值得从链升级到图。
14 步路线图速览
| # | 步骤 | 一句话 |
|---|---|---|
| 1-2 | 节点与边 → 线性脚本是退化图 | 有数据流过才有边, 链条没有并行 |
| 3-4 | 节点契约 → 边即数据契约 | JSON schema 定边界, 数据命名边 |
| 5-7 | parallel 扇出 → 屏障扇入 → 菱形拓扑 | 并发 + 合并是主力模式 |
| 8-9 | 条件路由 → 验证器 | 节点 LLM 判断 + 边 JS 确定 |
| 10-12 | 失败隔离 → 循环收敛 → 模型分层 | 错误不级联, 去重收敛, 按需选模型 |
| 13-14 | 拓扑即成本 → 自路由 | pipeline 优于 parallel, Claude 自动编图 |
七、交叉模式归纳
模式一: 上下文压缩是所有团队的隐藏主线
| 团队 | 压缩手段 | 压缩比 |
|---|---|---|
| 企业微信 | 五步定位法 + 三级知识库 | 300x |
| Vibe Flowing | SDD 文件 + AGENTS.md 集中规则 + CLI 替代脚本 | 未知 |
| e2e 2.0 | Spec 文件夹结构化, 不重复传入 | 中等 |
| AgentLoop | Trace→Trajectory 压缩到 4%-6% | ~20x |
规律: 先压缩再注入, 而非先全部塞进去再等模型过滤。
模式二: 验证的独立视角
| 团队 | 独立视角设计 |
|---|---|
| e2e 2.0 | 自检 Agent 独立会话, 不与编码 Agent 共享上下文 |
| 企业微信 | 编译 + 模拟器双验证, 独立于编码 |
| 图工程 | 验证器在节点边缘, 不参与生成 |
| 百度网盘 AICR | 核实→复核双 Agent, 独立于审查 Agent |
规律: 自检与生产必须隔离上下文, 否则验证变成"自己检查自己", 置信度归零。
模式三: 人机协作的三种姿势
| 姿势 | 代表 | 人做什么 | Agent 做什么 |
|---|---|---|---|
| 工程师驱动 | 企业微信 | 红线维护 + TECH_SPEC.md 沉淀 | 8 阶段流水线执行 |
| 平台驱动 | Vibe Flowing | 能力地图 + 评论协作 | 3 分钟环境 + 预装 Skills |
| 飞轮驱动 | e2e 2.0 | Harness 物料迭代 | 正反向双链路全自动 |
规律: 自动化程度越高, 人的角色越从"演员"变为"导演和编剧"——定义流程、维护规则、审查边界, 而非逐行看代码。
八、Q3 应用建议
- Skill 治理优先: 当前知识库 Skill 是否有 500 行红线？参考腾讯云检查清单做一次质量扫描
- 上下文压缩落地: 定位类任务参考五步定位法, 确定标准压缩流程
- 验证独立视角: 自检类脚本/Agent 与生产 Agent 独立上下文, 不共享 session
- 闭环选型: 高频任务配 AgentLoop 式自动闭环, 低频任务配 TECH_SPEC.md 式结构化沉淀
- 拓扑克制: 线性能解决的问题不升级到图, 每次升级都有具体收益指标
