---
title: Harness不是目的，知识才是护城河 —— 一个AI工程交付团队的知识沉淀实践
source_url: https://mp.weixin.qq.com/s/Xy8NwrHZRWv301eTZz4Dpw
publish_date: 2026-04-27
tags: [wechat, article, claude, openai, agent, harness, llm, gemini]
review_value: 7
review_confidence: 7
review_recommendation: neutral
sha256: 7ea1057e8b015149ebaea52f20c34a70882bd74def6aec426f5e53bf1aebee35
---
# Harness不是目的，知识才是护城河 —— 一个AI工程交付团队的知识沉淀实践
原创 腾讯程序员 腾讯技术工程
2026年4月27日 17:37 广东
作者：stevenpxiao
当 Harness Engineering 成为 2026 年最热门的 AI 工程话题，业界争论焦点集中在"该用多大的模型"还是"该搭多复杂的工作流"时，我们团队在落地实践中发现了一个被低估的事实——构建 Harness 工作流不是最终目的，私域和团队知识的沉淀才是真正的技术护城河。本文分享我们在 AI Team 工程交付编排系统中，如何设计知识分层架构、如何让团队知识库共建共享、如何让工作流成为知识沉淀的载体、如何突破人机交互瓶颈实现随时随地的工作流流转，以及我们的落地经验和思考。
## 一、从 Harness Engineering 热潮说起
2025 年末至 2026 年初，AI 工程领域掀起了一场关于 **Harness Engineering** 的热烈讨论。这个术语源自"harness"（马具）的隐喻——就像骑师通过缰绳和马鞍来**引导**马的力量走正确的方向，而非增强马本身的体能，Harness Engineering 强调的是**引导和约束 AI 模型的能力**，而非提升模型本身。
从三大标志性实践来看，不同团队对 Harness Engineering 的侧重各有不同：
| 实践方 | 核心关注 | 关键动作 |
|--------|----------|----------|
| OpenAI — Codex | 人机交互协议 | 零手写代码，通过精确的指令协议驾驭 Agent |
| Cursor — Self-Driving | 多 Agent 协同 | 背景 Agent 自动检测冲突并运行测试 |
| Anthropic — Claude Code | 长时运行稳定性 | 多层记忆系统 + CLAUDE.md 约束，让 Agent 在复杂任务中保持一致性 |
> 工作流只是管道，知识才是流过管道的活水。
正如 Harness 圆桌讨论中的一个核心论断所指出的：
> "将来的技术护城河不在模型，而在垂直领域知识的沉淀。"
## 二、Harness Engineering 本质：三支柱与知识的位置
Harness Engineering 三支柱：
| 上下文工程 Context Eng. | 架构约束 Architecture | 持续治理 Governance |
|------------------------|---------------------|---------------------|
| · 长/短期记忆 | · Agent 编排模式 | · 质量门禁 |
| · 知识检索注入 | · 状态机设计 | · 知识生命周期 |
| · 渐进式披露 | · 降级策略 | · 自动衰减 |
| · 上下文防火墙 | · 安全边界 | · 持续进化 |
**知识管理本身就是 Harness Engineering 的核心能力**，而不是附属品。
## 三、核心论点：为什么知识沉淀比工作流更重要
### 3.1 工作流是"可替换的"，知识是"可累积的"
今天用 16 阶段状态机编排工作流，明天可能用图结构 DAG 编排。Agent 的调度模式从串行到并行到分层级联，变化很快。但团队积累的知识——"广告预算扣减在高并发下会超扣，需用 Redis+Lua 保证原子性"——这条知识不管工作流怎么变，都是有价值的。
### 3.2 没有知识沉淀的工作流是"一次性"的
团队搭了很复杂的 Agent 工作流，每次需求都跑一遍全流程，但**每次都是从零开始**。上一次踩过的坑，下一次照踩不误。这就是**没有知识闭环的工作流**——投入了工程成本搭建工具链，却没有让工具链变得越来越聪明。
### 3.3 知识是团队的"复利资产"
知识分为三类：**散点型知识**（孤立的事实）、**因果型知识**（A 导致 B 的推理链）、**时空型知识**（特定场景和时间窗口下才成立的经验）。越是高阶的知识，越难以从模型中获得，越依赖团队的实践积累。
## 四、知识分层架构：五层存储 × 五种类型 × 三级成熟度
### 4.1 三个维度
| 维度 | 回答的问题 | 定义 |
|------|------------|------|
| 存储层（在哪） | 知识存在哪里？ | Layer 0-P 0-T 1 2 3 — 从个人到团队到项目 |
| 知识类型（是什么） | 知识描述的是什么？ | model / decision / guideline / pitfall / process |
| 成熟度（多可信） | 知识经过多少验证？ | draft → verified → proven |
### 4.2 五层存储架构
| 层级 | 路径 | 说明 |
|------|------|------|
| Layer 0-P | ~/.ai-team/ | 个人偏好，纯本地，不共享 |
| Layer 0-T | team-conventions/ | 团队约定，Git 共享 |
| Layer 1 | tech-wiki/ | 技术知识，跨项目通用 |
| Layer 2 | biz-wiki/{domain}/ | 业务知识，按领域划分 |
| Layer 3 | docs/knowledge/ | 项目知识，随项目走 |
**知识可以"向上提升"**：Layer 3 的项目知识，如果被判定为跨项目通用，会自动提升到 Layer 1 或 Layer 2。
### 4.3 五种知识类型（MECE 原则）
| 类型 | 定义 | 示例 |
|------|------|------|
| model | 实体定义、数据结构、关系图 | "广告计划包含预算/出价/投放时段三个核心字段" |
| decision | 技术选型、架构决策及理由 | "选择事件驱动而非 RPC 同步，因为广告状态变更需要解耦" |
| guideline | 推荐做法或禁止做法 | recommend: "公共模块变更后的兼容性检查清单" |
| pitfall | 已知风险、故障模式、排查步骤 | "广告预算扣减在高并发下会超扣" |
| process | 业务流程、状态机、操作步骤 | "广告审核：提交→机审→人审→上线" |
### 4.4 三级成熟度 + 自动衰减
```
draft（新提取，单一来源）
  ↓ 在 1 个工作流中被成功引用
verified（单项目验证）
  ↓ 在 ≥2 个不同项目中被验证
proven（成熟/可信赖）
```
**自动衰减机制**：
- proven 条目 12 个月未被引用 → 降级为 verified
- verified 条目 6 个月未被引用 → 降级为 draft
- draft 条目持续未引用 + Lint 标记 → 归档
## 五、团队知识库：如何共享和更新
### 5.1 独立 Git 仓库
团队知识库是一个**独立的 Git 仓库**，不寄生于任何业务项目。
```
team-knowledge.git
├── knowledge-catalog.md          ← 全景目录（Agent 查询入口）
├── .knowledge-config.yaml       ← 团队配置
├── team-conventions/           ← Layer 0-T
├── tech-wiki/                  ← Layer 1
├── biz-wiki/                   ← Layer 2
├── project-profiles/           ← 项目画像
└── contributions/              ← 贡献暂存区
```
**为什么独立仓库？** 跨项目共享、生命周期独立、权限独立。
### 5.2 三种团队角色
| 角色 | 权限 | 适用人群 |
|------|------|----------|
| maintainer | 裁决内容冲突、审批 proven 提升、管理成员 | 团队负责人、资深工程师 |
| contributor | 通过工作流自动贡献 | 正式团队成员 |
| reader | 只消费知识，不贡献 | 新成员试用期 |
### 5.3 贡献模式：借鉴区块链思想
- **不可篡改的追加日志**：log.md 只追加不修改
- **贡献可溯源**：evidence.contributors[]
- **共识机制**：draft→verified: 1 人验证; verified→proven: ≥2 人 + ≥2 项目
### 5.4 冲突解决策略
| 冲突类型 | 处理方式 |
|----------|----------|
| 纯新增（不同条目） | 自动合并 |
| 证据追加（同条目验证） | 自动合并 |
| 内容矛盾 | 写入 contributions/conflicts/，通知 maintainer 裁决 |
| 成熟度冲突 | 保留较低成熟度 + 标记 contradiction |
## 六、工作流如何服务于知识沉淀
### 6.1 知识的完整生命周期：三通道沉淀
**三个关键时刻**：
- **INIT 阶段（知识注入）**：工作流启动时，自动 `git pull` 团队知识仓库
- **各阶段执行中（知识消费）**：Agent 在决策点按需查询知识库
- **ARCHIVE 阶段（知识提取）**：工作流完成后，`@archiver` 自动从全流程产物中提取知识条目
### 6.2 各阶段查询什么知识
| 阶段 | 查询焦点 | 重点知识类型 |
|------|----------|-------------|
| ANALYSE_PRODUCT | 业务知识 + 历史需求 | model, process, pitfall |
| ANALYSE_TECH | 技术知识 + 归档索引 | decision, guideline(avoid), pitfall |
| ARCHITECT | 架构模式 + 实体关系 | decision, model |
| IMPLEMENT | 编码实践 + 团队约定 | guideline, pitfall |
| BUILD_VERIFY | 反模式库 | pitfall, guideline(avoid) |
### 6.3 冷启动导入：/flow-import
3 个 Agent 的管道：
1. `@doc-collector` → 多源资料收集（Git/TAPD/iWiki/本地文档/口述）
2. `@codebase-profiler` → 代码画像（技术栈/模块/依赖/模式，60 次搜索预算）
3. `@knowledge-builder` → 知识标准化（4 维基线 + ≤13 条知识条目 + 归档总结）
## 七、知识的按需消费：三级渐进式索引 + 查询预算
### 7.1 三级渐进式索引（借鉴 Karpathy LLM Wiki Pattern）
| 层级 | 文件 | 大小 | 作用 |
|------|------|------|------|
| Layer A: 全景目录 | knowledge-catalog.md | ~50 行 | "知识库有什么？" |
| Layer B: 分类清单 | 各目录下的 catalog.md | ~100-300 行 | "这个分类有哪些条目？" |
| Layer C: 完整条目 | TK-*.md / BK-*.md | ~50-200 行 | "这条知识说了什么？" |
**渐进查询流程**：Agent 可以用 ~50 行的成本了解知识库全貌，用 ~300 行的成本定位到相关条目，只在真正需要时才读取完整内容。
### 7.2 知识引用追踪闭环
Agent 查询知识后，在输出产物中记录 `knowledgeReferences`。ARCHIVE 阶段读取所有阶段的 `knowledgeReferences`，批量更新 `evidence.last_referenced` 字段，形成自动化的引用追踪闭环。
## 八、突破人机交互瓶颈：随时随地保障工作流流转
### 8.1 问题：Harness 工作流的"在场依赖"
工作流的流转依赖于人的在场。一个典型的工作日 8 小时中，真正能"坐在工位操控 Agent"的时间不到 4 小时。
### 8.2 解法：Hapi 内网版
核心能力：
- **跨设备会话接管**：手机/平板/电脑均可接管同一 Agent 会话
- **24 小时待机**：开发机上的 Agent 持续运行
- **PWA 原生体验**：安装到桌面后像原生 App
- **多助手切换**：支持 Codebuddy/Codex/Gemini 等
- **自主模式**：YOLO 模式让 Agent 自主执行
### 8.3 架构设计启示
- **状态持久化**：工作流的状态必须是持久化的（文件系统即状态机）
- **断点恢复**：每个阶段的入口和出口都有明确的持久化产物
- **异步审批**：人工确认节点应设计为异步模式
- **通知触达**：关键节点应通过企业微信等渠道主动推送
## 九、落地经验与思考
### 9.1 历史项目引入：从 0 到 1 的冷启动挑战
多源收集：`/flow-import` 支持 Git 仓库扫描、TAPD 需求拉取、iWiki 文档导入、本地文档解析、口述录入等多种输入方式。渐进导入，所有导入知识初始 maturity 为 draft。
### 9.2 知识膨胀治理：Lint 机制
借鉴 Karpathy 的 LLM Wiki，定期检查：索引不一致、孤儿条目、矛盾检测、过时检测、重复/相似条目、成熟度衰减。
### 9.3 Big Model vs Big Harness — 务实立场
- 模型能力提升是大势所趋，投在知识工程上的架构应该对模型能力的提升保持开放
- 但模型能力提升不能替代领域知识。再强的模型也不知道你的业务系统里有哪些隐藏的坑
- 知识工程的投入是确定性回报，每沉淀一条 proven 知识，所有后续工作流都受益
### 9.4 从"文件即状态"到"知识即资产"
AI Team 的设计哲学：**文件系统即状态机**。所有状态、产物、知识都以文件形式存在，没有数据库、没有独立平台。
## 十、总结与展望
**核心论点**：Harness 不是目的，知识才是护城河。
**六项关键实践**：
1. 知识分层管理（五层存储 × 五种类型 × 三级成熟度）
2. 团队知识库共建共享（独立 Git 仓库 + 三种角色 + 自动冲突解决）
3. 工作流服务于知识沉淀（INIT 注入 → 各阶段按需查询 → ARCHIVE 自动提取）
4. 知识的按需消费（三级渐进式索引 + 查询预算）
5. 知识的生命周期管理（自动衰减 + Lint 机制 + 引用追踪闭环）
6. 突破人机交互瓶颈（远程操控 + 跨设备接管 + 异步审批）
**未来探索方向**：
- 知识的语义检索增强：引入向量检索实现语义级的知识发现
- 跨团队知识联邦：不同团队的知识仓库之间如何安全地共享通用技术知识（Layer 1），同时保护业务知识（Layer 2）的边界
- 知识质量的自动评估：用模型来评估知识条目的质量和时效性
- 全异步工作流：结合远程操控能力，探索完全异步的人机协作模式
**参考文献**：Karpathy LLM Wiki — 知识复合增长：Ingest + Query + Lint