JARVIS 与 Harness Engineering：AI 研发的记忆层和运行层

2026-03-31

JARVIS 与 Harness Engineering：AI 研发的记忆层和运行层

最近 Harness Engineering 突然火了。

OpenAI 发了 Harness engineering: leveraging Codex in an agent-first world，Anthropic 发了 Effective harnesses for long-running agents，LangChain 发了 The Anatomy of an Agent Harness，Martin Fowler / Thoughtworks 也写了 Harness Engineering。GitHub 上甚至出现了一个 awesome-harness-engineering 列表，收录了几十个相关资源。

这不是偶然的。当 coding agent 从”写个函数”进化到”跑一整天帮你做 feature”，工程界终于意识到了一件事：

Agent 的瓶颈不是模型能力，而是模型运行的环境。

我读完这些材料后，一个强烈的感受是：Harness Engineering 正在把我过去几个月在 JARVIS 上做的事情中的一部分，抽象成了一个通用范式。但只是一部分。

JARVIS 和 Harness Engineering 之间，既有重叠，也有根本性的差异。这篇文章想把这件事说清楚。

Harness Engineering 到底在说什么

先说清概念。

Harness 这个词，最早来自 Anthropic 对 Claude Code 的工程实践。它的核心含义是：

Agent = Model + Harness

模型提供推理能力，Harness 提供一切让推理能落地的环境。

具体来说，Harness Engineering 关注的是：

1. Context Engineering（上下文工程）

怎么管理 agent 的上下文窗口。不是”塞得越多越好”，而是把上下文当作工作记忆预算来管理。Manus 团队讲的 KV-cache 局部性、工具屏蔽、文件系统记忆；Anthropic 讲的 context condensation；OpenHands 讲的 bounded conversation memory——都是在解决同一个问题：agent 跑久了，上下文会失控。

2. Constraints & Guardrails（约束与护栏）

怎么让 agent 自主但不失控。沙箱、权限策略、审批节点、工具边界。Anthropic 讲的 sandboxing、MCP 执行控制；HumanLayer 讲的 12 Factor Agents；Thoughtworks 讲的 quality check in the loop——都是在回答：自动化的边界在哪？

3. Specs & Agent Files（规约与指令文件）

AGENTS.md、CLAUDE.md、agent.md——这些 repo-local 的指令文件告诉 agent”在这个仓库里怎么工作”。GitHub 的 Spec Kit 更进一步，把 spec-driven development 变成标准流程。

4. Evals & Observability（评估与可观测性）

怎么知道 agent 做得好不好。不只是看最终结果，还要 trace 整个过程。OpenAI 的 eval skills、Anthropic 的 trace grading、LangChain 的 multi-turn eval——agent 越自主，你越需要可观测性。

5. Runtime & Orchestration（运行时与编排）

Agent 的生命周期管理：启动、暂停、恢复、多 agent 协调。LangChain 的 deepagents、Inngest 的 AgentKit、SWE-agent 的执行环境。

如果用一句话总结 Harness Engineering：

它关心的是 agent 怎么跑。

JARVIS 在说什么

我之前写过两篇关于 JARVIS 的文章：《构建软件公司的 JARVIS》讲方法论框架，《从 AI 写代码到 AI 驱动研发》讲为什么 coding agent 不等于研发系统。

核心论点不重复了，只提最关键的一条：

JARVIS 关心的不是 agent 怎么跑，而是 agent 跑的时候脑子里有什么。

具体来说，JARVIS 是一个按 History / Present / Future 三层时态架构组织的产品知识库：

History：5.7 万个 issue 的分类索引、18 个模块的深度文档、635+ 条 MR 修复摘要、7311 条被否决需求、60+ 条破坏性变更、跨模块依赖矩阵
Present：当前 backlog 快照、版本计划、团队配置
Future：AI 对 backlog 的去重检测、优先级分析、排期推荐

它解决的核心问题是：当 AI agent 面对一个 bug 时，它不只是看当前代码——它知道这个模块 3 年前为什么这样设计，知道类似的 bug 之前怎么修的，知道哪些方案已经被否决过。

用一句话总结 JARVIS：

它关心的是 agent 知道什么。

本质区别：运行层 vs 记忆层

现在区别就很清晰了。

维度	Harness Engineering	JARVIS
核心问题	Agent 怎么跑	Agent 知道什么
关注点	上下文管理、约束、评估、编排、运行时	组织记忆、产品知识、历史决策、已知模式
时间跨度	单次任务 ~ 单次会话	产品全生命周期（年）
数据来源	当前代码、当前任务、当前对话	历史 issue、设计文档、MR 记录、被否决需求
知识形态	指令文件（AGENTS.md）、工具定义、Prompt	结构化知识库（模块文档、索引、交叉引用）
更新频率	随 repo 变化	随每次 bug 修复、设计决策、版本发布
通用 vs 专有	通用范式，适用于所有 agent	公司/产品专有，不可迁移

