https://zhuanlan.zhihu.com/p/2027708773662226067

一、真实大系统为什么难做 Harness Engineering

1. 业务耦合

任何一个程序都不是孤立存在的。面对一个新需求，往往不是改一个函数，而是要理解一整条数据链路、多个依赖关系、若干状态转换和一批边界场景。

这意味着 agent 真正需要的不是“更多文档”，而是真实有效，能被构建、筛选、验证的上下文。

2. 跨部门依赖

对于一个项目来说，它依赖的很多上游和下游系统往往并不在自己控制范围内。你可能只能调用，不能修改；只能访问测试环境，不能接触生产；只能拿到接口文档，拿不到真实异常数据。

在这种情况下，单纯把本项目代码交给 agent，并不能让它真正理解系统行为。

3. 复杂业务信息

给 agent 提供真实、有效、不冗余的上下文，本身就是困难的事情。

过少的上下文会让 agent 幻觉，过多的上下文会让 agent 迟钝。

而传统业务系统最大的问题，恰恰是上下文很多，但真正有用的上下文很少。

4. 文档腐化

我们当然可以投入资源，把公司现有文档抽取出来，构建知识库，形成一套给 agent 使用的 skills。

但传统文档有几个问题：

1. 图片、视频、流程图这类信息对 agent 不友好。
2. 文档和代码、接口、部署状态往往不是精确对应。
3. 文档年久失修，可能存在错误信息。
4. 很多关键信息其实在开发者经验里，没有沉淀成文档。

单纯做知识库，不足以解决大系统的 Harness Engineering 问题。

---

二、问题不在“让 agent 知道更多”，而在“让 agent 进入一个可验证的环境”

面对这些困难，一个很自然的想法是：给 agent 代码 + 部署的可调试环境。

这个环境通常是测试环境，里面包含：

• 足够完整的部署。
• 依赖接口的访问权限。
• 调试工具。
• 项目源码。
• 若干 roles、skills、验收方式。

这当然是一个好的方向。在系统足够简单、边界足够清晰的时候，这甚至已经足够构成一个不错的 harness。

但当业务体系继续增长，链路继续拉长，耦合继续增加，就会出现一个问题：

测试环境并不能自动变成 agent 可理解、可调用、可验证的工作环境。

测试环境是真实的，但太重。

知识库是轻的，但不够准。

agent对不同级别的prompt的理解程度是有优先级的，一般是：

人类语言 < 伪代码 < 程序代码 < 完整工程

基于 Confluence 等的文档是人类语言、伪代码级别的，对于 agent 来说往往是不够的，我寻找一种折中的方式。

它是对真实系统的压缩，是围绕数据流、状态流和验证点构造出来的 agent 工作外壳，而又小于完整工程的复杂性。

我把这个东西称为 data-flow-skills，简称 dfs。

---

三、什么是 Data-Flow-Skills

data-flow-skills 不是普通意义上的知识库，也不是几段 prompt，更不是一堆零散 mock。

它的定义应该更严格一些：

DFS 是围绕某个程序或某条链路构建的、面向 agent 的可执行工程资产。
它使用真实业务中提炼出来的数据、接口契约、状态转换、时序控制和验证规则，
在一个受控环境里压缩真实部署行为，
让 agent 可以稳定地完成理解、调试、改动、验证和回归。

如果说传统文档解决的是“人如何理解系统”，那么 DFS 解决的是“agent 如何在不完整真实系统中仍然可靠工作”。

它的目标不是覆盖整个世界，而是压缩出当前任务真正需要的那一部分世界。