Harness不是目的，知识才是护城河 —— 一个AI工程交付团队的知识沉淀实践¶
Ch05.078 Harness不是目的，知识才是护城河 —— 一个AI工程交付团队的知识沉淀实践¶
📊 Level ⭐⭐⭐ | 14.7KB |
entities/tencent-knowledge-harness-practice.md
Tencent Knowledge Harness Practice
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 三级成熟度 + 自动衰减¶
自动衰减机制：- 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 |
深度分析¶
要点 1：知识沉淀是 Harness Engineering 的隐藏主线¶
原文描述了三支柱框架（上下文工程、架构约束、持续治理），但真正贯穿全文的核心洞察是：知识管理本身就是 Harness Engineering 的核心能力，而非附属品。这与 OpenAI/Anthropic 强调"记忆系统"的思路一脉相承，但本文更进一步——他们将知识从隐式能力显式化为五层存储架构，使知识管理成为可工程化的系统。
要点 2：工作流一次性困境的本质是知识缺失闭环¶
文章指出团队"每次都是从零开始"的困境，揭示了一个深刻矛盾：投入工程成本搭建工具链，却没有让工具链变得越来越聪明。这背后是知识论的问题——工作流消耗知识但不生产知识，因此需要专门的 ARCHIVE 阶段来从工作流产物中提取知识条目，形成闭环。
要点 3：五层存储架构的层级跃迁机制¶
Layer 3 项目知识可以"向上提升"到 Layer 1 或 Layer 2，这一设计解决了知识管理的核心痛点——项目知识往往因为只服务于单一场景而被束之高阁。通过明确的晋升机制，项目知识得以在更广泛的上下文中被复用和验证。借鉴区块链的共识机制，draft→verified 需要 1 人验证，verified→proven 需要 ≥2 人 + ≥2 项目，这一设计确保了知识质量的可信传递。
要点 4：知识按需消费的成本控制逻辑¶
三级渐进式索引（50 行全景→100-300 行分类→50-200 行条目）本质上是一种查询预算管理。在 Agent 每次搜索预算有限的情况下，这种设计确保了知识获取的效率最大化——用最小成本了解全貌，用中等成本定位相关条目，只在真正需要时才读取完整内容。Karpathy 的 LLM Wiki Pattern 在此被工程化落地。
要点 5：文件系统即状态机的哲学意义¶
"文件系统即状态机"的设计哲学将整个系统建立在文本持久化基础上，抛弃数据库和独立平台。这不仅简化了系统复杂度，更关键的是实现了真正的幂等性和可追溯性——所有变更都通过 Git 管理，所有状态都可从文件系统重建。在知识管理场景下，这意味着每一条知识都有完整的修改历史可查，每一次引用都有追踪闭环。
实践启示¶
1. 为每个工作流强制设计 ARCHIVE 阶段¶
不要让工作流成为单向消耗：每次工作流完成后，必须通过 @archiver 从产物中提取至少 N 条知识条目。如果某个工作流连续 3 次没有贡献新知识，说明该工作流的知识抽取机制失效。ARCHIVE 阶段是工作流闭环的必要组成，不是可选项。
2. 用成熟度晋升规则替代主观评审¶
建立明确的量化晋升标准：draft→verified 需要在同一工作流中被成功引用 1 次；verified→proven 需要在 ≥2 个不同项目中被验证。这样知识质量评审变成可自动化检查的流程，减少人为干预的主观性，同时让知识贡献者有明确的升级路径可预期。
3. 知识查询采用渐进式而非全量加载¶
不要在 Agent 启动时一次性加载完整知识库，而是在每个决策点按需查询。实现三层索引：Agent 启动时读 50 行全景目录建立心理地图（~300 tokens），进入特定领域时读该领域 100-300 行分类清单（~1-2K tokens），真正需要时再读完整条目（~2-5K tokens）。这样做的好处是将知识查询成本控制在合理范围内，避免 context 溢出。
4. 知识仓库独立部署，跨项目共享¶
团队知识库必须是独立 Git 仓库，不寄生于任何业务项目。这样做有三个好处：生命周期独立（业务项目删除不影响知识积累）、权限独立（可以单独管理知识库访问权限）、跨项目共享（Layer 1 技术知识可被所有项目引用）。具体路径结构：team-conventions/（Layer 0-T）、tech-wiki/（Layer 1）、biz-wiki/{domain}/（Layer 2）、docs/knowledge/（Layer 3）。
5. 用自动衰减机制代替人工清理¶
不要依赖人工判断知识是否过时。建立自动化规则：proven 条目 12 个月未被引用则降级为 verified；verified 条目 6 个月未被引用则降级为 draft；draft 条目持续未引用加上 Lint 标记则归档。这一机制确保知识库始终保持活性，过时知识不会长期占据检索结果，同时降低维护成本。
6. 冷启动用多源并行采集替代手工录入¶
新团队或历史项目引入知识库时，不要手工录入。用 /flow-import 管道：doc-collector 多源收集（Git/TAPD/iWiki/本地文档）→ codebase-profiler 生成代码画像（技术栈/模块/依赖/模式）→ knowledge-builder 标准化输出（4 维基线 + ≤13 条知识条目）。3 个 Agent 并行工作，冷启动周期从月级别压缩到天级别。