这一组文章原本可以写成一篇长文，但那样会把最重要的判断埋掉。

LLM Harness 更像一条链路，从“模型为什么不稳定”一路走到“工程系统怎样托住它”。每一环都能单独展开，也都必须接到下一环。裸模型的随机性解释了为什么需要边界；上下文换入换出解释了为什么长程任务需要外部状态；环境可供性解释了为什么工具和数据入口会改变智能水平；Spec 和测试解释了边界怎样被写成工程资产；Agent Teams 解释了注意力怎样被隔离和降维；软件入口高阶化解释了这一切最终会改变什么。

flowchart LR
    A[裸模型: 概率分布] --> B[上下文: 工作集管理]
    B --> C[环境: 取到正确数据]
    C --> D[Spec / Test: 可验证边界]
    D --> E[Agent Teams: 注意力降维]
    E --> F[软件入口: Agent 化]
    D --> G[Harness: 控制系统]
    B --> G
    C --> G
    E --> G

先从抽卡感开始

《裸模型为什么像抽卡》讨论的是使用者最先感受到的东西：模型输出不是一个稳定点，而是一段分布。

同一个任务，有时一次过，有时绕很久。偶尔抽到高分结果，会让人误以为再试一轮就能解决问题；低分结果又常常看起来“差一点就好了”。这种反馈结构很容易把 AI coding 变成变量奖励循环。

它给整个系列定底层假设：不要把裸模型当确定性函数使用。工程上要解决的不是每一次采样都完美，而是把采样结果接进停止规则、验证规则和回滚规则。

长程任务靠 context paging

《上下文换入换出：下一代 scaling》把问题从一次采样推进到长程任务。

人的注意力和模型的上下文窗口都有边界。不同的是，模型的 context refill 是读写问题，人类的 context refill 是注意力损耗问题。把所有历史不断塞回窗口，不只贵，还会把旧错误、旧假设和旧噪声一起带回来。

Compact 的价值不在于给聊天续命，而在于清场：丢弃已经完成的任务，留下未完成目标、当前状态、关键约束、下一步动作和验证方式。新任务开启时，Agent 应该从外部重新取数，而不是把历史对话当唯一信息源。

这篇文章给 Harness 补上供料系统：有限上下文要靠遗忘、压缩、检索、索引和外部状态接成连续工作边界。

智能的一半在环境里

《环境可供性：智能的一半是取到正确数据》讨论的是另一个常被低估的维度：模型不仅要能处理信息，还要能拿到正确的信息。

在模型不能主动取数的时候，增强它只能靠提示词工程：把更多背景、更多约束、更多示例塞进 prompt。模型有工具之后，问题变成环境设计：文档是否可检索，代码是否可定位，日志是否可查询，测试是否能跑，外部系统是否能被安全调用。

这解释了 Context7、MCP、repo map、代码搜索、语言服务器、测试框架和日志系统为什么重要。它们把真实世界改造成模型可观察、可调用、可验证的环境。

当主动取数能力变强以后，基本材料也不该默认常驻上下文。更合理的形态是入口常驻、材料外置、片段按需加载。Skill 的渐进式加载只是一个例子；同样的思路也适用于 SOP、文档、日志、测试输出和项目记忆。

Harness 的中心是边界

《Harness 的本质：把随机模型锁进可验证的箱体》是这一组文章的中心。

Harness 的本质不是“提示词写得更好”，而是把概率模型放进一个可验证的工作系统里。Spec 给出目标和非目标，测试给出验收边界，工具承担确定性执行，循环把有限上下文接起来，hook 和权限把不能交给模型自由选择的动作固定下来。

SDD 在这里的位置很清楚。它把文档推进为任务早期的小系统：目标、边界、计划、验收、回滚和非目标。后续实现是在这个小系统上延长，避免每一轮都重新从自然语言愿望里猜方向。

