最近半年Harness Engineering 无疑是 AI 工程领域最火的概念。从 OpenAI 的 Codex 到 Anthropic 的 Claude Code各大厂都在展示如何用工作流和约束引导 AI 模型输出高质量结果。但当业界还在争论 该用多大的模型 和 该搭多复杂的工作流 时腾讯内部一个 AI 工程交付团队AI Team基于CodeBuddy 做内部 AI 工程化落地的实践报告《Harness 不是目的知识才是护城河》却让我眼前一亮他们提出了一个被严重低估的观点工作流只是管道知识才是流过管道的活水。一、Harness Engineering 的本质我们可能都理解错了重点先简单回顾一下 Harness Engineering 的核心概念。这个术语源自 马具 的隐喻 —— 就像骑师通过缰绳和马鞍引导马的力量而非增强马本身的体能Harness Engineering 强调的是引导和约束 AI 模型的能力而非提升模型本身。业界三大标志性实践实践方核心关注关键动作OpenAI — Codex人机交互协议零手写代码通过精确指令驾驭 AgentCursor — Self-Driving多 Agent 协同背景 Agent 自动检测冲突并运行测试Anthropic — Claude Code长时运行稳定性多层记忆系统 CLAUDE.md 约束这些实践确实令人兴奋但腾讯 AI Team 在深度实践中发现了一个更本质的问题大家都在讨论高速公路该修几车道、立交桥该怎么设计却忘了问路上跑的车知识从哪来到哪去怎么维护二、核心论点为什么知识沉淀比工作流更重要腾讯 AI Team 在实践中总结出三个关键认知彻底改变了他们对 Harness Engineering 的理解1. 工作流是 可替换的知识是 可累积的今天用 16 阶段状态机编排工作流明天可能用图结构 DAG 编排Agent 调度模式从串行到并行到分层级联变化很快。但团队积累的知识 —— 比如 广告预算扣减在高并发下会超扣需用 RedisLua 保证原子性—— 这条知识不管工作流怎么变都是有价值的。2. 没有知识沉淀的工作流是 一次性 的很多团队搭了复杂的 Agent 工作流每次需求都跑一遍全流程但每次都是从零开始。上一次踩过的坑下一次照踩不误上一次做过的架构决策下一次重新推导一遍。这就是没有知识闭环的工作流 —— 投入了工程成本搭建工具链却没有让工具链变得越来越聪明。3. 知识是团队的 复利资产知识分为三类散点型知识孤立事实、因果型知识A 导致 B 的推理链、时空型知识特定场景下成立的经验。越是高阶的知识越难以从模型中获得越依赖团队实践积累。当知识库有成百上千条 proven经过多项目验证的知识条目时新来的成员、新启动的项目都能 站在前人肩上这就是知识的复利效应。三、三维正交知识架构让知识有 家 可归腾讯 AI Team 设计了一套五层存储 × 五种类型 × 三级成熟度的三维正交知识体系解决了知识管理的核心难题。1. 五层存储架构划分知识的共享边界层级名称存储位置共享范围核心作用Layer 0-P个人偏好~/.ai-team/纯本地不共享保存个人开发习惯、代码风格等Layer 0-T团队约定team-conventions/团队级Git 共享代码规范、Commit 规范、Review 标准Layer 1技术知识tech-wiki/团队级跨项目跨项目通用技术经验如 Spring Boot 多租户设计Layer 2业务知识biz-wiki/{domain}/团队级按领域特定业务领域的领域模型、规则、流程Layer 3项目知识docs/knowledge/项目级随项目走仅当前项目有意义的上下文如数据库版本最关键的设计是知识可以 向上提升Layer 3 的项目知识如果被判定为跨项目通用会自动提升到 Layer 1 或 Layer 2实现知识的持续进化。2. 五种知识类型MECE 分类覆盖全场景他们将知识按 描述的是什么 分为五类遵循 MECE互斥且完全穷尽原则类型定义示例model实体定义、数据结构、关系图广告计划包含预算 / 出价 / 投放时段三个核心字段decision技术选型、架构决策及理由选择事件驱动而非 RPC 同步因为广告状态变更需要解耦guideline推荐做法或禁止做法公共模块变更后的兼容性检查清单pitfall已知风险、故障模式、排查步骤广告预算扣减在高并发下会超扣process业务流程、状态机、操作步骤广告审核提交→机审→人审→上线3. 三级成熟度 自动衰减让知识 活 起来知识不是 写完就完了它有生命周期draft新提取单一来源 ↓ 在1个工作流中被成功引用 verified单项目验证 ↓ 在≥2个不同项目中被验证 proven成熟/可信赖更关键的是自动衰减机制—— 知识如果长期不被引用会自动降级proven 条目 12 个月未被引用 → 降级为 verifiedverified 条目 6 个月未被引用 → 降级为 draftdraft 条目持续未引用 Lint 标记 → 归档移出活跃索引这个设计腾讯 AI Team借鉴了 Karpathy 在 LLM Wiki 概念中提出的 Lint 操作确保知识库始终保持健康和时效性。四、团队知识库从 个人经验 到 团队资产 的转变1. 独立 Git 仓库知识的 单一事实来源腾讯 AI Team 做了一个关键决策团队知识库是一个独立的 Git 仓库不寄生于任何业务项目。team-knowledge.git ← 独立Git仓库 ├── knowledge-catalog.md ← 全景目录Agent查询入口 ├── .knowledge-config.yaml ← 团队配置成员、冲突策略 ├── team-conventions/ ← Layer 0-T: 团队约定 ├── tech-wiki/ ← Layer 1: 技术知识 ├── biz-wiki/ ← Layer 2: 业务知识 ├── project-profiles/ ← 项目画像 └── contributions/ ← 贡献暂存区为什么要独立仓库跨项目共享同一个团队的多个项目连接同一个知识仓库项目 A 沉淀的知识项目 B 自动受益生命周期独立业务项目可能归档或重构但知识不应该跟着项目消失权限独立知识库的贡献和消费权限可以独立于代码仓库管理2. 三种团队角色权责清晰的协作模式角色权限适用人群maintainer裁决内容冲突、审批 proven 提升、管理成员团队负责人、资深工程师contributor通过工作流自动贡献创建 / 验证 / 标记矛盾正式团队成员reader只消费知识查询 / 注入不贡献新成员试用期3. 贡献模式贡献暂存 异步合并他们借鉴了区块链的三个核心思想用 Git 作为实现载体区块链思想AI Team 实现机制不可篡改的追加日志log.md 只追加不修改每条变更记录贡献者、时间、会话哈希贡献可溯源evidence.contributors[]类似 Git blame粒度为知识条目级共识机制maturity 多人验证提升draft→verified:1 人验证verified→proven:≥2 人 ≥2 项目这种设计让大多数情况纯新增、证据追加、成熟度提升可以自动处理只有真正的内容矛盾才需要人工介入大幅降低知识共建的摩擦成本。五、工作流如何服务于知识沉淀从 为了编排而编排 到 为了知识而编排在腾讯 AI Team 的系统中16 阶段状态机的每一个阶段都与知识的流动紧密关联形成了知识的完整生命周期闭环INIT知识注入→ 各阶段执行知识消费→ ARCHIVE知识提取1. 三个关键时刻的知识流动INIT 阶段知识注入工作流启动时自动 git pull 团队知识仓库将知识全景目录注入 Agent 的查询入口。新启动的工作流自动站在前人肩上。各阶段执行中知识消费Agent 在决策点按需查询知识库。每个阶段的 Agent 有独立的查询预算聚焦不同类型的知识避免上下文膨胀阶段查询焦点重点知识类型ANALYSE_PRODUCT业务知识 (Layer 2) 历史需求model, process, pitfallANALYSE_TECH技术知识 (Layer 1) 归档索引decision, guideline(avoid), pitfallARCHITECT架构模式 实体关系decision, modelIMPLEMENT编码实践 团队约定guideline, pitfallBUILD_VERIFY反模式库pitfall, guideline(avoid)ARCHIVE 阶段知识提取工作流完成后自动从全流程产物中提取知识条目 —— 架构决策变成 decision踩过的坑变成 pitfall总结的经验变成 guideline。提取后执行提升判定符合条件的自动提升到 Layer 1 或 Layer 2。2. 冷启动导入历史项目的知识唤醒对于已有大量代码但没有知识库的历史项目他们提供了 /flow-import 命令通过 3 个 Agent 的管道实现冷启动doc-collector → 多源资料收集Git/TAPD/iwiki/ 本地文档 / 口述codebase-profiler → 代码画像技术栈 / 模块 / 依赖 / 模式knowledge-builder → 知识标准化4 维基线 ≤13 条知识条目 归档总结六、知识的按需消费解决上下文膨胀的核心方案传统做法是在 Agent 启动时把一堆知识 推送 给它导致信息过载和不精准。腾讯 AI Team 的设计理念是Agent 不被动接收固定数量的知识推荐而是通过三级渐进式索引主动按需查阅。三级渐进式索引效率提升一个数量级层级文件大小作用Layer A: 全景目录knowledge-catalog.md~50 行知识库有什么—— 分类统计 按阶段推荐查阅路径Layer B: 分类清单各目录下的 catalog.md~100-300 行这个分类有哪些条目—— 每条一行摘要ID 标题 成熟度 标签Layer C: 完整条目TK-.md / BK-.md~50-200 行这条知识说了什么—— 完整内容 背景 适用场景渐进查询流程读全景目录~50 行零成本→ 了解知识库全貌读分类清单~100-300 行低成本→ 过滤相关条目读完整条目按需每条 50-200 行→ 获取完整内容读原始产物深入可选→ 追溯原始推导过程这种方式让 Agent 可以用极低的成本了解知识库全貌只在真正需要时才读取完整内容上下文效率提升了一个数量级。七、突破人机交互瓶颈让工作流 7×24 小时流转在实际落地中腾讯 AI Team 发现了一个被普遍忽视的工程现实 ——工作流的流转依赖于人的在场。如果 Agent 在执行过程中需要人工确认而你恰好在开会、通勤或吃饭工作流就卡住了。解法远程操控 跨设备接管他们引入了 Hapi 内网版来解决这个问题核心能力是在办公网下用手机远程接管运行在开发机上的 AI 编程会话。这意味着站会时可以用手机扫一眼 Agent 进展评审会间隙可以用手机确认 Agent 架构方案午饭后可以用手机 review Agent 产物通勤路上可以用手机启动新工作流在家可以用浏览器远程操控开发机这种能力不仅解决了 人机交互 的效率问题更重要的是保障了知识沉淀闭环的完整性 —— 工作流可以更紧凑地走完全流程从 INIT 的知识注入到各阶段的知识消费和决策确认到 ARCHIVE 的知识提取和自动提升大幅缩短交付周期加速知识沉淀闭环的流转。八、我的思考腾讯 AI Team 实践对行业的启示1. 知识工程应该成为 Harness 的核心而非附属品Harness Engineering 的三支柱上下文工程、架构约束、持续治理中知识管理本身就是核心能力。腾讯 AI Team 的实践让我们看到知识检索注入、长短期记忆、知识生命周期管理应该是 Harness 系统的标配而非可有可无的功能。2. 模型能力提升不能替代领域知识沉淀业界存在一场争论该投入更多在 更大更强的模型 上还是 更复杂的 Harness 上腾讯 AI Team 的立场很务实这不是非此即彼的选择而是要找到适合团队的平衡点。模型能力提升是大势所趋投在知识工程上的架构应该对模型能力的提升保持开放但模型能力提升不能替代领域知识。再强的模型也不知道你的业务系统里有哪些隐藏的坑知识工程的投入是确定性回报每沉淀一条 proven 知识所有后续工作流都受益。而模型能力提升的回报是概率性的3. 文件即状态机 是 AI 工程的最佳实践之一AI Team 的设计哲学中有一条看似朴素但非常重要的原则文件系统即状态机。所有的状态、产物、知识都以文件形式存在没有数据库、没有独立平台。这不是技术妥协而是刻意选择可见性所有知识都是 Markdown 文件人可以直接阅读、编辑、审查可版本化Git 管理的文件天然有版本历史可迁移性不依赖任何特定平台或服务换工具链时知识不会丢失IDE 原生.codebuddy/ 目录驱动被 IDE 原生识别零配置成本九、总结Harness 的终极目标是知识沉淀而非工作流本身腾讯 AI Team 的实践给我们上了重要一课当 Harness 热潮褪去真正能让团队保持竞争力的不是复杂的工作流而是沉淀在团队内部的领域知识。他们的整套体系实现了知识分层管控五层存储 × 五种类型 × 三级成熟度让知识有清晰的组织结构团队共建复用独立 Git 仓库 三种角色 自动冲突解决让知识从 个人经验 变成 团队资产流程沉淀积累INIT 注入→各阶段按需查询→ARCHIVE 自动提取让每次需求交付都是一次知识积累高效检索消费三级渐进式索引 查询预算解决上下文膨胀与知识利用的平衡生命周期治理自动衰减 Lint 机制 引用追踪闭环让知识库保持健康和活力人机协同提效远程操控 跨设备接管 异步审批让工作流 7×24 小时顺畅流转最后引用他们在项目 README 中写的那句话作为结尾Skill、Agent、工具链会随模型迭代更新但领域知识是永恒的。这才是对 Harness Engineering 最深刻的理解 —— 工作流是手段知识是目的。互动话题面对模型持续迭代当Harness 热潮褪去你觉得哪种资产不会被技术浪潮淘汰我是阿宇欢迎大家在评论区留言讨论注本文基于腾讯技术工程公众号发布的《Harness 不是目的知识才是护城河 —— 一个 AI 工程交付团队的知识沉淀实践》https://mp.weixin.qq.com/s/Xy8NwrHZRWv301eTZz4Dpw整理解读。
