最近半年，Harness Engineering 无疑是 AI 工程领域最火的概念。从 OpenAI 的 Codex 到 Anthropic 的 Claude Code，各大厂都在展示如何用工作流和约束引导 AI 模型输出高质量结果。但当业界还在争论 "该用多大的模型" 和 "该搭多复杂的工作流" 时，腾讯内部一个 AI 工程交付团队（AI Team）基于CodeBuddy 做内部 AI 工程化落地的实践报告《Harness 不是目的，知识才是护城河》却让我眼前一亮，他们提出了一个被严重低估的观点：工作流只是管道，知识才是流过管道的活水。

一、Harness Engineering 的本质：我们可能都理解错了重点

先简单回顾一下 Harness Engineering 的核心概念。这个术语源自 "马具" 的隐喻 —— 就像骑师通过缰绳和马鞍引导马的力量，而非增强马本身的体能，Harness Engineering 强调的是引导和约束 AI 模型的能力，而非提升模型本身。

业界三大标志性实践：

实践方	核心关注	关键动作
OpenAI — Codex	人机交互协议	零手写代码，通过精确指令驾驭 Agent
Cursor — Self-Driving	多 Agent 协同	背景 Agent 自动检测冲突并运行测试
Anthropic — Claude Code	长时运行稳定性	多层记忆系统 + CLAUDE.md 约束

这些实践确实令人兴奋，但腾讯 AI Team 在深度实践中发现了一个更本质的问题：大家都在讨论高速公路该修几车道、立交桥该怎么设计，却忘了问：路上跑的车（知识）从哪来？到哪去？怎么维护？

二、核心论点：为什么知识沉淀比工作流更重要

腾讯 AI Team 在实践中总结出三个关键认知，彻底改变了他们对 Harness Engineering 的理解：

1. 工作流是 "可替换的"，知识是 "可累积的"

今天用 16 阶段状态机编排工作流，明天可能用图结构 DAG 编排；Agent 调度模式从串行到并行到分层级联，变化很快。但团队积累的知识 —— 比如 "广告预算扣减在高并发下会超扣，需用 Redis+Lua 保证原子性"—— 这条知识不管工作流怎么变，都是有价值的。

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 个月未被引用 → 降级为 verified
• verified 条目 6 个月未被引用 → 降级为 draft
• draft 条目持续未引用 + 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, pitfall
ANALYSE_TECH	技术知识 (Layer 1) + 归档索引	decision, guideline(avoid), pitfall
ARCHITECT	架构模式 + 实体关系	decision, model
IMPLEMENT	编码实践 + 团队约定	guideline, pitfall
BUILD_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 行	"这条知识说了什么？"—— 完整内容 + 背景 + 适用场景

渐进查询流程：

1. 读全景目录（~50 行，零成本）→ 了解知识库全貌
2. 读分类清单（~100-300 行，低成本）→ 过滤相关条目
3. 读完整条目（按需，每条 50-200 行）→ 获取完整内容
4. 读原始产物（深入，可选）→ 追溯原始推导过程

这种方式让 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整理解读。