我为什么要做 Harness Engineering
先把话说直
我现在最想长期投入的方向，是 Harness Engineering。
这里的 harness，不是一个漂亮的新名词。它指的是 AI Agent 真正跑起来时外面那一整套工程框架：它能调用哪些工具、不能碰什么；它跨会话怎么保留记忆；多个 agent 怎么协作；它做完一件事之后，系统怎么知道它真的做对了，而不是只是看起来像做对了。
模型会继续变强，写代码、查资料、生成方案都会越来越便宜。越是这样，越不能把自己的价值押在「我会让模型多输出一点东西」上。真正值得押的是另一件事：我能不能把模型放进一个可靠的工作系统里。
这就是我理解的 Harness Engineering。
我的起点不是研究员，是工程师
我的主栈是 Vue 3 / TypeScript，也在往 Next.js / NestJS 全栈延伸。过去很长一段时间，我的价值主要体现在实现能力上：把需求拆开、把界面做出来、把接口接通、把系统跑起来。
但 AI 辅助编码之后，这条路的天花板在变矮。不是前端不重要了，而是「会写」本身越来越不稀缺。Agent 能帮我写大量代码，甚至能并行做多个分支任务。这个变化逼我重新问自己：三年后，我到底靠什么和别人拉开差距？
我的答案不是去追更大的平台叙事，也不是一头扎进模型训练。那两条路都不是我当前手里的最佳牌。
我更适合从工程系统入手：把一个模糊的 agent 协作问题拆成边界、协议、记忆、验证、工具合约这些可落地的模块，然后用真实项目一点点验证。
四个真实项目，分别验证一层
这个 blog 里的文章不是随手写的观点集合，它们背后对应的是我正在做或已经做过的实验。
Nestwork 验证的是记忆和协作协议。
我用 Git 给多台机器、多个 agent 同步同一套规则、策略和记忆。每个 agent 有自己的目录，人类维护只读的治理层，共享记忆通过 distillation 汇总。它不是为了炫技，而是在解决一个具体问题：agent 不能只靠一场对话活着，它需要跨机器、跨会话的上下文真相源。
A2A mesh 验证的是实时互调的数据面。
Git mailbox 适合慢速交接，但不适合秒级调用。于是我把多台机器上的 agent 通过 A2A 和 worker-pull 连起来。真正的难点不是协议本身，而是 NAT、常驻、安全和结果回填。跑通之后，我更清楚地意识到：连通性只是入场券，下一层必须是验证面。
cheat-on-content 验证的是校准回路。
内容创作看起来和 agent 无关，但底层问题一样：面对一个黑箱系统，不能靠事后解释安慰自己，而要提前预测、锁死预测、回收数据、复盘偏差、迭代 rubric。它是「可验证性」在内容领域的落地。
Duovid 验证的是小工具产品纪律。
它不是宏大的 AI 平台，而是一个很具体的问题：一次拍摄，同时产出横版和竖版。这个项目提醒我，独立开发不该总是被平台化诱惑带走。小而可验证的工具，反而更容易检验真实需求。
真正的主线：给智能体装边界和痛觉
把这些项目放在一起看，主线其实很清楚：
- Nestwork 解决「agent 怎么记住和交接」；
- A2A mesh 解决「agent 怎么跨机器实时互调」；
- cheat-on-content 解决「不确定系统怎么校准」；
- Duovid 解决「一个工具型产品怎么克制地验证价值」。
它们看起来分散，但都在服务同一个目标：让我从「会用 agent」往「会设计 agent 系统」走。
其中最关键的一层，是验证。
没有验证的 agent 系统很危险。它可以跑很久、产出很多、看起来很忙，但它错了自己不知道。人盯着的时候还能兜底；agent 数量变多、运行时间拉长之后，人就会变成瓶颈。系统必须自己有痛觉：每个任务带可机器判定的验收契约，结果能回看，错了能触发修正。
这也是我接下来最想补的短板。
这个 blog 应该怎么读
如果你想看我的方向判断，先读这篇，再读《从前端到 Harness Engineering》。
如果你想看具体项目，读 Nestwork、A2A mesh、cheat-on-content 和 Duovid。
如果你想看我对 AI 时代程序员能力的判断，读能力阶梯、CS 基础和人类相对 AI 的净优势。
这不是一个已经完成的答案集。它更像一个公开的工程日志：我把判断写下来，用项目去验证，然后等现实打脸。打脸不是问题，没有记录、没有校准、没有下一步，才是问题。
Harness Engineering 对我来说也不是一个头衔，而是一条练习路线：少讲空泛的 AI 感想，多做能跑、能验、能复盘的系统。