打一个比方：

Harness Engineering 是给 agent 搭一个好的手术室——灯光、器械、监控设备、安全规程都到位。

JARVIS 是让上手术台的 agent 拥有十年临床经验——知道这个病人的病史，知道上次手术为什么失败，知道哪些药有禁忌。

手术室很重要。但一个没有临床经验的医生，在再好的手术室里也可能犯致命错误。

反过来，一个经验丰富的老医生，在简陋的条件下也能救命——但如果给他一个好的手术室，他能做得更好。

这就是 JARVIS 和 Harness Engineering 的关系：它们解决不同层的问题，且互相增强。

Harness Engineering 里缺失的那一块

读完 awesome-harness-engineering 的全部资源后，我注意到一个有趣的缺口。

这个列表有六大分类：

Context, Memory & Working State
Constraints, Guardrails & Safe Autonomy
Specs, Agent Files & Workflow Design
Evals & Observability
Benchmarks
Runtimes, Harnesses & Reference Implementations

第一类”Context, Memory & Working State”听起来最接近 JARVIS 做的事。但仔细看内容：

Anthropic 讲的是上下文窗口管理——怎么不浪费 token
Manus 讲的是KV-cache 局部性——怎么让缓存命中率更高
OpenHands 讲的是会话压缩——怎么在长对话里不丢关键信息
HumanLayer 讲的是上下文漂移——怎么让 agent 不跑偏

这些全是运行时记忆——agent 在一次执行过程中怎么管理自己的短期记忆。

但组织记忆呢？

这个模块为什么这样设计？
上次类似的 bug 是怎么修的？
哪些方案被否决过？
这个功能的测试覆盖盲区在哪？
修了这里会影响哪些其他模块？

这类知识不在上下文窗口里，不在 AGENTS.md 里，不在任何 harness 组件里。

Harness Engineering 的”Memory”是工作记忆（Working Memory），JARVIS 的”Memory”是长期记忆（Long-term Memory）。

一个是 RAM，一个是硬盘。两个都需要，但它们不是同一个东西。

JARVIS 本身也需要 Harness

反过来说，JARVIS 光有知识库也不够。

在实际操作中，JARVIS 的知识库需要被 agent 有效调用。这里面涉及的问题恰恰就是 Harness Engineering 关心的：

上下文预算分配

JARVIS 有 18 个模块、每个模块有 overview、known-issues、decisions、test-coverage、faq。如果 agent 接到一个 charts 模块的 bug，不能把 18 个模块的文档全塞进上下文——需要智能路由。这是 Context Engineering 的问题。

工具边界设计

Agent 应该能搜索 JARVIS、能更新 JARVIS，但不应该在没有人工审批的情况下删除或覆盖关键知识。这是 Guardrails 的问题。

知识更新的评估

Agent 从一次 bug 修复中提炼出的 known-issue 条目，质量怎么样？有没有幻觉？这是 Evals 的问题。

多 agent 协调

一个 agent 在修 bug，另一个在更新知识库，还有一个在跑回归测试。它们之间怎么协调？这是 Orchestration 的问题。

所以：

JARVIS 提供了 agent 需要的知识，Harness Engineering 提供了 agent 使用这些知识的可靠方式。

搭配组合：一个实践方案

在我的实际工作中，JARVIS + Harness 的搭配是这样运作的：

┌─────────────────────────────────────────────────┐
│                 AI 研发中枢 (JARVIS)               │
│                                                   │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐       │
│  │ History  │  │ Present  │  │ Future   │       │
│  │ 历史知识  │  │ 当前状态  │  │ AI 判断  │       │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘       │
│       │              │              │             │
│       └──────────────┼──────────────┘             │
│                      │                            │
│              ┌───────▼───────┐                    │
│              │  Knowledge    │                    │
│              │  Router       │ ← Context Eng.     │
│              └───────┬───────┘                    │
└──────────────────────┼────────────────────────────┘
                       │
┌──────────────────────┼────────────────────────────┐
│              Agent Harness                         │
│                      │                            │
│  ┌──────────┐  ┌─────▼─────┐  ┌──────────┐       │
│  │Guardrails│  │  Agent    │  │  Evals   │       │
│  │ 约束护栏  │  │  Runtime  │  │ 评估追踪  │       │
│  └──────────┘  └─────┬─────┘  └──────────┘       │
│                      │                            │
│  ┌──────────┐  ┌─────▼─────┐  ┌──────────┐       │
│  │  Tools   │  │Orchestr.  │  │ Sandbox  │       │
│  │ 工具接口  │  │ 任务编排   │  │ 安全沙箱  │       │
│  └──────────┘  └───────────┘  └──────────┘       │
└───────────────────────────────────────────────────┘

