一个 AI 工程交付团队的知识沉淀实践
概述
本文是腾讯技术工程团队基于 AI Team 工程交付实践的深度复盘，针对 2026 年 AI 工程领域热门的 Harness Engineering 话题，提出了一个被业界普遍低估的核心观点：工作流编排只是手段，团队知识沉淀才是真正的技术护城河。
核心观点速览
| |
|---|
| 模型与工具链会迭代更新，但领域知识是永恒的复利资产 |
| 五层存储 × 五种类型 × 三级成熟度的三维正交体系 |
| |
| |
| |
推荐阅读人群
- 关注 Agent 工作流、Harness Engineering 的工程师
- 对 Big Model vs Big Harness 路线选择感兴趣的从业者
阅读价值
文章不仅提供了完整的知识管理方法论（五层存储、五种类型、三级成熟度、自动衰减机制），还结合 AI Team 项目的真实落地经验，给出了可复用的工程实现方案（独立 Git 知识仓库、三种角色权限、贡献暂存与异步合并、三级渐进式索引、Lint 治理机制等），是一篇兼具理论深度与工程实操性的优秀实践文章。
文章原文：
一、从 Harness Engineering 热潮说起
2025 年末至 2026 年初，AI 工程领域掀起了一场关于 Harness Engineering 的热烈讨论。这个术语源自"harness"（马具）的隐喻——就像骑师通过缰绳和马鞍来引导马的力量走正确的方向，而非增强马本身的体能，Harness Engineering 强调的是引导和约束 AI 模型的能力，而非提升模型本身。
从三大标志性实践来看，不同团队对 Harness Engineering 的侧重各有不同：
| | |
|---|
| | |
| | |
| | 多层记忆系统 + CLAUDE.md 约束，让 Agent 在复杂任务中保持一致性 |
这些实践无疑令人兴奋。但在我们团队深度实践的过程中，我们逐渐意识到一个更本质的问题——
工作流只是管道，知识才是流过管道的活水。
正如 Harness 圆桌讨论中的一个核心论断所指出的：
"将来的技术护城河不在模型，而在垂直领域知识的沉淀。"
模型会迭代，工具链会更新，工作流会重构。但你的团队在一个特定业务领域积累的领域模型、架构决策、最佳实践、已知陷阱、业务流程——这些知识是永恒的，是不会因为模型换代而失效的。
这就是我们在 AI Team 项目中坚持的核心理念：
Skill、Agent、工具链会随模型迭代更新，但领域知识是永恒的。
二、Harness Engineering 本质：三支柱与知识的位置
在深入我们的实践之前，先简要回顾 Harness Engineering 的理论框架。Harness 的核心要素可以归结为三个支柱：
注意看"上下文工程"这个支柱——知识检索注入和长/短期记忆赫然在列。再看"持续治理"——知识生命周期和自动衰减也是核心组成部分。
换句话说，知识管理本身就是 Harness Engineering 的核心能力，而不是附属品。只是在当前的热潮中，大家更多关注了"工作流怎么编排""Agent 怎么协同"这些更显眼的工程话题，而忽略了底层的知识基础设施。
这就好比大家都在讨论高速公路该修几车道、立交桥该怎么设计，却忘了问：路上跑的车（知识）从哪来？到哪去？怎么维护？
三、核心论点：为什么知识沉淀比工作流更重要
我们在实践中总结出三个关键认知：
3.1 工作流是"可替换的"，知识是"可累积的"
今天用 16 阶段状态机编排工作流，明天可能用图结构 DAG 编排。Agent 的调度模式从串行到并行到分层级联，变化很快。甚至于各大 SOTA 模型厂商也会逐渐内化和强化这种规划能力。但团队积累的知识——"广告预算扣减在高并发下会超扣，需用 Redis+Lua 保证原子性"——这条知识不管工作流怎么变，都是有价值的。
像 Anthropic 的 Claude Code 本身就是一个极其纯粹的 harness 实现，他们在 4 月份发的《Emotion concepts and their function in a large language model》论文就有类似的指向，可能未来的 Mythos 模型会通过探针系统 SAE 来实现模型的"情绪"稳定，进而从根本去实现 harness 希望解决的模型认知节省的问题。
3.2 没有知识沉淀的工作流是"一次性"的
我们观察到一个反模式：团队搭了很复杂的 Agent 工作流，每次需求都跑一遍全流程，但每次都是从零开始。上一次踩过的坑，下一次照踩不误。上一次做过的架构决策，下一次重新推导一遍。
这就是没有知识闭环的工作流——投入了工程成本搭建工具链，却没有让工具链变得越来越聪明。
3.3 知识是团队的"复利资产"
知识分为三类：
越是高阶的知识，越难以从模型中获得，越依赖团队的实践积累。
当你的知识库有成百上千条 proven（经过多项目验证）的知识条目时，新来的成员、新启动的项目，都能"站在前人肩上"。这就是知识的复利效应。
四、知识分层架构：五层存储 × 五种类型 × 三级成熟度
在 AI Team 系统中，我们设计了一套三维正交的知识体系架构。
4.1 知识体系的三个维度
| | |
|---|
| | Layer 0-P / 0-T / 1 / 2 / 3 — 从个人到团队到项目 |
| | model / decision / guideline / pitfall / process |
| | draft → verified → proven |
4.2 五层存储架构
为什么要分五层？ 因为不同范围的知识有不同的共享边界和生命周期。
- Layer 0-P（个人偏好）：你喜欢 4 空格缩进还是 2 空格？偏好函数式还是面向对象？这是纯个人的，不应该强制给团队。
- Layer 0-T（团队约定）：代码规范、Commit 规范、Review 标准。这是团队层面的"宪法"，相对稳定。
- Layer 1（技术知识）：跨项目通用的技术经验。比如"Spring Boot 多租户拦截器设计模式"、"Optional 依赖传递陷阱"。
- Layer 2（业务知识）：特定业务领域的领域模型、业务规则、业务流程。比如"广告审核流程：提交→机审→人审→上线"。
- Layer 3（项目知识）：仅在当前项目有意义的上下文。比如"本项目数据库用的是 TencentDB for MySQL 8.0"。
关键设计：知识可以"向上提升"。 Layer 3 的项目知识，如果被判定为跨项目通用，会自动提升到 Layer 1 或 Layer 2。
4.3 五种知识类型
知识按"描述的是什么"分类，遵循 MECE（互斥且完全穷尽）原则：
| | |
|---|
| | |
| | "选择事件驱动而非 RPC 同步，因为广告状态变更需要解耦" |
| 推荐做法 (recommend) 或禁止做法 (avoid) | recommend: "公共模块变更后的兼容性检查清单" |
| | |
| | |
这五种类型覆盖了我们在实践中遇到的所有知识形态。每一条知识只属于一个类型，来源信息记录在元数据中用于溯源分析。
4.4 三级成熟度 + 自动衰减
知识不是"写完就完了"。它有生命周期。
更关键的是自动衰减机制——知识如果长期不被引用，会自动降级：
为什么需要衰减？ 因为知识也会过时。一条三年前的"最佳实践"，可能因为框架版本升级已经不再适用。与其让过时知识误导 Agent，不如让它自然衰减退出活跃库。
这个设计借鉴了 Karpathy 在 LLM Wiki 概念中提出的 Lint 操作——定期识别矛盾、孤儿页、缺失交叉引用和数据缺口。
五、团队知识库：如何共享和更新
5.1 独立 Git 仓库 —— 知识的"单一事实来源"
我们做了一个关键的架构决策：团队知识库是一个独立的 Git 仓库，不寄生于任何业务项目。
为什么要独立仓库？
- 跨项目共享：同一个团队的多个项目连接同一个知识仓库，项目 A 沉淀的知识，项目 B 自动受益。
- 生命周期独立：业务项目可能归档或重构，但知识不应该跟着项目消失。
- 权限独立：知识库的贡献和消费权限可以独立于代码仓库管理。
5.2 三种团队角色
5.3 贡献模式 —— "贡献暂存 + 异步合并"
我们借鉴了区块链的三个核心思想，但用 Git 作为实现载体：
| | |
|---|
| | |
| | |
| | draft→verified: 1 人验证；verified→proven: ≥2 人 + ≥2 项目 |
log.md 示例：
5.4 冲突解决策略
当多名成员同时向知识库贡献时，按以下策略自动处理：
| |
|---|
| |
| |
| |
| 写入 contributions/conflicts/，通知 maintainer 裁决 |
| 保留较低成熟度 + 标记 contradiction |
设计理念： 大多数情况（纯新增、证据追加、成熟度提升）可以自动处理，只有真正的内容矛盾才需要人工介入。这让知识的共建过程尽可能低摩擦。
六、工作流如何服务于知识沉淀
现在回到工作流。在 AI Team 系统中，我们的 16 阶段状态机不是为了"好看"或"复杂"——它的每一个阶段都与知识的流动紧密关联。
6.1 知识的完整生命周期：三通道沉淀
三个关键时刻：
- INIT 阶段（知识注入）：工作流启动时，自动
git pull 团队知识仓库，将知识全景目录注入 Agent 的查询入口。新启动的工作流自动站在前人肩上。
- 各阶段执行中（知识消费）：Agent 在决策点按需查询知识库。比如
@tech-explorer 在技术分析阶段查询"有没有类似的架构决策"，@backend-architect 在架构设计阶段查询"有没有已知的反模式"。
- ARCHIVE 阶段（知识提取）：工作流完成后，
@archiver 自动从全流程产物中提取知识条目——架构决策变成 decision，踩过的坑变成 pitfall，总结的经验变成 guideline。提取后执行提升判定，符合条件的自动提升到 Layer 1 或 Layer 2。
6.2 各阶段查询什么知识
每个阶段的 Agent 有独立的查询预算，聚焦不同类型的知识：
| | |
|---|
| | |
| | decision, guideline(avoid), pitfall |
| | |
| | |
| | pitfall, guideline(avoid) |
为什么要限制查询预算？ 因为 Agent 如果无限制地读取知识库，会导致上下文膨胀——这恰恰是 Harness Engineering 要解决的核心问题之一。我们通过预算控制，让知识消费"精准"而非"贪婪"。
6.3 冷启动导入 —— /flow-import
对于历史项目（已有大量代码但没有知识库），我们提供了 /flow-import 命令，通过 3 个 Agent 的管道实现冷启动：
所有产出条目初始 maturity 为 draft，后续工作流的执行会逐步验证和提升它们。
七、知识的按需消费：三级索引 + 查询预算
7.1 从"推送"到"主动查询"的范式转变
传统做法是在 Agent 启动时，把一堆知识"推送"给它。这有两个问题：
- 信息过载：推送太多知识，Agent 反而被淹没，找不到关键信息。
- 不精准：预先推送的知识不一定是 Agent 当前决策点需要的。
我们的设计理念是：Agent 不被动接收固定数量的知识推荐，而是通过三级渐进式索引主动按需查阅。
7.2 三级渐进式索引
借鉴 Karpathy 的 LLM Wiki Pattern，我们设计了三层索引结构：
| | | |
|---|
| | | "知识库有什么？"——分类统计 + 按阶段推荐查阅路径 |
| | | "这个分类有哪些条目？"——每条一行摘要（ID + 标题 + 成熟度 + 标签） |
| | | "这条知识说了什么？"——完整内容 + 背景 + 适用场景 |
渐进查询流程：
这意味着 Agent 可以用 ~50 行的成本 了解知识库全貌，用 ~300 行的成本 定位到相关条目，只在真正需要时才读取完整内容。对比"一次性推送 50 条完整知识"（可能 5000-10000 行），上下文效率提升了一个数量级。
7.3 知识引用追踪闭环
Agent 查询知识后，在输出产物中记录引用：
ARCHIVE 阶段会读取所有阶段产物中的 knowledgeReferences，批量更新 evidence.last_referenced 字段。这形成了自动化的引用追踪闭环——被引用的知识 maturity 会自动提升，长期未引用的会自动衰减。
八、突破人机交互瓶颈：随时随地保障工作流流转
前面七个章节聚焦于"知识如何沉淀"和"工作流如何服务于知识"。但在实际落地中，我们遇到了一个被普遍忽视的工程现实——
工作流的流转依赖于人的在场。
16 阶段状态机设计得再精密，如果 Agent 在执行过程中需要人工确认（比如架构评审节点、产物验收节点），而你恰好在开会、通勤、或者吃饭——工作流就卡住了。这不是知识架构的问题，而是人机交互模式的瓶颈。
8.1 问题：Harness 工作流的"在场依赖"
传统的 Agent 工作流有一个隐含假设：操作者坐在电脑前，IDE 打开着，随时可以响应 Agent 的请求。
但现实是：
一天 8 小时工作，真正能"坐在工位操控 Agent"的时间可能不到 4 小时。更关键的是，那些"碎片时间"——会议间隙的 5 分钟、通勤路上的 30 分钟、晚饭后想 review 一下——恰恰是 Agent 需要你确认的黄金窗口。
如果工作流在你离开时就暂停，在你回来时才继续，那工作流的效率至少折半。
8.2 解法：远程操控 + 跨设备接管
在实际工程实践中，我们引入了 Hapi 内网版来解决这个问题。它的核心能力是：
在办公网下（不需要开启 IOA 远程工作，微信或企微均可直接打开），用手机远程接管运行在开发机上的 AI 编程会话。
这意味着：
核心能力矩阵：
8.3 与知识沉淀闭环的结合
远程操控能力不仅解决了"人机交互"的效率问题，更重要的是保障了知识沉淀闭环的完整性。
回顾第六章的知识流动路径：
INIT（知识注入）→ 各阶段执行（知识消费）→ ARCHIVE（知识提取）
需要说明的是，由于我们的 Harness 工作流采用"文件系统即状态机"的设计，暂停本身不会丢失任何进度——所有阶段产物和状态都持久化在文件中，随时可以从断点恢复。但暂停过久带来的真正问题是效率和时效性：
- 交付周期拉长：一个原本 Agent 可以连续推进的需求，因为卡在人工确认节点（如架构评审、产物验收），从 1 天交付变成 3 天交付。工作流没出错，只是在"等人"。
- 知识沉淀的时效性下降：ARCHIVE 阶段的知识提取依赖工作流完整走完。流程卡得越久，新产生的知识沉淀到团队知识库的速度就越慢，后续需求无法及时消费到最新的经验。
- 碎片时间浪费：你在会议间隙有 5 分钟、通勤路上有 30 分钟，这些碎片时间本可以推进工作流，但因为不在工位、没有 IDE 环境而白白流失。
有了远程操控能力后，这些碎片时间都能被利用——工作流可以更紧凑地走完全流程，从 INIT 的知识注入，到各阶段的知识消费和决策确认，到 ARCHIVE 的知识提取和自动提升，大幅缩短交付周期，加速知识沉淀闭环的流转。
8.4 工程架构设计启示
这个经验给我们的 Harness 工程架构设计带来一个重要启示：
好的 Harness 工程不仅要设计"Agent 怎么跑"，还要设计"人怎么随时参与"。
具体到架构层面，这意味着：
- 状态持久化：工作流的状态必须是持久化的（文件系统即状态机），而不是存在内存中。这样无论从哪个设备接入，都能看到一致的状态。
- 断点恢复：每个阶段的入口和出口都有明确的持久化产物，支持从任意断点恢复。
- 异步审批：人工确认节点应设计为异步模式——Agent 提交产物、暂停等待，人类可以在任意时间、任意设备上审批后，Agent 继续执行。
- 通知触达：关键节点（如架构评审、产物验收）应通过企业微信等渠道主动推送，而非被动等待人来检查。
这些设计与 AI Team 的"文件系统即状态机"哲学天然契合——所有状态都在文件中，不依赖内存或特定进程，远程设备通过 Web 界面看到的就是真实的工作流状态。
九、落地经验与思考
9.1 历史项目引入：从 0 到 1 的冷启动挑战
最大的挑战不是设计架构，而是让已有项目的隐性知识显性化。很多团队的知识散落在 Wiki、TAPD 评论、企业微信聊天记录、甚至团队成员的脑子里。
我们的做法是：
- 多源收集：
/flow-import 支持 Git 仓库扫描、TAPD 需求拉取、iWiki 文档导入、本地文档解析、口述录入等多种输入方式。
- 渐进导入：不追求一次性导入完美，所有导入知识初始 maturity 为 draft（置信度 0.5-0.6），通过后续工作流的实际使用逐步验证提升。
- 断点恢复：导入过程通过
import-state.json 持久化进度，支持中断后继续。
9.2 知识膨胀治理：Lint 机制
知识库不能只进不出。我们设计了定期的 Lint 机制（借鉴 Karpathy 的 LLM Wiki）：
Lint 触发方式包括：每完成 10 个工作流自动触发、/knowledge lint 手动触发、连续 30 天未执行时在下次 /flow-run 启动时提醒。
9.3 Big Model vs Big Harness —— 我们的务实立场
业界存在一场争论：该投入更多在"更大更强的模型"上，还是"更复杂的 Harness"上？
我们的立场是：这不是非此即彼的选择，而是要找到适合你团队的平衡点。
- 模型能力提升是大势所趋，投在知识工程上的架构应该对模型能力的提升保持开放——当模型更强时，同样的知识可以被更好地利用。
- 但模型能力提升不能替代领域知识。再强的模型也不知道你的业务系统里有哪些隐藏的坑。
- 知识工程的投入是确定性回报：每沉淀一条 proven 知识，所有后续工作流都受益。而模型能力提升的回报是概率性的，你不知道下一代模型在你的特定场景上是否真的更好。
9.4 从"文件即状态"到"知识即资产"
AI Team 的设计哲学中，有一条看似朴素但非常重要的原则：文件系统即状态机。所有的状态、产物、知识都以文件形式存在，没有数据库、没有独立平台。
这不是技术妥协，而是刻意选择：
- 可见性：所有知识都是 Markdown 文件，人可以直接阅读、编辑、审查。
- 可迁移性：不依赖任何特定平台或服务，换工具链时知识不会丢失。
- IDE 原生：
.codebuddy/ 目录驱动，被 IDE 原生识别，零配置成本。
十、总结与展望
回到文章开头的核心论点：Harness 不是目的，知识才是护城河。
我们在 AI Team 项目中的实践表明：
- 知识分层管理（五层存储 × 五种类型 × 三级成熟度）让知识有了清晰的组织结构，Agent 可以精准按需消费。
- 团队知识库共建共享（独立 Git 仓库 + 三种角色 + 自动冲突解决）让知识从"个人经验"变成"团队资产"。
- 工作流服务于知识沉淀（INIT 注入 → 各阶段按需查询 → ARCHIVE 自动提取）让每次需求交付都是一次知识积累。
- 知识的按需消费（三级渐进式索引 + 查询预算）解决了上下文膨胀与知识利用的平衡。
- 知识的生命周期管理（自动衰减 + Lint 机制 + 引用追踪闭环）让知识库保持健康和活力。
- 突破人机交互瓶颈（远程操控 + 跨设备接管 + 异步审批）让工作流 7×24 小时顺畅流转，保障知识沉淀闭环的完整性。
展望未来，我们认为有几个方向值得探索：
- 知识的语义检索增强：当前的三级索引是基于结构化标签的过滤，未来可以引入向量检索实现语义级的知识发现。
- 跨团队知识联邦：不同团队的知识仓库之间如何安全地共享通用技术知识（Layer 1），同时保护业务知识（Layer 2）的边界。
- 知识质量的自动评估：除了基于引用频率的成熟度提升，能否用模型来评估知识条目的质量和时效性。
- 全异步工作流：结合远程操控能力，探索完全异步的人机协作模式——Agent 自主执行非关键路径，仅在关键决策点异步通知人类审批，进一步释放工作流的 7×24 小时潜力。
最后，引用我们在项目 README 中写的那句话作为结尾：
Skill、Agent、工具链会随模型迭代更新，但领域知识是永恒的。AI Team 的每次交付都自动沉淀知识到团队共享仓库，所有成员共建共享，新工作流启动时自动站在前人肩上。
这就是我们对 Harness Engineering 的理解——工作流是手段，知识是目的。
作者： stevenpxiao（腾讯技术工程）
发布时间： 2026-04-27
原文链接：点击这里 
AI 速览
