Harness 之后，公司还是得有自己的 JARVIS

2026-05-13

Harness 之后，公司还是得有自己的 JARVIS

上一篇《JARVIS 正在变成 AI 研发组织的运行中枢》写的是内部变化：最近一个月，JARVIS 具体收进了哪些运行规则。

外面这一波文章和项目，已经把问题推到了很靠前的位置。再往前一步，就会碰到公司内部那层收口。

把 OpenAI、Martin Fowler、LangChain、Mitchell Hashimoto、Tanka、ArcKit，还有最近几篇中文文章放在一起看，轮廓其实已经很清楚了：行业已经走到 harness 这一步了，但公司里最后还得有一层自己的收口。这层东西，还是可以叫 JARVIS。

讨论已经从 prompt 走到 harness 了

这两年 AI 研发的讨论走得很快。

最早大家盯着的是 AI 会不会写代码。Copilot、Cursor、Claude Code，还有各种 coding agent，把写函数、补测试、改样板代码这些事做得越来越顺手。再往前走，问题就变了。任务一长、上下文一多、工具一接、权限一放开，模型另外一面很快就出来了：会忘，会猜，会漂，也会把一句像样的话直接当结论交上来。

所以后面的讨论开始往 harness 收。

OpenAI 在讲 harness engineering。Martin Fowler 在讲怎么把 coding agent 塞进工程系统。LangChain 在拆 agent harness 的运行结构。Mitchell Hashimoto 在写自己怎么把 AI 用进日常开发。中文这边也开始往实处走了，讨论 review、tests、guardrails、context、memory、知识沉淀，还有非确定性怎么被工程系统接住。

这一波变化说明，AI 研发的话题已经从“prompt 写得漂不漂亮”，往“agent 怎么进真实研发”挪了。

Harness 很重要，因为没有这层，agent 根本进不了现场

这一点现在已经很清楚了。

没有 harness，agent 最多帮你补几段代码，回答几个问题。真要长期干活，靠不住。

一个能长期干活的 agent，至少得有这些东西：

  • 明确的运行环境
  • 可用但受控的工具
  • 权限边界
  • review 和测试回路
  • 出错以后能停下来的机制
  • 长任务里的上下文管理

这些东西一补上，agent 才算真的从聊天框里走出来。它能进 repo，读文件，跑命令，改代码，提 PR，拿到反馈后继续往下做。

所以 harness 的价值也很直接：它解决的是 agent 能不能稳定干活。

但真到了公司里，后面还有一层问题会立刻冒出来

问题也就在这里。

就算 harness 已经搭起来了，很多关键判断还是没人替你回答。

比如：

  • 这个模块当年为什么这样设计
  • 这个需求以前为什么被否过
  • 这次修复要补哪条回归点
  • 哪些路径默认别碰
  • 什么情况必须升级给人
  • 谁对最后验收负责
  • 这次处理完以后，哪些经验应该沉回系统

这些都不会随着 harness 一起自动长出来。

公司里真正难的地方，很多时候也不在模型会不会调工具，在默认做法。

同样是一个 bug，不同公司第一步就可能完全不一样。有人先看历史 issue，有人先看线上日志，有人先看最近两次发布改了什么。有人要求先补测试再改代码，有人要求先复现，有人要求先确认是不是老问题重演。有人把某些改动当高风险动作，默认必须升级；有人把某些经验当成口头规矩，一直没写下来。

这些东西要是还在系统外面，agent 最后就只能自己猜。

而“自己猜”刚好是模型最容易翻车的地方。

把这几类材料放在一起看，缺口其实很好认

OpenAI、Fowler、LangChain、Mitchell Hashimoto 这一波内容，核心都在往一个方向推：怎么让 agent 能进工程系统，能持续执行，能被 review，能被约束，出了问题也能被看见。

Tanka 往前提的是 intent、role、memory 这一层。它提醒大家，AI 真进组织以后，不能只被看成一个工具面板。它要接住人的意图，也要接住角色带来的判断差异。

ArcKit 往前提的是另一层：专业知识不一定只待在文档里，也可以被压成 workflow、templates、commands、reviews 这种能反复跑的动作结构。很多团队的问题也确实不在“有没有文档”，而在文档有没有变成默认动作。

