JARVIS 正在变成 AI 研发组织的运行中枢
JARVIS 正在变成 AI 研发组织的运行中枢
我之前写 JARVIS，重点一直放在“记忆”上。
它知道历史 issue，知道模块边界，知道设计决策，知道哪些需求被否决过，知道类似 bug 以前是怎么修的。这个判断没变。我现在还是这么看：没有结构化组织记忆，AI 顶多是个会写代码的高智商实习生。
但最近一个月，我脑子里有个感觉越来越清楚：只把 JARVIS 叫做“知识库”，已经说不准它现在在干的活了。
这不是换方向，只是把前面的想法继续往下做。
不管是我之前写过的《构建软件公司的 JARVIS》和《从 AI 写代码，到 AI 驱动研发：中间差了一个 JARVIS》，还是三周前我单独提炼出来的 GitHub 仓库 hengshi/create-jarvis-skill，主线一直都一样：JARVIS 不是文档堆，不是 repo 生成器，也不是某个 agent 的提示词壳子。它是一层 agent-first 的组织能力层。真正值钱的，也不是一个整理漂亮的 repo，而是一条能跑起来、能回写、能越用越强的业务闭环。
如果说三周前的 create-jarvis-skill 主要在回答“怎么从 0 搭一套 JARVIS”，那最近一个月我在 hengshi-jarvis 上做的事，主要在回答另一件事：JARVIS 真开始干活以后，agent 该怎么进门，在哪块地上干活，先读什么，做到什么程度才算真的做完。
也就是从“怎么建”，往“怎么跑”又推了一大截。
这轮变化先卡在工作面不统一
这轮变化最早暴露出来的问题，不是知识不够，而是工作面先乱了。
当时我本机同时存在 ~/.openclaw/workspace/henglabs、~/.hermes/workspace/henglabs、~/Work/henglabs 三套工作根目录。Hermes、OpenClaw、Claude Code、Cursor 这些 agent 或 IDE 会并行开多个会话做不同任务，结果就是 workspace 不够用，文件互相覆盖，branch 和 dirty state 互相污染。
这件事一下就把问题顶到了台面上：
如果 AI 连该在哪个工作区里干活都不确定，那它知道再多历史知识也没用。
我也是从这里开始更明确地意识到，JARVIS 不能只负责知识索引。它还得把执行入口和工作地面也收进来。
最近一个月最硬的一步：运行时宪法
过去一个月里，JARVIS 最硬的一组更新，不是又多整理了多少知识，而是把运行时边界立成了宪法。
从 git log 往回看，这条线很清楚：
- 2026-04-28：
feat(runtime): formalize canonical ~/.hengshi root - 2026-04-29：
refactor: switch hengshi runtime constitution to per-task clones - 2026-05-09：
docs: require workspace root preflight across workflows - 2026-05-09：
docs: forbid task git mutations on canonical repo anchor
这几条放在一起，意思很直接：
- 所有 HENGSHI 相关 agent，先收口到同一个 canonical runtime root：
~/.hengshi - 真正执行任务时，不再共享一个会互相打架的 checkout，而是切到 per-task clones / task workspace
- 任意 workflow 开始前，都要先做 workspace root preflight，先确认 repo、workspace、checkout kind，再继续行动
- canonical repo anchor 只保留只读职责，不能在上面随便 checkout、merge、stash、cherry-pick
这事听起来很工程，但特别值钱。
以前 JARVIS 更像告诉 agent“你应该知道什么”。现在它还要先告诉 agent“你该站在哪儿干活”。地面没统一，后面全会打架。
这也是我现在特别在意的一点：知识库可以存事实，运行中枢得先把工作地面定下来。
入口先看闭环，再决定第一跳
如果说 runtime constitution 解决的是“在哪工作”，那后面这一段解决的就是“怎么进门”。
这一段的变化也很明显：
- 2026-04-22：
docs(skills): add jarvis repo-routing and closure rules - 2026-04-27：
refactor: reshape jarvis skills around workflows - 2026-04-28：
refactor: clarify skill layer boundaries - 2026-05-09：
docs: refresh repo execution routing
这背后的判断，我现在会说得更直接一点：真实研发任务别急着按 repo 分流，先看它属于哪条闭环。
用户抛过来的东西，可能是一个 bug、一段报错、一个 issue、一张截图、一个 PRD、一个 MR、一个 release 收尾动作。JARVIS 先要判断的，不是哪一个 repo 是 source-of-truth，而是：
- 当前任务属于哪个企业闭环
- 第一跳去哪里能最快拿到 first proof
- 什么时候需要升级到第二跳、第二仓库、第二数据面
- 什么证据出来以后，才算这个闭环真的完成
这已经不是“我这有一套资料，你来搜”的思路了。
这更像任务分诊系统。先分清这是哪类活，再决定第一步去哪。
JARVIS 以前更像资料入口，现在越来越像统一入口。
知识开始直接决定执行顺序
再往下走一步，就是我觉得最近这轮最关键的变化：知识不只是拿来查，已经开始直接决定执行顺序了。
这一组更新包括：
- 2026-04-27：
jarvis: backfill validated facet routing into module entries - 2026-05-07：
docs: add official-website source route - 2026-05-09：
feat(sources): add everest-cli source route - 2026-05-12：
jarvis(skill): add modules routing step to entry skill
以前一说“知识库”，大家很容易脑补成一个静态画面：AI 遇到问题，先搜一搜，再读几段文档，然后开干。
真到研发现场不是这么走的。
真正要先搞清楚的是：
- 这个任务一上来该先读
modules/<module>/overview.md，还是先看sources/<source>/README.md - 现在该先看模块已知问题，还是先看跨模块交互
- 这是一个 repo 内问题，还是已经跨到 official website / everest-cli / docs / ui-test 这些别的数据面
- 哪些知识是补充参考，哪些知识是不读就别开始改代码
像 add modules routing step to entry skill 这种更新，意思其实很直白：先读这份，再动手。
到这一步，知识已经不只是材料了。它开始管顺序，管前置条件，管这一步该不该开工。
这也是为什么我现在不太愿意把 JARVIS 只叫知识库。叫小了。
“完成”现在也有统一判断标准了
AI 系统还有个很常见的问题：它特别会宣布自己完成了。
代码改了，测试跑了，扔一段总结，看上去像 done 了。但真实研发里的 done，从来不是一句话。
最近这轮 JARVIS 更新里，我越来越在意这件事。
从 repo-routing、closure rules，到 completion standard、minimal closure card、writeback judgment，背后其实都在收紧同一个定义：
完成，不是“我产出了东西”，而是“证据已经够了，这个闭环可以收口了”。
这意味着 JARVIS 要回答的，不只是：
- 改了哪些文件
- 跑了哪些命令
- 测试是不是绿了
它还得继续往下追：
- 现在这个任务到底属于哪个闭环
- 这次判断基于哪些证据
- 有没有升级到第二跳 / 第二仓库 / 第二 source
- 最后要不要做 durable writeback
- 这次变化有没有改到组织长期知识
到这一步，JARVIS 已经在管任务到底算不算做完了。
这和普通意义上的知识系统，已经不是一回事。
所以我现在会把 JARVIS 叫成运行中枢
如果把最近一个月这些变化放在一起看，我现在更愿意把 JARVIS 重新讲一遍。
但这个“重新讲”，不是从零改口，是把旧抽象继续往前推。
三周前，在 create-jarvis-skill 里，我已经把 JARVIS 讲成了一个 agent-first 的组织能力层：它要帮助 agent 找到正确上下文、进入正确 repo 或系统、完成真实工作，并把可持续复用的学习写回去。那时我更关心的是建造方法：第一条闭环怎么选，sources / repos / workflows 怎么盘，哪些东西能 scaffold，哪些东西必须靠真实 writeback 长出来。
而最近一个月，我在 hengshi-jarvis 里真正往前推的，是把这套抽象压成跨 agent 的运行规则。说白了，就是以前我更多在定义 JARVIS 应该长什么样，现在我开始定义 agent 进了 JARVIS 之后必须怎么工作。
所以今天再让我下一个更准的定义，我会这么说：JARVIS 已经在管统一入口、知识索引、执行前置、闭环判断和 writeback。
它现在至少在管五件事：
- 这个任务从哪里进入系统
- 这个任务应该在哪个 workspace / runtime 里执行
- 这个任务开始前必须先读哪些知识
- 这个任务做到什么程度才算完成
- 这次结果需不需要回写进组织长期记忆
这五件事一旦都往系统里收，JARVIS 干的就已经不只是存知识了。它已经在接管研发现场的一部分秩序。
这就是我现在会把它叫成运行中枢的原因。
这件事为什么重要
我现在越来越不信，给企业套一个更强的 agent 壳子，这事就能成。
因为企业研发真正复杂的地方，不在模型会不会写代码，而在下面这些东西：
- 组织知识分散
- 工作入口混乱
- workspace 不统一
- source-of-truth 不唯一
- repo 和 workflow 的边界不清楚
- 完成标准靠口头默契
- 经验很难稳定回写
这些东西没被系统化，AI 每一轮都只能临场发挥。偶尔会很惊艳，但很难长期靠谱。
最近这轮 JARVIS 更新最让我确定的一点就是：AI 研发系统的上限，不看你给 agent 塞了多少知识，而看你有没有把知识、工作区、路由、闭环和回写连成一个系统。
而 JARVIS 现在就是在往这个方向收。
结语
所以今天如果再让我定义一次 JARVIS，我不会只把它叫做知识库。
知识库还是它的起点，但已经不够概括它现在干的活了。
最近一个月最重要的变化很实在：入口在收，runtime 在收，preflight 成了前置，第一跳和升级条件在收紧，完成标准和 writeback 也有了统一规则。
JARVIS 已经在往 AI 研发组织的运行中枢走了。
这事才刚开始。
