Harness 工程案例索引
本页从 [[wiki/concepts/上下文管理与 Harness Engineering]] 拆出，收录企业与团队的 Harness 工程实践案例与数据锚点；方法论与核心判断见母页。
知识沉淀式 Harness：基础设施之上
腾讯程序员团队的核心论点：Harness 工作流不是目的，知识沉淀才是真正的技术护城河。 他们设计了一套五层知识存储（个人偏好→团队约定→技术知识→业务知识→项目知识）× 五种知识类型（model/decision/guideline/pitfall/process）× 三级成熟度（draft→verified→proven）的知识分层架构，让每次需求交付都自动沉淀知识。独立 Git 仓库 + 三种团队角色 + 自动冲突解决 + 衰减机制（proven 条目 12 个月未引用降级）构成完整的知识生命周期管理。核心理念：Skill、Agent、工具链会随模型迭代更新，但领域知识是永恒的。 [[raw/2026-05-11/腾讯程序员/Harness不是目的，知识才是护城河 —— 一个AI工程交付团队的知识沉淀实践.md|来源: 腾讯程序员 - Harness 不是目的]]
延伸思考：这与 Karpathy 的 LLM Wiki Pattern 一脉相承——Ingest + Query + Lint 的循环，以及知识的复利效应。 [[raw/2026-05-11/腾讯程序员/Harness不是目的，知识才是护城河 —— 一个AI工程交付团队的知识沉淀实践.md|来源: 腾讯程序员 - Karpathy LLM Wiki]]
新的数据锚点（2026-05）
| 实践/实验 | 数据 | 来源 |
|---|---|---|
| LangChain 只改 Harness | TerminalBench 排名 30+ → 第 5 | [[raw/2026-05-12/Akshay/深度拆解：AI 智能体 Harness 的构造【译】.md|Akshay]] |
| LLM 自己优化 Harness | 76.4% 通过率，超过人类设计 | [[raw/2026-05-12/Akshay/深度拆解：AI 智能体 Harness 的构造【译】.md|Akshay]] |
| 10 步 99% 成功率 | 全流程仅 ~90.4%（错误滚雪球） | [[raw/2026-05-12/Akshay/深度拆解：AI 智能体 Harness 的构造【译】.md|Akshay]] |
| 验证循环 | 产出质量提升 2-3 倍 | [[raw/2026-05-12/Akshay/深度拆解：AI 智能体 Harness 的构造【译】.md|Akshay]] |
| 自我验证（写→跑→看→修） | 完成率比一次性生成高 40%-60% | [[raw/2026-05-14/李伟山/一文讲透如何构建Harness——六大组件全解析.md|李伟山]] |
| 搭 Harness vs 调 Prompt | 任务完成率 35% → 82%（两周 vs 三个月） | [[raw/2026-05-14/李伟山/一文讲透如何构建Harness——六大组件全解析.md|李伟山]] |
| 模型表现衰减 | 约 25.6 万 token 开始出现 | [[raw/2026-05-14/Datawhale/Harness Engineering在硅谷爆火，一文带你搞懂！.md|Datawhale]] |
| OpenAI 百万行代码 | 3 工程师 5 个月，零行手写 | [[raw/2026-05-14/Datawhale/Harness Engineering在硅谷爆火，一文带你搞懂！.md|Datawhale]] |
| 美团 AI 重构 | 31 万行代码渐进式重构，AI 定位 10 个隐藏性能隐患 | [[raw/2026-05-13/业务研发平台/用Agent评测思路管理AI Coding —— 31万行代码AI重构的实践.md|美团实践]] |
| Opus BrowseComp 准确率 | 43%（S4.5）→ 68%（O4.5）→ 84%（O4.6 加 Harness 改进） | [[raw/2026-05-12/宝玉/驾驭 Claude 的智能 - 构建应用的 3 个关键模式【译】.md|宝玉]] |
| F-Harness 三 Agent vs 单 Agent | 耗时 20min→6h（20x），成本 $9→$200（22x），质量从”逻辑残缺”到”生产环境级” | [[raw/2026-05-20/李伟山/从Prompt、Context到Harness，工程的三次进化与终局之战.md|李伟山 - F-Harness]] |
| QQ 音乐 Harness 体系 | 35 Commands + 34 Skills + 24 Agents，代码审查拆 8 维度并行 | [[raw/2026-05-21/黄欣欣/QQ音乐Harness Engineering实践.md|黄欣欣 - QQ音乐]] |
| 阿里云 AI 效能实践 | 前端人均代码量 3x，后端 2x；缺陷率前端降 30%，后端降 55% | [[raw/2026-05-22/阿里云开发者/代码一旦生产出来，首先是负债 —— 一个CIO 的AI效能实践复盘.md|阿里云开发者]] |
| Java 微服务 Harness 改造 | 单次迭代 5-10min→秒级，AI 自主修复 0 轮→3-5 轮收敛 | [[raw/2026-05-21/风业/都是 AI Coding，为什么 Java 体验差了一个量级？五条方法论帮你构建自己的 Harness 环境.md|风业 - Java Harness]] |
企业级基础设施进展
可观测性：LoongSuite GenAI 语义规范
阿里巴巴 & 蚂蚁在 OTel GenAI 基础上增强 Entry/Step Span、Skill 语义、Token 级推理观测。已支持 9+ GenAI 框架插桩。蚂蚁推理云 Token 级观测产品上线后，10 倍提速问题定界效率。[[raw/2026-05-12/铖朴、瑜棕、顺岭/阿里巴巴 & 蚂蚁 LoongSuite GenAI 可观测语义规范：从统一数据语言到规模化落地.md|来源: LoongSuite]]
通信底座：RocketMQ For AI
传统 MQ 在大模型场景的三个致命短板（不能区分消息优先级、不支持海量 Queue、会话队列头阻塞），通过 LiteTopic（百万级 Topic）+ Priority Message（1-10 级）解决。[[raw/2026-05-14/火山引擎存储/重构大模型通信架构：火山引擎 RocketMQ For AI 解决方案.md|来源: RocketMQ For AI]]
Java 生态：AgentScope 1.1.0
首个完整落地 “Harness Framework” 理念的 Java 框架。Workspace 作为唯一事实来源 + AbstractFilesystem 可插拔抽象层（本机/远端/沙箱三种模式）+ 双层记忆（每日流水账→后台合并精炼）+ 子 Agent 编排 + 内置对话压缩。[[raw/2026-05-15/刘军/首个 Java Harness Framework 来了｜AgentScope 把 OpenClaw 带到企业分布式场景.md|来源: AgentScope Java]]
定时调度：Agent 从工具到岗位
开源方案（OpenClaw/Hermes）在无高可用、运维成本高、权限管理弱、可观测弱、资源利用率低上有明显短板。阿里云 MSE AI 任务调度将定时调度从 Agent 内部抽离为统一平台。定时调度是 Agent 从”工具”升级为”岗位”的关键基础设施。[[raw/2026-05-13/千习、学仁/Agent从一问一答到自主执行面临哪些挑战？.md|来源: Agent 自主执行挑战]]
承吉：AgentTeams 多 Agent 编排平面
承吉的 AgentTeams（HiClaw）提供了一个与现有 wiki 中 Multi-Agent 编排模式完全不同的新范式：Agent orchestration 和 Agent runtime 应该是分离的两层。 AgentTeams 是 Kubernetes 类比于云原生的编排平面，不替代 Agent 运行时（OpenClaw/CoPaw），而是通过 CRD 协调它们。 [[raw/2026-06-17/承吉/工单闭环从半天到 6 分钟：我们把 AI Agent 编进了组织架构.md|来源: 承吉 AgentTeams]]
核心 CRD：Manager（平台）、Team（业务单元）、Worker（执行单元）、Human（真人）。组织架构即 CRD——TeamAdmin（真老板）→ TeamLeader（编排 Agent）→ Workers（执行 Agent）。Human 作为一等公民，与 Agent 共享同一 Matrix 通信房间，L1/L2/L3 权限直接映射到房间访问。
Credential convergence：AI Gateway（Higress）持有所有真实凭证，每个 Worker 获得 per-route 可撤销的 Consumer Token。
成果：15 Agents × 4 场景（产品开发、on-call 事件、开源 pipeline、商业智能），alert-to-resolution 从半天缩短到 6 分钟。
矛盾：Multi-agent coordination should be handled by a shared runtime (OpenClaw/CoPaw) — the wiki’s [[wiki/entities/OpenClaw 与多 Agent 编排]] treats the agent runtime as the coordination layer vs Agent orchestration and Agent runtime should be separate layers — AgentTeams is an orchestration plane that works ABOVE any runtime, analogous to how Kubernetes works above any container runtime 来自 [[raw/2026-06-17/承吉/工单闭环从半天到 6 分钟.md]]
爱奇艺前端/后端三层实践：从凭据到验证的完整链路
爱奇艺数据库团队将 Harness Engineering 落地为前端和后端各三层结构，核心理念：Agent 要可靠参与研发，不能只靠模型回答——项目需要给它准备任务入口、执行依据、工具边界、验证反馈和结果记录。 [[raw/2026-05-16/数据库团队/别让AI瞎猜了：用Harness Engineering 终结无限返工.md|来源: 爱奇艺 Harness 实践]]
前端三层
| 层次 | 典型载体 | 作用 |
|---|---|---|
| 执行依据层 | Pencil/设计结构文件/设计说明 | 固定页面目录、组件层级、变量映射、关键状态和交互边界 |
| 状态暴露层 | Storybook/Story 文件 | 展示 Default/Empty/Loading/Error/权限态/操作反馈态 |
| 交付实现层 | 真实页面、路由、接口接入 | 处理路由接入、权限逻辑、接口对接和页面联调 |
核心理念：“设计不要只冻结长相，还要冻结状态”。状态不要只存在于设计稿里，还要进入可运行环境（Storybook）。Agent 不应该凭一句描述生成页面，而应该在结构和状态都明确后补实现。这不是”生成速度更快”，而是”返工更少”——结构先冻结，状态先暴露，所有人围绕同一组对象协作。
后端三层
| 层次 | 常见载体 | 解决的问题 |
|---|---|---|
| 执行依据层 | docs/设计说明/接口说明/README/plan | 运行模式、输入输出、异常口径、非目标范围、回滚方式 |
| 状态暴露层 | 验证脚本/mock 环境/试运行结果/可复现命令 | 什么条件下算成功，什么条件下算失败 |
| 交付实现层 | 实现、测试、联调、收口 | 代码是否进入正式业务路径 |
后端”完成”的五层判断（从表到里）：
- 静态检查：代码结构、类型、lint、配置是否符合项目规则
- 单元验证：核心函数和边界条件是否正确
- 链路验证：入口、输入、处理、输出是否连通
- 失败验证：异常、超时、重试、回滚或停止策略是否符合预期
- 回写验证：结果是否同步到任务系统、PR/MR 或文档
Harness 与 Superpowers 的分工
爱奇艺团队将 Harness 与 Superpowers 技能体系做了明确职责切分：
- Harness：负责项目入口（AGENTS.md）、计划协议（
.agent/PLANS.md）、验证入口（runbook/scripts）、项目约束登记、结果回写位置 - Superpowers：负责写计划、TDD、系统化调试、代码评审、完成前验证
两者不应变成两套互相竞争的规则，而应按同一条链路配合：先读 Harness 项目依据 → 按技能化工作流完成实现与验证 → 把结果写回任务系统、PR/MR 或仓库文档。
“信息落点”矩阵
把临时上下文从聊天窗口移到稳定位置的四个象限：
| 信息位置 | 主要负责 |
|---|---|
| 任务系统（Linear/JIRA） | 目标、范围、状态、责任和反馈 |
| 仓库（repo） | 设计依据、计划、验证入口、项目约束和结果记录 |
| PR/MR | 代码变更、评审讨论、CI 结果、合并和留痕 |
| Agent 工具 | 搜索、修改、执行、验证和回写 |
关键不是把某个系统称为”唯一来源”，而是让每类信息都有清楚的位置，换工具时迁移成本才小。 [[raw/2026-05-16/数据库团队/别让AI瞎猜了：用Harness Engineering 终结无限返工.md|来源: 爱奇艺 Harness 实践]]
QQ 音乐 Harness Engineering 实践（五阶段+四道门禁）
黄欣欣团队将 Harness Engineering 落地为完整的工业化体系，核心理念：“不做补全、不做编辑器、不做模型网关，只补齐 L5 工程治理层。”
核心公式：代码产出 = AI 能力 × 上下文质量（乘法而非加法——上下文趋零时模型再强也无用）。这解释了为什么 Harness 投入的 ROI 远超模型升级。 [[raw/2026-05-21/黄欣欣/QQ音乐Harness Engineering实践.md|来源: 黄欣欣 - QQ音乐 Harness]]
五阶段主流程
| 阶段 | 动作 | 门禁 |
|---|---|---|
| 初始化 | 环境准备、上下文加载 | — |
| 需求定义 | 意图澄清、范围确认 | 门禁一：意图 |
| 设计 | 方案设计、接口契约 | 门禁二：方案 |
| 开发 | Dev 进入 + 服务仓库 | 门禁三：任务 / 门禁四：环境 |
| 交付 | 验收、合并、部署 | — |
四道门禁原则：“门禁要尽量少、尽量靠前”——分别对应意图、方案、任务、环境四个代价最低的纠错节点。
三层知识体系 + 三仓联动
三层知识：团队级（context/team/）→ 框架工程级 → 服务级（context/project/{module}/），逐层缩小实现 O(1) 命中。
三仓联动：Harness 仓（脑）+ 业务仓（手脚）+ IDL 契约仓（神经），同一条 TAPD 单三个仓用同名分支，保证一致性。
35 Commands + 34 Skills + 24 Agents 全部版本化管理，通过 scripts/install.sh 渲染到不同 CLI 本地目录。代码审查被拆成 8 个维度独立 Agent 并行执行——每个 Agent 只审一个维度，避免上下文过载。
Self-Refinement 闭环
AI 每次被纠正 → 识别是否为模式性教训 → 沉淀到对应知识层（团队/框架/服务）→ 下次新会话、新模型、新人也受益。这是一个将个体纠错经验转化为团队基础设施的正循环。 [[raw/2026-05-21/黄欣欣/QQ音乐Harness Engineering实践.md|来源: 黄欣欣 - QQ音乐 Harness]]
Harness 落地的五类问题及其解法
腾讯云开发者将 Harness 落地中的问题归为五类，每一类有明确的工程对策： [[raw/2026-05-22/腾讯云开发者/Harness落地的五大问题及其解法.md|来源: 腾讯云开发者 - 五大问题]]
| 问题类别 | 典型表现 | 解法 |
|---|---|---|
| 编码规范违反 | AI 生成代码不遵守团队约定 | Rule + Script（机械化检查+自动修复） |
| 操作流程遗漏 | AI 跳过了必须的工程步骤 | Skill 封装（标准化流程节点） |
| 流程交互混乱 | 多 Agent 间衔接出错 | SubAgent 定义（回退路由/细化流程/明确禁止项） |
| 外部能力缺失 | AI 无法访问必要的系统 | MCP 集成（标准化工具接入） |
| 系统性流程缺失 | 缺少必要的阶段或角色 | 加新阶段/新 Agent（结构性扩展） |
核心逻辑：护栏越多，AI 自主范围越大，人介入频率越低。 Harness 的本质是高度压缩的知识传递——十年经验不可能一次对话传给 AI，但拆成完善的 Rule/Skill/Script 就能秒级吸收。 [[raw/2026-05-22/腾讯云开发者/Harness落地的五大问题及其解法.md|来源: 腾讯云开发者 - 五大问题]]
“代码首先是负债”：AI 效能实践中的四个左移
阿里云某 CIO 的实践复盘提出了一个反直觉但被数据验证的判断：代码一旦生产出来，首先是负债（维护成本+复杂度），能否变成资产取决于是否产生业务价值。这重新定义了 AI Coding 的目标——不是”多写代码”，而是”用更少代码创造更多价值”。 [[raw/2026-05-22/阿里云开发者/代码一旦生产出来，首先是负债 —— 一个CIO 的AI效能实践复盘.md|来源: 阿里云开发者 - 代码负债]]
成果数据：
- 前端人均有效代码量提升 3 倍，后端 2 倍
- 千行代码缺陷率：前端降 30%，后端降 55%
AI 破解了两道经典软件工程难题：
- 人月神话：加 Agent 无沟通损耗——每个 Agent 独立上下文、独立执行、不互相等待
- 工程左移：AI 大幅降低左移的成本/ROI 门槛，使原本”太贵”的质量实践变得可行
四大左移实践：
| 实践 | 传统痛点 | AI 解法 |
|---|---|---|
| 质量与测试 | 覆盖率不够（往往只有 20%） | 覆盖率 20%→100%，自动生成+维护 |
| 知识工程+Spec | 存量系统无文档无 Spec | AI 反向还原 Spec，形成可维护的知识资产 |
| API First | 前端等后端，职责代偿 | API 契约先行，前后端并行开发 |
| Vibe Coding 左移 | 需求到代码中间缺少验证 | 需求澄清前置为 Live Demo，快速试错 |
核心理念：“定义清楚一个问题，问题可能就解决了 95%“，且这个权重正随着 AI 能力提升而逼近 99%。
Agent 囤积症警示：Skill 封装门槛下降 = 封装垃圾也更容易。价值不在”包装能力”，而在数据是否 Ready、工具是否成熟。Agent/Skill 的数量不是 KPI，有效产出才是。 [[raw/2026-05-22/阿里云开发者/代码一旦生产出来，首先是负债 —— 一个CIO 的AI效能实践复盘.md|来源: 阿里云开发者 - 代码负债]]
Java 微服务的 Harness 改造：AI Coding 体验差的根因与解法
风业指出了 Java 生态 AI Coding 体验差的系统根因：微服务架构”天然不 AI 友好”——云端基础设施依赖（数据库、消息队列、注册中心）导致本地验证闭环断裂。AI Agent 无法独立跑通测试，每次修改都需要人工介入验证。 [[raw/2026-05-21/风业/都是 AI Coding，为什么 Java 体验差了一个量级？五条方法论帮你构建自己的 Harness 环境.md|来源: 风业 - Java Harness]]
三条改造原则
| 原则 | 做法 | 效果 |
|---|---|---|
| 依赖倒置接口先行 | 定义 StorageAdapter 接口 + OSS 实现 + 本地文件实现 | AI 可在两种实现间无感切换 |
| 零侵入 Profile 隔离 | @Profile("local") 标记本地替代实现 | 不改业务代码，不影响生产部署 |
| 工具 AI 化 CLI 优先 | 所有操作脚本化（启动/验证/数据灌入） | GUI 对 AI 不可见，CLI 可直接调用 |
改造效果
- 单次迭代周期：5-10 分钟 → 秒级
- AI 自主修复轮次：0 轮（完全依赖人）→ 3-5 轮收敛
Harness Engineering Checklist（五维度）
| 维度 | 检查要点 |
|---|---|
| 可运行性 | AI 能独立启动和运行项目吗？ |
| 可测试性 | AI 能独立运行测试并看到结果吗？ |
| 可观测性 | AI 能看到日志、指标、错误信息吗？ |
| 工具 AI 化 | 所有人工操作都有对应的 CLI 脚本吗？ |
| 隔离性 | 不同服务/模块的验证环境相互独立吗？ |
核心公式：AI Agent 的能力边界 = 它能调用的工具的边界。不是模型不够聪明，是工具不够多、不够好、不够快。五条可复用方法论：最小可运行子集、替代而非模拟、脚本化一切人工操作、分层隔离逐层验证、让 AI 成为改造参与者（让 AI 自己写改造代码，人只做审查）。 [[raw/2026-05-21/风业/都是 AI Coding，为什么 Java 体验差了一个量级？五条方法论帮你构建自己的 Harness 环境.md|来源: 风业 - Java Harness]]
企业级 Harness 新案例群（2026-05 新增）
阿里云自主增长系统（OPC + Harness）
多 Agent 架构：orchestrator 总控 + 专业 Agent（product/design/arch/testcase/builder）+ 独立 Evaluator。三个核心工程问题及其解法：
- 长任务可靠性：状态机 + 心跳 + 超时恢复 + 失败处理
- 上下文污染：Planner/Builder 拆分为专业 Agent、每轮新 SubAgent
- 评估独立性：Evaluator 生成分离、零信任原则、三层评审（代码质量→静态质量→动态运行）
- Benchmark 评估体系：impl-reviewer 的评分标准建设（两层：code snippets + project 级）
[[raw/2026-05-25/让 AI 自己做增长：基于OPC和Harness思想的自主增长系统探索.md|来源: 阿里云自主增长]]
DIPG：C 端 AIGC 的 Harness 落地（蚂蚁保）
“离线生成 + verify 闭环”取代”实时生成直出”。三层 LangGraph 嵌套：Host Agent（编排+精准修正）→ Research Agent（纯生成）→ Verify Agent（只校验不改，程序化+LLM 双层 check）。Host Agent 精准编辑而非重新生成——这是降本的关键。
“强制前置溯源”的 Prompt 设计技巧：利用模型自回归特性，在生成关键数据前先写 HTML 注释说明来源。结构强制比语义强制有效。
[[raw/2026-05-26/Harness Engineering- C 端 AIGC 内容生产自优化实践.md|来源: 蚂蚁保 DIPG]]
淘天数字 SRE：AI 主导代码质量修复
100+ 应用、60%+ 自动修复率、节省 80% 人力成本。核心选择：技术选型反直觉地选了”UI 浏览器自动化”——因为环境碎片化使 CI 集成/静态扫描的工程化路径不可行。“中间态日志”机制记录每个修复的原始描述+修复思路+代码对比，既作审计线索又跨步骤上下文传递。
[[raw/2026-05-27/从人机协作到AI主导：我们是怎么把代码质量交给”数字SRE”的？.md|来源: 淘天数字SRE]]
得物 Highway & ATV 混合架构
80% Flow Engineering（意图→故事→动作）+ 20% OpenClaw Autonomous Agent 组合。7 阶段护栏：PRD→技术方案→需求开发→验证→联调→上线→效果跟进。半双工对话逻辑设计（智能客服）。
[[raw/2026-05-29/得物技术在 AICon 关于大模型与 Agent 技术实践分享来袭！.md|来源: 得物 AICon]]
Railway：AI Infra 视角
35 人团队服务 300 万用户。“软件生成速度提升一千倍后，基础设施里的每个小浪费都会被放大”——因此不用 Kubernetes，必须对工作负载精细控制。平台需要”环境快照”让 agent 复制整个工作现场。
[[raw/2026-05-23/Railway创始人：35 人团队如何服务300万用户丨Latent Space.md|来源: Railway]]
叶小钗：AI 原生组织三层次模型（2026-06 新增）
叶小钗（前腾讯技术总监）用三年实践的 CIO 数字分身失败案例，揭示了 AI 原生组织建设的核心难点不在于技术，而在于管理：
AI 原生不是 AI 课题，是管理课题。三年实践（CEO 数字分身创业失败）暴露的核心问题：没有业务主线、没有数据标准、权限模糊、指令落不下去——这些不是 AI 技术能解决的，需要”沟通、对齐、对齐再对齐”。[[raw/2026-06-01/叶小钗/AI 原生不是技术升级，而是组织重构：高大上的背后，全是脏乱差.md|来源: 叶小钗 AI原生案例]]
L1→L2→L3 层级模型：
- L1 工具辅助层：AI 进入个人工作流程，效率提升但组织不变
- L2 流程嵌入层：AI 进入岗位动作和部门流程，组织开始围绕 AI 重构
- L3 规则主导层：AI 结果直接影响分配、晋升、奖惩——评价权最终归属 AI
从 L1→L2 的难点不是技术是管理；从 L2→L3 的难点不是信不信任而是愿不愿意——“老板首先不需要公平，需要可控。” [[raw/2026-06-01/叶小钗/AI 原生不是技术升级，而是组织重构：高大上的背后，全是脏乱差.md|来源: 叶小钗 三层次]]
AI 销售线索分配案例（核心技术洞察）：技术上完美运行（将原来 5 人线索分配团队干到 1 人），但半年后系统被老板叫停——因为系统太公平，让老板不满意的团队也能持续拿奖金。管理意志与 AI 意志相左时，AI 会输。 这指向 AI 原生的终极命题：不是能不能做好，而是组织愿不愿意被 AI 治理。[[raw/2026-06-01/叶小钗/AI 原生不是技术升级，而是组织重构：高大上的背后，全是脏乱差.md|来源: 叶小钗 线索分配]]
风夏：WebTerminal CLI 的 Agent 分层实践（2026-06 新增）
风夏（阿里云）的 StarAgent WebTerminal 改造实践，提供了一份三层分工的工程参考：WebTerminal 页面（登录/角色/审计/官方连接）→ wt CLI（会话复用/命令发送/输出捕获/文件 API/交互控制面，不内置具体排障 suite）→ Skill（描述操作方法/风险边界/推荐命令模板）→ Agent（动态规划/执行/观察/复盘）。CLI 提供稳定手脚，Skill 提供行动章法，Agent 负责临场判断。 [[raw/2026-06-01/风夏/全是 Web 没 CLI 怎么行：一次把 StarAgent WebTerminal 改造成.md|来源: 风夏 三层分工]]
这个实践的核心洞察与 [[Skills、Agents 与工具设计#MCP/CLI/Skills：三层分工框架嵌入]] 完全一致——CLI 不是备选而是第一选择，因为只有 CLI 能做到”参数清楚、行为稳定、输出可解析、错误可复现、证据能落盘”。[[raw/2026-06-01/风夏/全是 Web 没 CLI 怎么行：一次把 StarAgent WebTerminal 改造成.md|来源: 风夏 CLI 优先]]
franslee：Harness Engineering 双向改造实践（2026-06 新增）
franslee（腾讯 PCG 大数据平台部 Dola 数据分析助手）提出了 Harness Engineering 的双向应用——对外服务好 AI 产品，对内服务好 AI Coding。 [[raw/2026-06-12/franslee/Harness Engineering落地前，先想清楚这几个问题.md|来源: franslee Harness 双改造]]
对外：服务好 AI 产品
图表推荐三维评分引擎：传统图表推荐库（AntV/AVA）完全基于数据特征推荐，在 AI 对话数据分析场景下不够用——同样的 GMV 数据，用户问”各渠道趋势”和”哪个渠道下降最明显”期望完全不同的图。Dola 的解法是利用 AI 链路独有优势——前端能拿到 SQL + 用户原始 prompt（传统 BI 拿不到）。GROUP BY/ORDER BY 藏着维度度量，用户 prompt 藏着分析目标。三维评分（数据特征 + SQL 特征 + Prompt 特征）将复杂多维场景推荐准确率从 55% 提升到近 90%。
LLM 流式对话代码展示攻坚：核心问题是主流代码高亮库（highlight.js/Prism/Shiki）为”已写好代码”设计，每 chunk 到达触发完整 DOM 重写，导致流式选区丢失、长会话 DOM 爆炸（33612 个 DOM 元素、180MB 内存）。Dola 3.0 双模渲染方案：DOM 模式用 CSS Custom Highlight API（代码以单个 textNode 存在，着色通过 Range + ::highlight() 伪元素，不创建 <span>），Canvas 模式兜底超大代码。实测 20 轮对话 DOM 节点从 15000 降到 500，长任务从 12 次降到 1 次，内存从 180MB 降到 55MB。
对内：服务好 AI Coding（Harness 改造存量项目）
存量项目 AI Coding 问题的根因不在模型，而在于项目本身缺少机器可读、可被 AI 稳定遵循的工程约束。AI 看到的是历史代码参差不齐的事实，只能取一个”平均值”。
改造四步法：
- 规则进入代码仓库：建立
openspec/rules/真相源，用.mdc文件沉淀编码铁律/样式规范/反模式清单，通过 postinstall 和 Git Hooks 自动分发到.cursor/rules/、.codebuddy/rules/——规则只在一处维护，全员全工具零漂移 - 代码出口收敛：UI 组件统一收口到
src/components/ui/，用 ESLintno-restricted-imports杜绝绕过封装层直接引 antd——“只有一条正确路径”环境下 AI 准确率显著提升 - Design Token 抽离：颜色/间距/字号以 TS 为真相源，脚本生成 less/CSS/antd 三端共享，AI 不再猜
#1677ff还是#1890ff - 编程范式重审：AI Coding 时代旧审美（短小=优雅、抽象=高级、少写=高效）的成本结构反转——真正稀缺的是代码是否容易理解、搜索、定位、review 和局部修改。新标准：显式优于隐式、可搜索优于可推导、直白优于炫技、适度重复优于过度抽象
腾讯程序员：Harness Eval——用「考试」撕掉工作流遮羞布（2026-06-18 新增）
腾讯技术团队构建了 Harness Eval——一个轻量级、可回归的闭环评测系统。核心第一性原理：「无法量化的东西就无法优化。」Harness 工作流是「规则驱动的概率程序」，其输出是非确定性的，不能用传统布尔测试评估，而要当「考试」（多维度打分+证据+改进建议）。 [[raw/2026-06-18/腾讯程序员/你的 Harness 工作流真的在进步吗？我们用一场考试撕掉了遮羞布.md|来源: 腾讯 Harness Eval]]
三条不可违背原则：① 可复现 > 精确（统计显著性优于单次跑分）；② 可归因 > 高分（每次失败必须解释为什么——工作流缺陷？问题模糊？模型能力极限？）；③ 闭环 > 单向（评测终点不是成绩单，而是下一轮迭代的驱动力）。
三角色流水线：出题官（LLM 扮演用户）→ 被测 Agent → 评判官（完全独立进程）。出题官按剧本与 Agent 多轮对话（用户不会只发一条就走），评判官完全隔离——独立进程、不共享上下文、只看 rubric.md + 压缩的 transcript。关键教训：早期设计让出题官兼评判，误判率很高，因为出题官只看对话文本看不到工具调用。
量化结果：经过 4 轮 workflow_rev 迭代和 50+ 次自动化运行，通过率从 82.4%（14/17）提升至 100%（17/17）。多个关键问题的 overall 分从 1-2 提升到 5。执行引擎用 Go 写、单 CLI 二进制、零外部依赖、用 git worktree 做沙箱隔离。 [[raw/2026-06-18/腾讯程序员/你的 Harness 工作流真的在进步吗？我们用一场考试撕掉了遮羞布.md|来源: 腾讯 Harness Eval 三角色]]
「薛定谔的退化」：没有评测系统，你永远不知道工作流什么时候变差了。
澄沨：淘宝主播 Agent 的 Harness 工程实战（2026-06-17 新增）
目前最全面的生产级 Harness 工程案例。淘宝主播 Agent 在极端条件下运行（真金白银的公开操作、主播注意力稀缺、高频多主题交织、数小时可中断会话）。论文将 Harness 形式化为六元组 H = (E, T, C, S, L, V)：执行循环、工具注册表、上下文管理器、状态存储、生命周期钩子、评测接口。设计哲学：「业务写 Skills；框架处理所有安全、状态、上下文和可观测性的脏活。」 [[raw/2026-06-17/澄沨/更可靠的主播助理：淘宝主播Agent的Harness工程实战.md|来源: 澄沨 淘宝主播 Harness]]
三层物理存储架构：Session 数据→MySQL（强一致、高频读写）；Memory→Hologres（向量+全文+标量混合检索）；Skills→GitLab（版本控制、代码审查、灰度发布）。「逻辑统一，物理分离」——Agent 看到一个统一工作区，框架处理三个异构后端。
Context Engineering 的 Reducer 模式：LLM 只产生 Actions；Reducer 函数（纯函数、确定性）处理状态变更。每轮通过 system-hint 注入状态快照，替代膨胀的聊天历史。被称为全文最重要的设计。
幂等设计：所有写操作基于 UUID 的幂等键 + 框架级去重缓存，防止「双切产品」「双改价」灾难。结构化错误码：3xxx（业务异常→换策略重试）、4xxx（参数异常→自动修正+重试一次）、5xxx（系统异常→最多 3 次指数退避）、9xxx（不可恢复→通过 Hook 通知主播）。
PlanEngine（DAG）：从 ReAct 单步升级到 DAG 全局规划+三层 Checkpoint。结果：执行成功率 0.847 vs ReAct 0.737；子任务覆盖 0.976 vs 0.883；工具执行冗余 0.587 vs 0.727；迭代轮数 5.44 vs 8.02（基座 qwen3.7-max）。
信任分系统：量化信任来自 Decision Trace Log。事件：采纳+好结果（+0.05）、采纳+坏结果（-0.10，非对称惩罚）、拒绝+Agent 对了（+0.03）、拒绝+主播对了（-0.05）。信任等级驱动输出形式：≥0.7 给建议、0.4-0.7 给证据+弱参考、<0.4 只给纯数据。 [[raw/2026-06-17/澄沨/更可靠的主播助理：淘宝主播Agent的Harness工程实战.md|来源: 澄沨 信任分非对称惩罚]]
爱奇艺：Agentic Quality Engineering 质量门禁左移（2026-06-18 新增）
爱奇艺提出 AI 时代质量门禁必须左移——从提交后移到开发活动本身内部。AI 的角色从「Copilot」演变为「Quality Orchestrator」：通过 Harness 管理上下文、通过 Agent 分解任务、通过 Subagents 运行专项验证、通过 Skills 调用工具、向规则化门禁引擎交付证据做可审计决策。 [[raw/2026-06-18/移动产品研发团队/AI 时代的质量门禁左移：Agentic Quality Engineering 架构与落地模板.md|来源: 爱奇艺 Agentic QE]]
三大范式转变：① 从人工经验到显式契约（写 AI 可执行的结构）；② 从结论驱动到证据驱动（每次 pass/fail/block 必须有截图、日志、网络 trace）；③ 从单点工具到系统能力（自动执行、环境准备、报告治理、复查入口一条管道）。
架构清晰边界：AI Agent（任务分解/风险识别/工具调用/证据解读，但不替代门禁决策规则）→ Execution Runtime（真实环境操作）→ Evidence Bus（过程数据统一收集）→ Gate Engine（证据映射到 PASS/FAIL/BLOCK，可追溯报告）。
三级风险门禁：L1 低风险快门禁（文案、非核心样式）；L2 标准门禁（用户可见变更）；L3 强门禁（核心路径或 AI 生成的大 diff：支付、登录、内容发布）。
核心判断：「AI 工程竞争力将转向验证系统。」工程组织之间的差距不再是「谁生成代码更快」，而是「谁的验证系统更强来吸收这些变更」。
OpenSquilla：MetaSkill 与可验证交付（2026-07 新增）
OpenSquilla 的案例把 Harness 的两个落点讲得很具体：一是 coding task 要求 Agent 写完代码后必须通过测试再停止，避免”写完就算完”；二是 MetaSkill 把多个普通 Skills 串成论文写作等多阶段工作流，按阶段拉起不同子代理、最后再由修订代理统一收尾。它的价值不在于又多了一个 Agent 框架，而在于把”任务执行成功率、Skill 组织方式、成本路由和稳定流程”做成显式机制。[[raw/2026-07-03/Bubble/分享一个让我大受启发的开源Agent项目，老板听完拍手叫好。.md|来源: OpenSquilla]]
这与上文爱奇艺质量门禁、QQ 音乐 Harness、WorkBuddy 专家团形成同一条线：复杂任务不是靠一个更聪明的模型硬扛，而是靠任务类型识别、阶段化 Skill 编排、验证门禁和成本控制共同降低不确定性。[[raw/2026-07-03/Bubble/分享一个让我大受启发的开源Agent项目，老板听完拍手叫好。.md|来源: OpenSquilla]]
腾讯程序员：知识库工程 × 端到端开发工程（2026-07 新增）
腾讯程序员的端到端 Harness 实践把问题定义得很清楚：AI Coding 在真实工程现场会被单窗口上下文膨胀、业务知识不足、自动化闭环缺失和无法并行四件事卡住。解决思路不是单点提示词优化，而是把 Knowledge Engineering 和 端到端开发工程 绑在一起：先让 AI 真正获得业务知识，再围绕需求、开发、验证、交付设计可运行的工程闭环。[[raw/2026-07-03/腾讯程序员/从AI Coding到Harness Engineering的端到端工程开发实践.md|来源: 腾讯 Harness]]
这条案例对本页最重要的补充是：Harness 不是”给 Agent 加几条规则”，而是把知识库、任务拆解、工具调用、验证证据、并行执行和交付链路一起工程化。它和本库自身的 raw/wiki/outputs 分层形成互证：知识库不是背景材料，而是 Harness 能否持续工作的基础设施。[[raw/2026-07-03/腾讯程序员/从AI Coding到Harness Engineering的端到端工程开发实践.md|来源: 腾讯 Harness]]
相关页面
- [[wiki/concepts/上下文管理与 Harness Engineering]]
- [[wiki/concepts/Harness 架构演进与前沿]]
- [[wiki/concepts/Harness 机制与配置工程]]