夜雨聆风从Prompt Engineering到Harness Engineering，开发者需要学会用配置文件管理AI行为，让AI在你设定的边界内工作。
最近看了一篇论文，《Harness Engineering for Agentic AI Coding Tools: An Exploratory Study》
论文中数据显示，作者团队在对经过挑选的 2853 个工业级GitHub代码仓库扫描发现：
85.5% 的 Skills 配置是空壳（定义了但从没执行过）
493 个仓库只用 AGENTS.md，不用任何工具特定配置
这难道说Skills是鸡肋吗？还是说除AGENTS.md之外，CLAUDE.md、GEMINI.md都不好用？
从提示词到驾驭工程：三次进化
2025年之前大家玩的是 Prompt Engineering。写提示词。跟AI说话的艺术。你得琢磨怎么措辞，怎么给上下文，怎么让它吐出你想要的东西。这阶段的核心问题是，你每次都要从头教它。
后来升级了，叫Context Engineering。设计上下文。不只是单次对话了，而是把项目的架构文档、代码规范、历史决策全塞进去，让AI有背景知识。这一步很关键，因为它让AI从"路人"变成了"项目组新人"。
但还是不够。
现在进化到第三阶段。Harness Engineering。驾驭工程。什么意思？就是把AI塞进一个框架里。告诉它什么能做，什么不能做。怎么找文件，怎么跑测试。出了错怎么兜底。不是每次对话都要重复，而是写一次配置，永久生效。
这三个阶段的进化逻辑其实很清晰。Prompt解决的是"怎么跟AI说话"。Context解决的是"让AI知道什么"。Harness解决的是"让AI怎么行动"。
从说话，到知道，到行动。一层比一层深。
Agent和Tool的本质区别
要理解Harness Engineering，先得搞清楚两个概念。Agent和Tool。
这俩看起来都是"AI帮你干活"，但本质完全不同。
Tool是边界功能。一个确定性的能力。你调一次，它执行一次，结束。比如跑一个Shell命令，读一个文件，调一个API。输入输出明确，没有自主性。
Agent是目标驱动的。你告诉它一个目标，它自己拆解步骤，选择工具，执行，调整，再执行。这是一个自主循环。它会自己决定下一步干什么。
关键区别在哪？Agent是自主的。Tool是被动的。
所以你需要配置Agent。告诉它边界在哪。什么能做，什么不能做。而Tool不需要这些，因为它本身就有明确的边界。
这就是为什么"写提示词"不够用了。提示词是单次指令。Agent需要的是持续的行为规范。你不能每次都跟它说"别删数据库"，你得把这个规则写进配置文件，让它每次启动都自动加载。
八大配置机制拆解
论文扫描了主流的Agentic编码工具后，总结出8种配置机制。我挑几个最关键的讲。
Context Files，上下文文件。这是最基础的，也是目前用得最多的。AGENTS.md、CLAUDE.md、GEMINI.md，这些文件告诉AI项目的架构是什么、怎么构建、怎么测试、代码规范是什么。相当于给AI写一份项目说明书。78.3%的配置仓库里都有这类文件。
Skills，技能包。这是一个文件夹。里面有SKILL.md，告诉AI这个技能怎么触发、怎么执行。还有scripts目录放可执行脚本，references目录放参考文档。比如你有一个代码审查流程，打包成一个Skill，以后每次审查AI就知道怎么做。
Subagents，子智能体。高级玩法。主Agent可以派出多个子Agent，每个有自己的上下文和工具，并行执行互不干扰。比如主Agent在写代码，同时派一个子Agent去跑测试，再派一个去审查文档。
Hooks，生命周期钩子。在特定时刻自动触发。代码提交前跑lint，测试通过后自动部署，文件修改后触发通知。让AI的行为可预测、可审计、可追溯。
MCP Servers，模型上下文协议。解决AI怎么访问外部数据的问题。比如 数据库、API、GitHub，这些系统不在代码库里，但AI需要它们。MCP定义了一个标准协议，让AI安全地连接外部系统。
这8个机制，从最简单的"写个说明书"到最复杂的"连接外部系统"，覆盖了AI行为管理的方方面面。但现实是，大多数人只用了第一个。
AGENTS.md：开发者用脚投票选出的标准
最有趣的发现来了。
论文做了一个时间线分析。发现CLAUDE.md通常先出现，因为Claude Code是最早提供配置能力的工具。然后开发者会加一个AGENTS.md。为什么？因为AGENTS.md是通用的。不管你换什么工具，它都能读。
更有意思的是，有493个仓库，只用AGENTS.md。不用任何工具特定配置。没有厂商绑定，没有工具锁定。
这是什么？这是自下而上的标准化。不是大厂推的，不是委员会定的，是开发者用脚投票选出来的。
论文还做了一个文件引用网络分析。在所有配置文件的互相引用中，CLAUDE.md指向AGENTS.md的次数高达301次。AGENTS.md成了配置生态中唯一的超级核心节点。
这就像当年README.md成为项目标配一样。没人规定你必须写README，但所有人都写了。AGENTS.md正在走同样的路。
高级特性的集体荒废
现在说一个残酷的事实。
论文扫描了2853个仓库后发现，85.5%的Skills只有SKILL.md这一个文件。没有scripts，没有references，没有assets。就是一段自然语言描述，定义了但从没执行过。
这意味着什么？绝大多数开发者写Skill的方式，就是在用自然语言向AI"念魔法"。告诉它你应该做什么，但没有给它真正的工具去做。
Subagents的持久记忆功能，零采用。没有仓库在用。Hooks和MCP，几乎无人问津。
为什么？因为配置成本太高。写一个SKILL.md很简单，打开编辑器写几段话就行。但写一个带脚本、带引用、带资源的完整技能，需要真正的工程投入。大多数人选择了最简单的路。
这就像你买了一台全功能的咖啡机，但每天只用它烧热水。不是机器不行，是你没把功能开发出来。
三大工具的配置风格分化
最后看三大工具的配置哲学。
Claude Code最复杂。八种机制全覆盖。Context Files、Skills、Subagents、Commands、Rules、Settings、Hooks、MCP，全都有。用户也用得最多，占45.2%。它的设计理念是，给你全套武器，你自己选怎么组合。
Cursor不一样。它强调Rules和Commands。.cursorrules文件是它的标志。你写一套规则，AI照着做。简洁，但上限也低。你没法像Claude Code那样精细控制每一个环节。
Copilot最简单。几乎只用Context Files。很少扩展到其他机制。它的定位是"代码补全增强版"，而不是"自主Agent"。所以配置需求也最低。
三种工具，三种风格，三种生态。选哪个，取决于你需要多深的控制。如果你只是要一个聪明的自动补全，Copilot够了。如果你要一个能自主跑任务的Agent，你得学会Claude Code那套完整的配置体系。
三步上手：从今天开始写你的AGENTS.md
说了这么多，到底怎么开始？
别想着一步到位把八大机制全配齐。那是给自己挖坑。论文的数据已经告诉我们了，大多数人连一个完整的Skill都写不出来，你上来就想搞全套，大概率三天后放弃。
就三步。
第一步，写一个AGENTS.md。
不需要完美。不需要覆盖所有机制。打开编辑器，写下四件事：你的项目是什么，怎么构建，怎么测试，代码规范是什么。就这些。把它放在项目根目录，提交到Git。
这一步花不了你20分钟。但效果立竿见影。因为AI终于知道你的项目是什么了。它不再是一个拿着锤子到处找钉子的陌生人，而是一个读过项目说明书的新同事。
如果你同时在用Claude Code和Cursor，让它们读同一个AGENTS.md。别维护两份配置。论文的数据说了，维护过多的专属配置文件容易导致上下文冗余和逻辑冲突。一份共享的AGENTS.md，就是多工具协作的最佳实践。
第二步，把你的Bug变成测试用例。
这是最容易被忽略但价值最高的一步。
你发现AI写出来的登录接口在密码输入特殊字符时崩溃了。别手动改代码。在测试文件里加一行断言，校验特殊字符的处理。然后把这个用例喂回给Agent。
只要它改完代码没有跑通这个新用例，流水线就自动打回。这样历史Bug不会反复复发。每次你修一个Bug，就多一道防线。久而久之，你的测试用例就是你的质量护城河。
别去搞什么高大上的自动化测试框架。先把最常见的三个Bug变成三个测试用例，这就够了。
第三步，把重复性工作流打包成Skill。
如果你每周都要做一次代码审查，每次都跟AI说同样的话，那就把这些话写成一个SKILL.md。审查标准放references里，审查脚本放scripts里。以后每次审查，一个命令搞定。
这就是从"每次都要念魔法"到"写一次长久生效"最务实的做法。
论文里85.5%的Skill是空壳，只有文档没有脚本。你要做的就是成为那14.5%。不需要写得多复杂，哪怕只有一个可执行的shell脚本，也比纯文字说明强十倍。
说到底，Harness Engineering不是什么高深的技术活儿。它就是把你脑子里对AI想说的那些个话，翻译成机器能读的配置文件。你已经在做了，只是没意识到而已。
从今天开始，给你的项目写一个AGENTS.md。迈出这一步，你会发现AI的输出质量立刻不一样了。
因为它终于知道你的项目是什么了。
👇欢迎加入智能体老王的AI群，共同探讨AI话题和技术
👇文章不错的话，记得关注，点赞，谢谢
