AI原生研发｜Jarvis和Harness的双剑合璧

最近 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」列表收录了几十个相关资源。这绝非偶然。Agent Coding 已经从只会写单个函数进化到全天开发完整功能。业内慢慢看清制约 Agent 落地的不是大模型性能而是配套运行环境。Agent 的瓶颈不是模型能力而是模型运行的环境。Harness Engineering 提炼出了通用落地范式部分思路与衡石此前 JARVIS 项目的研发方向重合但二者仍存在本质区别。本文将梳理二者的共性与核心差异。一、Harness Engineering 究竟是什么Harness 这个词最早来自 Anthropic 对 Claude Code 的工程实践。它的核心含义是Agent Model Harness模型提供推理能力Harness 提供一切让推理能落地的环境。具体来说Harness Engineering 关注的是1. Context Engineering上下文工程怎么管理 agent 的上下文窗口。不是”塞得越多越好”而是把上下文当作工作记忆预算来管理。Manus 团队讲的 KV-cache 局部性、工具屏蔽、文件系统记忆Anthropic 讲的 context condensationOpenHands 讲的 bounded conversation memory——都是在解决同一个问题agent 跑久了上下文会失控。2. Constraints Guardrails约束与护栏怎么让 agent 自主但不失控。沙箱、权限策略、审批节点、工具边界。Anthropic 讲的 sandboxing、MCP 执行控制HumanLayer 讲的 12 Factor AgentsThoughtworks 讲的 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 三层时态架构组织的产品知识库History5.7 万个 issue 的分类索引、18 个模块的深度文档、635 条 MR 修复摘要、7311 条被否决需求、60 条破坏性变更、跨模块依赖矩阵Present当前 backlog 快照、版本计划、团队配置FutureAI 对 backlog 的去重检测、优先级分析、排期推荐它解决的核心问题是当 AI agent 面对一个 bug 时它不只是看当前代码——它能够追溯至 3 年前这个模块的设计原理总结类似 bug 过往修复方案 了解哪些方案已经被否决。由此我们简要总结 JARVIS它关心的是 agent 有多少知识沉淀。三、本质差异运行环境层 VS 长期记忆层现在区别相对清晰。我们具体举例如果 Harness Engineering 给 agent 提供了标准化手术室灯光、器械、监控设备、安全规程都到位。JARVIS 则是让上手术台的 agent 拥有十年临床经验它知道病人病史知道过往手术失败原因知道药物禁忌。完善的手术室不可或缺但缺乏临床经验的医师即便身处优良环境仍易出现重大失误。反之经验丰富的医生在简陋的条件下也能救治但给他配备完善的手术室他能做得更好。由此可见 JARVIS 和 Harness Engineering 的关系它们各司其职且相辅相成。四、Harness Engineering 体系现存短板梳理 awesome-harness-engineering 相关资源可以发现其定义的 Memory 仅针对ContextMemory Working State、ConstraintsGuardrails Safe Autonomy、SpecsAgent Files Workflow Design、Evals Observability 、Benchmarks 和 RuntimesHarnesses Reference Implementations。其中 Context, Memory Working State看似和 JARVIS 能力相似但细分落地内容不难发现差异Anthropic 聚焦上下文窗口优化、节约 Token 开销Manus 依托 KV 缓存局部性提升缓存效率OpenHands 通过会话压缩留存关键信息HumanLayer 侧重规避上下文漂移问题。这些方案都围绕运行时的记忆展开只能管控单次任务周期内的短期记忆。而产品长期沉淀的组织记忆并未纳入 Harness 体系例如模块原始设计逻辑、同类故障历史修复方案、过往废弃技术路线、功能测试短板、代码改动带来的跨模块联动风险等内容这类知识不在上下文窗口里不在 AGENTS.md 里不在任何 harness 组件里。Harness Engineering 的”Memory”是工作记忆Working Memory类比计算机 RAM。JARVIS 的”Memory”是承载的是沉淀全生命周期信息Long-term Memory更像是硬盘。二者缺一不可但技术定位完全不同。五、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 的搭配是这样运作的我们用一个典型案例说明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 生态发展趋势我们可以大胆预测这个体系会在 2026-2027 年被标准化。Context Engineering、Evals、Guardrails 这些东西会变成基础设施就像 CI/CD 在 2015 年被标准化一样。但是组织记忆不会被标准化。各企业产品形态、迭代历程、设计思路与过往问题存在差异化特征通用 Harness 框架可以跨企业复用但 JARVIS 这类记忆体系无法通用。Harness 相关能力可依托 SWE-agent、AgentKit 等开源产品直接采购落地而企业专属的记忆层只能自主搭建。JARVIS 并非标准化商用产品本质上是企业独有的组织能力他的核心价值不在于开发技术而是企业对自身业务的沉淀理解组织记忆的结构化沉淀深度直接决定 AI 智能体能力上限。八、落地建议针对正在尝试 AI 深度参与研发的团队衡石总结出以下建议先做 Harness再做 JARVIS。Harness 的投入产出比更直接写好 AGENTS.md、配好沙箱、接好测试、设好审批节点。这些是低垂的果实能立刻提升 coding agent 的可靠性。Harness 完成后启动组织记忆建设从 issue 系统开始导出历史 issue做模块分类提取高频 bug 模式和被否决需求。你会发现光是”让 AI 知道哪些方案之前被否决过”就能省掉大量重复讨论。同时进行时关注两层体系的连接记忆层和运行层的连接是最容易出问题的地方知识路由是否准确上下文预算是否合理知识回写是否有质量保障这些”接缝”决定了系统的实际效果。结语Harness Engineering 的爆火绝非偶然。它标志着行业从”模型军备竞赛”转向”工程基建竞赛”。工程基建解决智能体可靠运行的问题但无法定义执行目标与决策依据这个部分能力恰好由 JARVIS 补齐。JARVIS 并非 Harness 的替代方案而是上层支撑体系Harness 保障智能体稳定执行JARVIS 保障智能体决策方向准确。一套成熟的 AI 研发体系两层架构缺一不可。