中文这边，像《Harness不是目的，知识才是护城河》《Martin Fowler 的 AI 研发提醒：非确定性进了研发链路，Harness 才真正开始承重》《软件工程的功底是智能时代生死攸关的要素》这些文章，也在把问题往实处推。重点已经落到知识沉淀、非确定性、工程基本功这些地方了。

把这些东西拼起来，已经能看出一条很完整的线。但公司内部真要长期跑，后面还差最后一层收口。

因为总得继续回答这些问题：

  • 默认动作到底由谁来写
  • 例外情况怎么处理
  • 历史经验怎么沉下来
  • 这次该停、该升、还是该继续，由谁拍板
  • 哪些判断以后要变成所有 agent 的前置条件

这几件事如果还在系统外面，前面的 harness、knowledge、memory、workflow 都有用，但还没有真正落进这家公司的日常研发里。

这层收口，还是可以叫 JARVIS

这里说的 JARVIS，已经不只是知识库，也不只是一个 agent 外壳。

更关键的是，怎么把组织里已经证明有效的做法，收成 agent 默认会遵守的工作方式。

这里面至少包括这些东西：

  • 任务进来先读什么
  • 哪些历史判断默认生效
  • 哪些地方不要直接动
  • 什么情况要升级给人
  • 这次做到什么程度才能收口
  • 结束以后哪些结果要沉回系统

如果这些东西没有收进去，那就算资料很多，agent 还是只能现查、现拼、现判断。偶尔会做对，偶尔也会像一个刚进组的新同事，字面意思都听懂了，但还是没接上这家公司真正的做法。

放在这条线里看，JARVIS 更像最后那层收口。

harness 解决 agent 怎么稳定跑，Tanka 提醒 intent 和 role，ArcKit 提醒知识怎么压成动作结构，那几篇文章在补工程、知识和治理这几块。JARVIS 要做的是把这些东西接进来，再落到这家公司自己的研发闭环里。怎么进门，先看什么，谁来兜底，什么算 done，做完以后什么要沉回去，最后都得在这层落地。

上一篇写的是最近一个月具体收进了哪些运行规则。这一篇讲的是，为什么这一步绕不过去。

为什么这件事最后还是得公司自己做

我现在越来越确定，AI 研发最后拼的不会只是模型，也不会只是某个通用 harness。

每家公司最难的那部分，长得都不一样。

产品历史不一样。
仓库结构不一样。
工具链不一样。
发布节奏不一样。
团队协作方式不一样。
以前踩过的坑不一样。
默认的验收口径也不一样。

OpenAI 的 harness、Fowler 的框架、Tanka 对 intent 和 role 的处理、ArcKit 的 workflow 和治理结构，都可以拿来参考。

但轮到你们自己团队的时候，最后还是得自己回答：

  • 哪些经验以后默认生效
  • 哪些例外以后默认升级
  • 哪些历史判断以后不能再丢
  • 哪些知识以后必须回写

这些东西没有通用答案，也买不来。

它们只能从这家公司自己的研发过程里长出来。

JARVIS 也不太像一个“装上去就能用”的标准产品。它更像公司把自己研发经验一点点收成系统的过程。外面那些文章和项目能帮你把路看清一点，但最后那层，还是得自己做。

这也是我还会继续把 JARVIS 往下做的原因

把这两篇文章放在一起看，分工已经很清楚了。

上一篇写的是：最近一个月，JARVIS 具体收进了哪些运行规则。

这一篇写的是：为什么这件事不能停在 harness，也不能停在几篇好文章和几个好项目这里。

JARVIS 也不只是一个单独的工具名。

它更像一个位置。前面接得住 harness，接得住 knowledge，接得住 intent，也接得住 workflow。后面要把这些东西都落回公司自己的研发闭环里。agent 一进来，先按这套做法工作。做完以后，再把新的经验沉回去。

这层如果一直没人做，很多 AI 研发讨论最后都会停在一个很尴尬的位置：大家知道方向已经变了，也知道工程系统得补强，但到了公司内部，最后还是靠几个人脑子里的经验在兜底。

继续把 JARVIS 往下做，补的也是这一层。

扩展阅读

如果你想先看行业这一步已经走到哪，可以先看这些：

如果你想继续看知识、组织和治理这条线，也可以看这些：

© 2026 Memories - Powered by Hexo