难点也在这里：到底多大的任务需要多少 spec 密度。一个函数可能一句话足够，一个 CRM 系统不可能靠一句话稳定生成。系统性问题需要系统性约束，很多函数组成的系统要由很多句话、很多结构化关系和很多验证规则来驱动模型。

Agent Teams 是注意力降维

《Agent Teams 为什么有效》把 Harness 的一个子问题单独拆出来：为什么多 Agent 有时有效。

关键在注意力隔离，不在“更多人格更聪明”。复杂任务会把单个上下文拉向多个方向；计划、实现、验证、研究、审查全挤在一个窗口里，模型很容易在不同维度之间来回摆动。阶段拆分和模块拆分都是降维：每一轮只让模型面对一个小世界。

这也解释了多 Agent 的边界。任务能拆、信息能隔离、合并规则清楚，多 Agent 就有价值；任务强依赖同一份连续上下文，或者合并者没有足够能力，多 Agent 只会制造更贵的信息损耗。

软件不会消失，入口会变

《AI 不会吞掉软件，只会吞掉入口》是这一组文章的宏观收束。

模型不适合替代所有确定性软件。计算器、数据库、编译器、浏览器、PDF 库、CI、权限系统、CAD 和专业业务系统都会继续存在。变化发生在入口层：人不再直接学习每个软件的按钮、菜单和 API，而是把意图交给一个能读文本、能调工具、能接工作流、能接受验证的 Agent。

这让 AI 更像新一代胶水语言。不同的是，过去的胶水语言连接 API 和脚本，Agent 入口连接的是意图、上下文、工具、权限、日志和验证。

和旧文的关系

这组六篇短文不替代旧文。它们给旧文补了一条更紧的概念骨架。

旧的 《Harness Engineering 完整指南》和 《Harness Engineering：长程 Agent 的工程化底座》更像工程手册，讲 Prompt / Context / Harness 的层级跃迁、长程 Agent 的失败模式和落地清单。新文只抓本质：概率模型进入工程世界，需要边界、供料、验证和循环。

《智能体记忆全景综述》讲四层记忆、文件系统回归、外部记忆生命周期；context paging 那篇把这些机制压成一个操作系统比喻。

《SDD 与超级个体》和 《OpenSpec 实战指南》讲流程和落地；Harness 本质篇回答为什么 spec 是边界，而不是仪式。

《Multi-Agent 架构深度解析》和 《子 Agent 的本质》讲定义、拓扑和通信成本；Agent Teams 那篇只保留一个中心判断：多 Agent 先是上下文隔离，再是团队协作。

《Context7 MCP Server 深度解析》和 《Coding Agent 代码检索技术全景》讲具体取数工具；环境可供性那篇把它们放回同一个问题：智能水平也取决于取数水平。

这一组文章的读法

如果只读一篇，读 Harness 本质篇。它是中心。

如果在 AI coding 里感到累，先读抽卡篇和上下文换入换出篇。它们解释为什么“再试一次”会把人烧干，也解释为什么 compact 不应该是无限续命。

如果在做工具、MCP、检索或知识库，读环境可供性篇。它把工具设计从“功能扩展”提升到“智能边界扩展”。

如果在搭多 Agent 或团队式编排，读 Agent Teams 篇，再回到 Multi-Agent 架构深度解析看通信成本。

如果在判断 AI 会不会替代软件，读软件入口篇。它给出的答案更冷静：软件本体不会消失，入口会被 Agent 改写。

收束

这一组文章最终指向同一个结论：LLM 的能力不是单独存在的。它总是在一个上下文、环境、工具、权限、验证和循环构成的系统里表现出来。

裸模型决定能力分布的底座。Harness 决定这段分布怎样被压缩、筛选、验证和延长。

未来一段时间，真正有价值的 AI 工程不会只问“哪个模型更强”，也会问另一组问题：上下文怎样换入换出，环境怎样让正确数据可见，spec 怎样定义边界，测试怎样拒绝低分尾部，Agent 怎样拆分注意力，软件怎样把入口暴露给高阶智能。

这就是 LLM Harness 的路线图。