1.
在人人都完全可以只靠自然语言就能轻易捏制软件的当下，偶尔还是可以在时间线上看到「学不动了」、「学晚了就不用学了」这样的调侃。明明所有事情都让 Agent 来做了，作为末端的消费者，究竟还要学什么？难道还要学习说话吗？
调侃本身针对的是层出不穷的 AI 新词：它们大部分是旧酒新瓶式的噱头，比如 Agentic ，Agent OS；一部分属于无需在意坐等模型/应用内化即可，比如 Prompt Engineering；一部分纯粹只是新的应用名称，还能不会安装吗？一部分属于知道就等于学会 (反正也是让 AI 调用)，比如 MCP，Skill；还有一些看似装神弄鬼但反而具备一定的指导思想，比如 Harness …
2.
我认为 Harness 是一个比较糟糕的词，它用了一个需要多转一道弯的类比来命名一套工程实践，在我看来完全可以叫做 AI Control System 或者 Agent Runtime Environment 云云 (x)。
以至于作为一个普通的 Coding Agents 用户，第一反应是：究竟为什么要把这种工程词汇暴露给我？
当然实际上稍微了解一下也不难理解，这个东西是一种通用的工程范式，并非只针对 Agentic 项目本身的开发流程。
就跟大部分人一样，AI 不管不行。学问就体现在怎么搭建这个管控环境。
3.
除了那些沉迷于一句话生成一个 App 的用户，大部分人在常规的工作流程中都能自然而然生长出类似的方法论。
比如你会先尝试与 AI 沟通需求并反复强调先别动手，或者让 AI 写完需求文档后再另起一篇规划文档，外加一份可执行的 Todo / 验收标准 List，这些经验事实上就是在践行朴素版 Harness 了。
略往前一点，所谓的 Context Engineering 和 Spec-driven 也是一样的套路。这么看来 Harness 这个词在吸睛效果上确实有一套。
4.
再学究一点，拆开来看看，Harness 是怎么达成所谓系统性的：
- Context - AI 应该知道什么？
AGENTS.md保持简明，随后续结构化的项目文档让 AI 自主迭代。文档的版本要可回溯，每次决策变化都尽量记录下来。 - Capability - AI 可以用什么工具？
客户端内建工具(对我来说) 基本够用，再往前一步，就是把常用的外部服务都包成简单的动作，然后在文档里说清：在什么场景下可以用，失败了怎么降级。 - Constraint - 不许 AI 做什么？
危险的事情靠物理封死：沙箱环境 + Git 回滚，剩下的靠规则和检查拦：文档里写清楚「绝对不能动」的区域，CI、Lint 负责盯代码，出了界就报警。 - Process - AI 怎么来执行任务？
给不同任务设计标准化的模版：复杂任务要求先写 Plan 再动手；UI 相关的先把状态、交互说明白；Bug 修复必须先复现，再定位原因、最后才是改代码… - Verification - AI 做完后怎么算数？
还是文档、指标、CI、Lint、验收报告，以及让别个 Agent 交叉验证… 不过作为设计师，所有的视觉产物我仍然习惯手动验证 (毕竟也不能不做)。 - De-entropy - AI 做完后怎么不让项目变乱？
业务复杂度上去后，代码、文档和工具清单都无法避免膨胀，周期性按上述步骤做一些重构、减重任务。 - Memory - 经验如何沉淀？
加固上述手段：补文档、Checklist、Lint rule、Issue template…
总结一句话：能写清楚的写清楚，能自动检查的自动检查，能沉淀的沉淀，保持可观测性，尽最大可能剔除 AI 临场发挥的可能性。
并且所有这些事情也必须都是由 AI 来做。
5.
虽然说得天花乱坠，个人的很多项目的复杂度远没有达到完全践行这套系统的必要性，Demo 跑通已经功德圆满。
所以开头的调侃也能理解，一个原本用于解决复杂场景的实践，传播时变成了所有人都应该立刻学习的焦虑。
6.
报一些菜名作为备忘，知道了就是学会了：
Context engineering：Prompt engineering 装 X 版，核心是给 AI 塞资料时悠着点。Eval：出卷子测 AI，看它到底变聪明了，还是只是更会装了。State management：记住「我是谁、我在哪、我刚才干了什么」，人类靠脑子，AI 靠这个，都不太可靠。Workflow：把 AI 要做的事排好顺序，然后祈祷它别走岔。Hook：输出前拦一下、调工具前审一下、任务完成后记一下，程序员的老朋友，现在 AI 也得被钩住。Sandbox：AI 的安全屋，在里面随便折腾，出不去就行。Human in the loop：在 AI 流水线里塞个人类审批节点，假装还在掌控全局。Agent：让 AI 从回答问题进化到主动惹麻烦。ReAct：让 AI 边想边做、边做边想，然后把草稿也叫做高级推理范式。Multi-agent：多找几个 AI 干活，然后花更多时间协调它们。Parallel agent：Multi-agent 的装 X 版，强调大家是「同时」在干活，还假装自己发明了多线程。Orchestrator：全场最自恋的角色，自己不干活，专门指挥别人。Tool calling：让 AI 从只会说话进化到会按按钮。MCP：AI 拓展坞，让工具都用差不多的接口接进来。Skill：给 AI 写的岗位 SOP，本质是格式化小抄，叫 Skill 显得高级。System prompt：AI 的入职培训文件，写得好是规范，写得烂是诅咒。Context window：AI 的工作桌面，摊满了就开始丢三落四，和人类开会一样。Chain of thought：让 AI 把草稿也写出来，结果发现草稿比答案更有用。Structured output：求 AI 别写小作文，给我 JSON，谢谢。Streaming：AI 打字给你看，去掉它你会以为它死了。Grounding：把 AI 按在真实资料上回答，防止它张嘴就来。RAG：已退化成「让 AI 查资料再回答」这件朴素常识。Embedding：把文字翻译成一串数字，让语义相近的内容在数字空间中彼此靠近。Vector database：专门存「意思」的数据库，因为普通数据库不知道什么叫「像」。
6.
作为普通消费者的一些观点和暴论：
- 从今往后 (非基建贡献者) 所有能学的、能做的事情，无一例外都属于 Harness 的一部分 (当然也是因为这个词过于宽泛)。
- 工程师学
Harness是在补设计课，设计师学Harness是在补工程课。 - 但说到底其实也不用学，AI 都懂，直接问，直接做。
Harness未来大概率分两条路线，作为客户端内化的能力和作为开箱即用的可配置的外部框架。- 项目的质量等同于 Agent-readable 程度。
- 不需要花心思研究 AI 生成设计，设计将只会作为草稿来辅助思考和服务于汇报和沟通 (Short FIG)。
- 能做真的就不需要做假的，实际上真实产品的实现成本已经低到足以让任何人直接做真的。
- (对我来说) 最大的瓶颈还是 Token 太贵了。
向 GPT / Claude 直接提问获取 AI 圈层内影响力最大的几篇关于 Harness 的文章并假装是 Ref：