一个典型的 bug 修复流程：

Issue 进入 → Harness 接收任务，分配给 agent
知识路由 → JARVIS 根据 issue 内容匹配模块，推送相关的 overview、known-issues、decisions
上下文组装 → Harness 的 Context Engineering 决定推多少知识进上下文（预算管理）
方案生成 → Agent 基于知识库生成修复方案
约束检查 → Harness 的 Guardrails 检查方案是否触及已知风险（JARVIS 的 cross-module interactions）
代码实现 → Agent 写代码
测试验证 → Harness 运行测试，对比 JARVIS 的 test-coverage 确认覆盖
知识回写 → 修复完成后，agent 更新 JARVIS 的 known-issues 和 fix-knowledge
评估记录 → Harness 的 Evals 记录整个过程的质量指标

每一步都同时需要 JARVIS 和 Harness。缺了任何一层，系统都不完整。

对行业的一个预测

读完 Harness Engineering 的整个生态后，我有一个判断：

Harness Engineering 会在 2026-2027 年被标准化。Context Engineering、Evals、Guardrails 这些东西会变成基础设施，就像 CI/CD 在 2015 年被标准化一样。

但是：

组织记忆不会被标准化。

因为每家公司的产品不同、历史不同、设计决策不同、踩过的坑不同。你可以用同一套 Harness 框架，但你不能用同一套 JARVIS。

这意味着：

Harness Engineering 会变成开源工具和平台（已经在发生了——SWE-agent、AgentKit、deepagents）
但每家公司的”记忆层”必须自己建

Harness 是买得到的。记忆是买不到的。

这也是为什么我说 JARVIS 不是一个产品，而是一种组织能力。它的价值不在于技术实现（技术并不复杂），而在于你对自己产品的理解深度——你能把多少年的组织记忆结构化，就决定了你的 AI 能有多强。

给实践者的建议

如果你正在尝试让 AI 更深度地参与研发，我的建议是：

如果你还没开始

先做 Harness，再做 JARVIS。

Harness 的投入产出比更直接：写好 AGENTS.md、配好沙箱、接好测试、设好审批节点。这些是低垂的果实，能立刻提升 coding agent 的可靠性。

如果 Harness 已经做好了

开始建记忆层。

从 issue 系统开始：导出历史 issue，做模块分类，提取高频 bug 模式和被否决需求。你会发现，光是”让 AI 知道哪些方案之前被否决过”，就能省掉大量重复讨论。

如果两者都在做

关注连接点。

记忆层和运行层的连接是最容易出问题的地方：知识路由是否准确？上下文预算是否合理？知识回写是否有质量保障？这些”接缝”决定了系统的实际效果。

结语

Harness Engineering 的火不是偶然。它标志着行业从”模型军备竞赛”转向”工程基建竞赛”。

但我想补充一点：

工程基建解决的是”怎么跑”的问题。而”跑向哪里”和”基于什么判断”，需要另一层东西。

JARVIS 就是那另一层。

它不是 Harness 的替代品，而是 Harness 的上游。Harness 让 agent 跑得稳，JARVIS 让 agent 跑得对。

一个跑得稳但不知道该干什么的 agent，只是一个高效的随机游走器。

一个知道该干什么但跑不稳的 agent，只是一个有想法但手抖的外科医生。

你两个都需要。

前两篇文章：《构建软件公司的 JARVIS》 | 《从 AI 写代码到 AI 驱动研发》

本文提到的 Harness Engineering 资源汇总：awesome-harness-engineering

作者： Thomas Chan
日期： 2026-03-31
标签： JARVIS, Harness Engineering, AI Agent, Context Engineering, Software R&D

Memories

JARVIS 与 Harness Engineering：AI 研发的记忆层和运行层

JARVIS 与 Harness Engineering：AI 研发的记忆层和运行层

Harness Engineering 到底在说什么

1. Context Engineering（上下文工程）

2. Constraints & Guardrails（约束与护栏）

3. Specs & Agent Files（规约与指令文件）

4. Evals & Observability（评估与可观测性）

5. Runtime & Orchestration（运行时与编排）

JARVIS 在说什么

本质区别：运行层 vs 记忆层

Harness Engineering 里缺失的那一块

JARVIS 本身也需要 Harness

上下文预算分配

工具边界设计

知识更新的评估

多 agent 协调

搭配组合：一个实践方案

对行业的一个预测

给实践者的建议

如果你还没开始

如果 Harness 已经做好了

如果两者都在做

结语