我的判断：你怎么知道自己的 Harness 是不是在工作？
前五篇讲了五套 Harness 实践，但没有一篇回答过最基础的问题：你怎么知道自己的 Harness 是不是在工作？20 年企业 IT 经验提炼出的六个判断，以及衡量任何 Harness 的三个核心问题。
RAFA · 2026.03.25
Harness系列： AI早知道 · 第六篇（终篇）
前五篇花了大量篇幅讲了五套 harness 实践——Anthropic 的 Generator-Evaluator，OpenAI 的 Knowledge as Code，Mario 的极简透明，Karpathy 的 LOOP FOREVER，Garry Tan 的明确认知档位。
这五套实践我都认真读了、部分复现了。它们是真实的、有价值的工程实践。
但它们有一个共同的盲区：没有一篇回答过这个最基础的问题——你怎么知道自己的 harness，是不是在工作？
不是"你的 harness 是不是足够好"——那个问题永远没有标准答案。而是更具体的：当你的 agent 系统出问题的时候，你多快知道？你能不能追溯发生了什么？同样的错误，下次还会发生吗？
我在企业 IT 里待了 20 年，横跨系统集成、云计算、AI 落地三个阶段。这 20 年里我学到最有用的一件事是：一套系统的可靠性，最终体现在它的故障响应速度上。不是在系统工作正常的时候，是在它出错的时候。
一个好的 harness，不是保证 agent 不犯错——而是保证当 agent 犯错时，你第一时间知道，你能追溯原因，你能阻止同样的事再发生。
这是我用来衡量任何 harness 设计的三个问题，也是这篇文章的主线。
六个判断
判断一：agent 输出不稳定，根源通常不是模型
这是独立开发者最常犯的认知错误：当 agent 表现不稳定时，第一反应是换模型、改 prompt、升级工具。
我在做 Talk-with-Buffett 的时候踩过这个坑。产品是一个巴菲特风格的对话 AI，用户问投资问题，agent 检索巴菲特的历史言论，生成符合他风格的回答。有一段时间回答质量飘忽不定——有时候出色，有时候答非所问。我的第一直觉是模型的问题。
但问题不在模型。问题在于：agent 没有办法知道自己的回答是否成功。
它完成了检索，生成了一段文字，但它不知道这段文字有没有准确地召回相关内容，不知道有没有忠实地代表巴菲特的立场，不知道用户得到的答案是否真的有用。没有反馈，它只能依赖统计规律——有时候规律对上了，有时候没有。
这不是模型能力问题，是反馈回路缺失的问题。
当你的 agent 输出不稳定，在换任何东西之前，先问一个问题：agent 有没有一种方式知道它是否做对了？ 如果答案是否，你遇到的是 harness 设计问题，不是模型问题。
判断二：可见性不是工具给你的，是你给自己的
前五篇里最让我印象深刻的是 Mario 的一句话："你以为你在做 context engineering，但你连 context 里有什么都不知道。"
这不只是针对 MCP 工具的批评，是一个更普遍的问题：大多数开发者对自己 agent 系统的实际状态，掌握的信息远少于他们以为的。
一个实用的自检方法：不要问"我的 harness 设计得好不好"，而是问两个具体的问题——
- 我能不能告诉你，三个 session 之前 agent 做了什么决策，为什么？
- 如果 agent 刚才犯了一个错误，我多快能知道，从哪里看？
如果这两个问题你答不上来，你的 harness 里有盲区。盲区不是会出错的地方，是出错了你不知道的地方。
可见性不是通过安装更多工具获得的——更多工具往往意味着更多你不了解的行为在 context 里发生。可见性是通过减法得到的：去掉你追溯不了的工具，去掉你看不见的 sub-agent，去掉任何让你失去追溯能力的组件。剩下的，才是你真正能掌控的 harness。
判断三：凡是输出质量依赖"品味"，evaluator 就无法被机械化
前五篇里的 evaluator 案例，有一个共同点：评估标准是相对明确的。
Karpathy 的 autoresearch 用 val_bpb——一个数字，好坏一目了然。Anthropic 的 Playwright 测试——按钮能不能点，功能有没有跑通。OpenAI 的 CI linter——代码符不符合架构规范。这些 evaluator 之所以能嵌进 harness 自动运行，是因为"什么叫成功"有一个可以机械判断的答案。
但我做过的三个产品，全部撞上了同一堵墙。
Talk-with-Buffett：用户问"巴菲特怎么看英伟达的估值"，一个好的回答需要准确召回相关内容、正确理解问题意图、用巴菲特的逻辑框架而不是通用 LLM 的腔调来作答。这三件事没有一个能被机械地自动化。
judge-the-code：AI 写代码的速度远超人工，但判断一段代码写得好不好，taste 还是来自人。你可以自动化"能不能跑"、"有没有语法错误"，但"这个抽象合不合适"、"这个命名有没有传达意图"——这些判断，模型做不到一致且可靠，人也很难把标准完全编码化。
publish-md-to-wechat：样式和排版可以规则化，但"这篇文章读起来对不对"的审美判断，还是得人来过一遍。style 的最终裁量权在人，不在 harness。
这三个产品告诉我一件事：evaluator 的机械化边界，划在了"品味"这里。 能被量化的，可以自动化；依赖审美判断的，目前还不行。
你能做的是：在 harness 里设计人工检验节点，把"什么叫好的输出"写成人能快速判断的标准，用抽样而不是全量来维持质量感知。这不是最优解，是目前诚实的解。
任何声称"输出质量已经完全自动化评估"的方案，都值得追问：你的 evaluator 真的覆盖了品味判断，还是只覆盖了可量化的部分？
判断四：独立开发者的核心 harness 约束是注意力，选组件要选最底层的 primitive
Anthropic 的 harness 可以让两个研究工程师花几周时间设计。OpenAI 可以有一个团队专门维护 AGENTS.md 和 linter 规则。
独立开发者没有这些。你在用 AI 写代码的同时，还在做产品设计、用户运营、市场推广。你不可能把大量时间花在维护 harness 本身上。这意味着：你的 harness 越复杂，维护它消耗的注意力就越多，直到有一天你发现自己在维护工具而不是在做产品。
从这个约束里可以推出一个具体的组件选择原则：选最接近操作系统的 primitive，不要选应用层的抽象。
最直接的例子是定时任务。OpenClaw 生态里有各种应用层的调度工具，也有更"智能"的触发机制。我自己用下来的结论：cron job 最稳定。 操作系统级别的唤醒，不依赖应用层的状态，不受 agent 框架的生命周期影响，出了问题你知道去哪里看日志。应用层调度器能给你更多功能，也给你更多你看不见的失败点。
这个原则适用于 harness 里的所有组件选择：文件比数据库可靠（agent 可读，人也可读，不需要连接），cron 比调度框架可靠，shell 脚本比应用层封装可靠。每一层抽象都是一个你需要理解和维护的故障域。独立开发者的注意力预算，支撑不了太多故障域。
判断五：记忆是 harness 里目前还没有解的问题
前五篇里讲了很多记忆方案：MEMORY.md 的热记忆、Micro Sync 的暖记忆、第二大脑的冷检索。理论上很完整。实际上，目前没有一个方案是真正工作良好的。
我在 OpenClaw 上用过内置的 memory 机制，用过各种插件，配置过 tobi/qmd 作为记忆管理方案。每一套都有问题：内置机制的记忆质量不稳定，重要的忘，不重要的记；插件生态碎片化，互相不兼容；QMD 配置复杂，在长任务里 context 管理还是会漂移。
Supermemory 宣称解决了跨 session 记忆问题。我现在不确定。
这不是某一个工具的问题，是结构性的难题：大模型没有持久记忆，每个 session 从零开始。所有现有的记忆方案，本质上都是在用外部存储模拟持久记忆，然后在 session 开始时用某种策略把相关记忆注入 context。这个模拟过程有根本性的局限——你永远在做取舍：注入太多，context 被挤占；注入太少，agent 失忆。
目前诚实的状态是：记忆问题是 harness 工程里最难、进展最慢的部分。 如果有人告诉你他完全解决了 agent 的跨 session 记忆，问他具体怎么做的，大概率是在某个维度上做了妥协但没有说出来。
对独立开发者来说，当前最务实的做法是：接受记忆是不完美的，用最简单的方案（MEMORY.md + 手动维护）建立基线，花时间在记忆维护上，而不是花时间寻找完美工具。完美工具还没出现。
判断六：企业 harness 的终态，是 skill 成为业务 SOP 的载体
我在系统集成时代见过企业 ERP 上线；在云计算时代见过企业"搬迁上云"；现在在 AI 时代见企业"引入 agent"。
这三次技术引入，失败案例惊人地相似：工具到位了，但组织的知识没有准备好被工具使用。ERP 上线之后，系统里的流程和实际运作的流程是两套；云上线之后，机房管理经验没有人翻译成云运维规范；agent 上线之后，核心业务知识还是在老员工的脑子里、群聊的置顶消息里、没有人整理的 Excel 里。
知识没有转移，工具就只能在系统边缘打转。 这是每次技术浪潮最常见、也最不被承认的失败原因。
但Uber 案例给了我另一种看法——它让我意识到，企业 harness 有一个比"知识显性化"更具体的终态：skill 会成为企业未来业务流程和 SOP 的真正载体。
Uber 的工程团队没有自上而下地设计 skill 体系。一个工程师在没有立项、没有审批的情况下，建了一个仓库，放了两个 skill（CI 日志分类、代码审查）。五个月后，这个仓库变成了 500+ skill 的生态系统，覆盖从需求研究到生产监控的整个开发生命周期。
这里有两个值得拆开看的结构：
第一，skill 开发需要自下而上。 员工最了解自己的业务场景，最知道哪个流程值得 skill 化，哪个不值得。强制自上而下地设计 skill，会造出精致但没人用的脚手架。让员工自己开发 skill，才能覆盖真实的业务痛点。
第二，skill 的治理需要自上而下。 Uber 的做法是两层并行：黄金市场（核心 skill 严格质量门控，输出必须可预期）+ 个人市场（自由实验，容错率高）。质量门控、可观测性、合规审计、skill 的上线和下线机制——这些不是某个工程师能单独解决的，需要企业级的基础设施。
这对中国企业意味着什么？在讨论"引入什么 AI 工具"之前，先问：我们有没有机制让员工把业务 SOP 转化成 skill，同时有治理框架保证这些 skill 的质量和合规性？ 没有这两样，再好的 AI 工具都只是在边缘打转。
中国企业的知识比硅谷团队更隐性——核销流程在钉钉群置顶消息里，排产规则在老工人脑子里，客户关系在个人微信里。这意味着 skill 化的前置工作更重，但 skill 一旦建立，对组织知识的沉淀价值也更大。这是一个以年为单位的工程，但方向是对的。
这个系列写到这里，我想说最后一件事。
前五篇展示的案例——Anthropic 的研究团队、OpenAI 的百万行实验、Mario 的极简哲学、Karpathy 的实验室、Garry Tan 的工程师团队——都是在非常好的条件下做出来的工程实践。
你的条件很可能不一样。你可能是一个人，在业余时间，用一台 Mac Mini，在做一个还没有多少用户的产品。
这没有问题。harness 不要求完美的条件，它要求的是诚实——对你的 agent 在做什么诚实，对你的工具在 context 里注入了什么诚实，对你的 evaluator 是否真的在工作诚实。
从诚实开始，harness 自然会生长。
Harness 早知道系列完结。