【转载】Harness不是目的，知识才是护城河
这篇转载摘录讨论的是 Harness Engineering 与 Agent 工作流建设中的长期价值判断：Agent、Harness、工作流编排和具体框架都只是驾驭模型的手段，真正可积累的资产是团队在业务交付中形成的领域知识。内容将 Harness Engineering 概括为上下文工程、架构约束和持续治理三支柱，强调通过记忆管理、检索注入、Agent 编排、状态机或 DAG 流程、安全边界、质量门禁等方式，让模型在复杂任务中稳定执行。文章进一步指出，工作流形态、调度模式和模型能力都会快速变化，但领域模型、架构决策、业务规则、已知陷阱和最佳实践不会因工具换代而失效。为避免知识库沦为平台依赖，文中倾向采用 Git + Markdown 管理团队知识，并给出 team-knowledge.git 目录和个人偏好、团队约定、技术知识、业务知识、项目知识五层存储划分。它特别强调知识闭环：工作流启动时消费已有知识，结束后沉淀新经验，同时通过引用追踪、成熟度提升、自动衰减和 Lint 治理防止知识只进不出。适合关注 AI 工程化、Agent 编排、团队知识库建设和软件研发治理的读者，用来重新判断工具投入与知识资产沉淀之间的优先级。
文章地址： https://mp.weixin.qq.com/s/Xy8NwrHZRWv301eTZz4Dpw
提炼总结#
Agent / Harness / 工作流编排不是护城河，真正的护城河是团队在业务交付中持续沉淀出来的领域知识。
不要只沉迷于 Harness / Agent / 工作流框架 更重要的是把团队知识结构化、版本化、可查询、可验证、可衰减
所以 Harness Engineering 关注的是：
如何组织上下文
如何约束模型行为
如何设计 Agent 工作流
如何维护长期记忆
如何做质量治理
如何让 Agent 在复杂任务中稳定执行
上下文工程 Context Engineering
架构约束 Architecture
持续治理 Governance
team-knowledge.git
team-knowledge.git
├── knowledge-catalog.md
├── team-conventions/
├── tech-wiki/
├── biz-wiki/
├── project-profiles/
└── contributions/
因为很多所谓“知识库系统”最后都会变成平台依赖，而 Git + Markdown 的方式反而很稳定、透明、易迁移。
-
Harness Engineering 的本质不是堆复杂工作流，而是用上下文、约束、记忆和治理来驾驭模型。
-
工作流会变，模型会变，Agent 框架会变，但团队领域知识是长期资产。
-
知识需要被结构化管理：放在哪一层、属于什么类型、有多可信。
-
每次工作流执行都应该形成闭环：启动时消费知识，结束时沉淀知识。
**5. 知识库不能只进不出，需要引用追踪、成熟度提升、自动衰减和 Lint 治理。 ** 6. Agent 工作流不只是自动化执行，还要支持人随时异步参与，否则流程会卡在人工确认节点。
- 真正的护城河不是“我会用某个 Agent 框架”，而是“我的团队有一套持续增长、可复用、可治理的领域知识系统”。
重要观点#
构建 Harness 工作流不是最终目的，私域和团队知识的沉淀才是真正的技术护城河。
这个术语源自"harness"（马具）的隐喻——就像骑师通过缰绳和马鞍来引导马的力量走正确的方向，而非增强马本身的体能，Harness Engineering 强调的是引导和约束 AI 模型的能力，而非提升模型本身。
"将来的技术护城河不在模型，而在垂直领域知识的沉淀。"
模型会迭代，工具链会更新，工作流会重构。但你的团队在一个特定业务领域积累的领域模型、架构决策、最佳实践、已知陷阱、业务流程——这些知识是永恒的，是不会因为模型换代而失效的。
Skill、Agent、工具链会随模型迭代更新，但领域知识是永恒的。
┌─────────────────────────────────────────────────────┐
│ Harness Engineering 三支柱 │
├─────────────────┬─────────────────┬─────────────────┤
│ 上下文工程 │ 架构约束 │ 持续治理 │
│ Context Eng. │ Architecture │ Governance │
├─────────────────┼─────────────────┼─────────────────┤
│ · 长/短期记忆 │ · Agent 编排模式 │ · 质量门禁 │
│ · 知识检索注入 │ · 状态机设计 │ · 知识生命周期 │
│ · 渐进式披露 │ · 降级策略 │ · 自动衰减 │
│ · 上下文防火墙 │ · 安全边界 │ · 持续进化 │
└─────────────────┴─────────────────┴─────────────────┘
今天用 16 阶段状态机编排工作流，明天可能用图结构 DAG 编排。Agent 的调度模式从串行到并行到分层级联，变化很快。甚至于各大SOTA模型厂商也会逐渐内化和强化这种规划能力。但团队积累的知识——"广告预算扣减在高并发下会超扣，需用 Redis+Lua 保证原子性"——这条知识不管工作流怎么变，都是有价值的。
[注]: 这里的 “16 阶段状态机” 不一定是一个固定行业标准名词，它更像是在说：把一个 Agent / 工作流拆成 16 个明确阶段，每个阶段只能按规则进入下一个阶段，用状态机来控制流程。 16 阶段状态机：不是固定标准，而是指把 Agent 流程拆成很多固定阶段，用状态流转控制执行。
图结构 / DAG 编排：就是 LangGraph 这类方式，把任务抽象成节点和边，支持分支、并行、汇聚、条件跳转。 核心:
当前状态 -> 根据条件判断 -> 进入下一个状态
所以 状态机更像“流程固定、状态清晰、分支可控”的编排方式。
而DAG结构：
节点 = 一个任务 / 一个 Agent / 一个工具调用 / 一个处理步骤
边 = 从哪个节点流向哪个节点
用户问题
↓
意图识别
↓
Query 改写
↓
并行检索
↙ ↓ ↘
商品库 QA库 评论库
↘ ↓ ↙
结果融合
↓
答案生成
↓
合规检查
↓
输出
这就是没有知识闭环的工作流——投入了工程成本搭建工具链，却没有让工具链变得越来越聪明。
五层存储架构
┌──────────────────────────────────────────────────────────────┐
│ 五层知识存储 │
├──────────┬──────────────────────────────┬────────────────────┤
│ 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 0-P（个人偏好）：你喜欢 4 空格缩进还是 2 空格？偏好函数式还是面向对象？这是纯个人的，不应该强制给团队。
Layer 0-T（团队约定）：代码规范、Commit 规范、Review 标准。这是团队层面的"宪法"，相对稳定。
Layer 1（技术知识）：跨项目通用的技术经验。比如"Spring Boot 多租户拦截器设计模式"、"Optional 依赖传递陷阱"。
Layer 2（业务知识）：特定业务领域的领域模型、业务规则、业务流程。比如"广告审核流程：提交→机审→人审→上线"。
Layer 3（项目知识）：仅在当前项目有意义的上下文。比如"本项目数据库用的是 TencentDB for MySQL 8.0"。
评论
还没有评论，来发第一个吧