在 AI Coding 链路里，模型只是冰山一角。真正决定 agent 能不能交付生产代码的， 是它周围的 Harness —— 工具、上下文、子代理、评估、权限、记忆。 下一代 Coding 团队的差距，不在模型层，而在 Harness 工程。
一句话：Harness 是把模型变成 agent 的所有非模型组件。 它决定了模型"能不能干活"、"干得好不好"、"干得安不安全"。
Harness 本意是"马具"——把马的力传导到车上。没有 harness，马就是马； 有了 harness，马才能拉车。LLM 本身只是"会说话的马"， Harness 才是让它真正干活的那套传动系统。
在 AI Coding 语境里，Harness 包括工具调用、上下文组装、子代理调度、
权限沙箱、记忆持久化、评估反馈、用户界面、等等。
不管是 Claude Code、Codex CLI、Gemini CLI 还是 Cursor Composer， 头部 harness 都在围绕这六个维度内卷。这是 2026 年的主战场。
Harness 给模型装上"手脚"：文件读写、终端执行、grep 搜索、git 操作、网络请求。 工具不是越多越好——好的 harness 提供少量、原子、组合性强的工具。
怎么把对的代码、对的规范、对的历史塞进有限的窗口。 从 Prompt Engineering 进化到 Context Engineering——管理整个上下文图谱， 包括 rules、memory、@-files、动态加载。
一个父代理负责拆解任务，分发给"搜索代理"、"编辑代理"、"测试代理"、"审查代理"。 每个子代理有独立上下文、独立工具集、独立目标。 这是从"单体 agent"走向"agent 团队"的关键。
在工具调用前后插入自动化检查：pre-tool 校验权限、post-tool 跑 lint、 stop 时跑测试。Hooks 让 harness 变成一个 "每一步都被验证"的系统，而不是信任模型的输出。
哪些操作需要确认？哪些文件不能动？哪些命令要拦？ Harness 必须给模型划定可操作边界——既不能太严（agent 啥都做不了）， 也不能太松（agent rm -rf 整个仓库）。
先出方案、再动手。Plan Mode 让用户先看到 agent 的计划、确认或修改， 然后进入执行。这把"决策权"和"操作权"分离—— agent 提出方案，人来做最终判断。
用户输入一句话后，harness 里发生了什么？下面是从输入到落盘的完整执行路径。
CLI / IDE / Web 输入 + 当前会话历史 + 工作目录环境变量。最朴素的一层，但决定了起始上下文。
"重构 src/auth 目录，把 JWT 改成 RS256"
加载 CLAUDE.md、项目 .claude/rules、相关 @files、近期会话摘要。控制 token 预算，决定"哪些进窗口"。
system_prompt + rules + files + history ≈ 60K tokens
模型推理 → 拆成子任务（先调研、再设计、再实现、再测试）→ 进入 Plan Mode 让用户确认。不确认不执行。
TaskList: [explore src/auth, design RS256 schema, implement, write tests]
父代理分发任务给子代理（独立上下文），或直接调用工具。每一步都有 PreToolUse hook 校验。
subagent: Explore(src/auth) → subagent: Coder(plan) → Bash(npm test)
PostToolUse 跑 lint/format，Stop 跑测试套件。结果回灌到下一轮推理，形成闭环。
PostToolUse(Edit) → bash lint.sh → result: 3 warnings
把这次会话的结论（"我们项目用 RS256 JWT"）写入 user/project memory。下次新会话自动加载。
memory.user: "项目偏好：JWT 用 RS256、TS strict、测试覆盖率 ≥80%"
AI Coding 的演进，本质是 Harness 的演进。 模型能力是地基，harness 才是上层建筑。下面是已经走过和正在走的四步。
Harness 的雏形：光标位置 + 上下文窗口 → 模型 → 补全建议。几乎没有"系统"，就是 IDE 插件。
Harness 开始成形：侧边栏对话 + 文件引用 + Apply 按钮。模型能读懂项目，局部重构成为可能。
Harness 完整化：完整 Bash 权限 + 子代理 + Plan Mode + Hooks + Skills。整个仓库变成 agent 的工作面。
Harness 走向团队：多个 agent 长期协作，每个专精一项（PM / Architect / Coder / Reviewer / Tester）。人类监督而非执行。
Harness 工程没有银弹。下面九个问题，是当下所有 harness 团队都在反复撞墙的地方。 理解它们的难度，比"再加一个 tool"重要得多。
塞进窗口的内容越多，模型表现反而越差。噪声淹没了信号。重要的规范、文件位置、历史决策被堆在大量无关内容里，模型开始忽略关键约束。
模型不知道自己写的代码对不对。它可以"看起来合理"，但缺一个边界条件、改错一个变量名、漏一个并发问题。没人测 = 不能上生产。
长任务跑了几十步后，agent 开始"忘了最初的目标"。它可能在解决一个不再存在的问题，或者追求一个"看起来对"但偏离原意的子目标。
工具越多，模型越不会选。100 个工具时，agent 经常调错工具、忽略关键工具、把工具拼起来用错。工具设计的组合性 vs 表达力是核心权衡。
子代理编排 + 长会话 + 多轮反思 = token 爆炸。一个简单任务可能消耗 100K+ tokens。多 agent 不是"越多越强"，而是"调度越精越省"。
太严 → agent 啥都做不了；太松 → agent 一行 rm -rf 干废仓库。人类被频繁的"是否允许"打断时，会直接"全部允许"，等于裸奔。
怎么衡量 harness 的好坏？SWE-bench 测的是"模型 + 一次性 prompt"，而 harness 是"模型 + 工具 + 上下文 + 编排"。评估 harness 比评估模型难一个数量级。
工具结果里塞恶意指令（来自网页、用户输入、第三方文件），模型可能被骗。harness 必须假定"所有外部内容都是不可信输入"，而非上下文。
agent 跑到一半崩溃了、用户换了设备、网络断了几小时。怎么从断点恢复？纯靠日志回放既慢又贵，需要结构化的会话状态。
Harness 工程最大的敌人是"把模型当全部"。 下面是过去一年踩过的坑里出现频率最高的五条经验。
模型决定了 AI Coding 的上限，
Harness 决定了 AI Coding 的下限。
真正交付生产代码的，是把两者捏在一起的那套工程。
— Harness Engineering Notes · 2026