开源模型 + OpenCode：企业内网 Coding Agent 的破局之路

2025 年底到 2026 年初这几个月，开源大模型在编码能力上发生了一件大事：集体追平了前沿闭源模型。

这话放在半年前说，多少有点 PPT 味。但现在，MiniMax M2.5 在 SWE-bench Verified 上打出了 80.2% 的成绩——逼近了 Claude Opus 4.6 的 80.8%，差距只剩 0.6 个百分点。GLM-5 拿到 77.8%，Kimi K2.5 拿到 76.8%。这不是某一家的突然开窍，而是整个开源模型生态在编码能力上的系统性突破。

对我们来说，这件事的意义非常具体：在企业内网工作，安全合规的原因让外网模型用不了，想买 Claude Opus 和 Sonnet 也只能在个人设备上跑。如果开源模型真的追上来了，那「OpenCode + 自部署开源模型」就不再是退而求其次的方案，而是一条可以认真走的路。

但这篇文章想做的不只是拆解数据。模型追上来了只是起点，更深的问题是：当模型强到一定程度，开发者和 AI 的关系本身会发生什么变化？ 我们先从数据说起。

一、先摆数据：2026 年初编码模型能力全景

直接上硬指标。SWE-bench Verified 是目前 Coding Agent 领域最被认可的基准测试，考的是模型在真实 GitHub Issue 上的端到端修 bug 能力。

厂商自报分数（各家最优脚手架）

标准化对比（mini-SWE-agent v2，同一脚手架）

厂商自报分数存在脚手架差异，SWE-bench 官方的 mini-SWE-agent v2 提供了苹果对苹果的标准化对比：

⚠️ 注意：这两张表的分数差异不代表”谁在造假”。厂商自报分数使用了各家优化过的 Agent 脚手架（系统提示、工具链、重试策略等），而 mini-SWE-agent v2 用一套标准化的 100 行 Python 脚本去跑所有模型。差距恰恰说明了一个关键事实：脚手架工程（Harness Engineering）能显著放大模型的有效输出——这也是后文的核心论点。

⚠️ 关于数据与真实体感的差距：需要强调的是，无论是厂商自报还是标准化对比，SWE-bench 测的都是「标准化场景下的修 bug 能力」。真实的日常使用体感往往比这些数字暗示的更有差距——你的项目结构不标准、需求描述不精确、工具链有自定义配置，这些都会放大模型之间的差异。开头说的「0.6 个百分点差距」是 benchmark 层面的事实，但不要把它等同于「体感也只差 0.6%」。这个差距在日常使用中可能被放大到 10-30%，具体取决于你的项目复杂度和脚手架工程的成熟度——这也是为什么后文花大量篇幅讨论 Harness Engineering。

几个关键信息：

1. MiniMax M2.5 的性价比令人惊叹。 在标准化测试中得分 75.80%（并列第二），但平均成本仅 $0.07——是 Opus 4.6 的 1/8。这对成本敏感的企业内网部署来说意义重大。
2. GLM-5 综合能力最全面。 Terminal-Bench 2.0 拿到 56.2%（开源最高），MCP-Atlas 67.8%（全场第二），τ²-Bench 工具调用 89.7%（第三）。做 Agent 不只看写代码——工具调用、终端操作、MCP 协议支持都得行，GLM-5 在这几项上都拿到了第一梯队的成绩。
3. Qwen3-Coder-Next 是「轻量级之王」。 80B 总参数但只有 3B 激活参数，用 SWE-Agent 脚手架就能在 SWE-bench Verified 上超过 70%。这意味着一张消费级显卡就能跑，对资源受限的内网部署来说，这是最现实的选择。
4. 闭源前沿的天花板：Opus 4.6 vs Gemini 3.1 Pro。 两者在 SWE-bench Verified 上几乎打平（80.8% vs 80.6%），但使用体感不同：Opus 4.6 在长链推理和架构规划上更稳，Gemini 3.1 Pro 在速度和多模态上更强。对企业内网来说，更关键的是——开源模型和它们的差距已经小于脚手架工程能弥补的差距。

二、不只是分数：这些模型的「Agent 底座」能力

SWE-bench 分数高是必要条件，但做 Coding Agent 还需要几个关键能力。逐个看：

1. 工具调用（Function Calling / Tool Use）

Agent 的核心循环是「思考 → 调用工具 → 观察结果 → 继续」。模型的工具调用能力直接决定了 Agent 能不能用。

• GLM-5：τ²-Bench 89.7%（第三名），MCP-Atlas 67.8%（第二名）。这两个测的都是工具调用的准确性和协议遵循度。GLM-5 已经明确支持 MCP 协议，官方发布了 AutoClaw（澳龙）——一个开源的 OpenClaw 客户端，内置 50+ 技能。
• MiniMax M2.5：BFCL 多轮对话函数调用 76.8 分，在所有模型中排名领先。Lightning Attention 架构支持原生 100 万 token 上下文，这在处理大型代码库时优势明显。
• Kimi K2.5：支持 Agent Swarm（多智能体协作），月之暗面还专门发布了 Kimi Code——一个对标 Claude Code 的开源编码工具。
• Qwen 3.5：官方定位就是「Native Multimodal Agent Model」，明确支持与 OpenCode、Claude Code、Cline、OpenClaw 集成。

2. 长上下文处理

写代码不是改一行的事。Agent 需要读取整个文件、理解项目结构、跨文件修改。上下文窗口小，Agent 就是瞎子。

• GLM-5：200K input / 128K output
• MiniMax M2.5：原生 100 万 token（Lightning Attention 的 7:1 线性-softmax 混合注意力）
• Kimi K2.5：256K token 上下文窗口，继承 Kimi 系列一贯的长上下文优势
• Qwen 3.5：默认 262K token 上下文，可扩展至 100 万 token

对比 Claude Opus 4.6 的 200K 上下文和 Gemini 3.1 Pro 的 100 万 token，这些开源模型全部达标，MiniMax 甚至与 Gemini 3.1 Pro 持平。

3. 非 NVIDIA 芯片支持

企业内网的 GPU 可能是华为昇腾、寒武纪，不一定有 NVIDIA。这是个很现实的问题。

• GLM-5：明确支持华为昇腾等国产芯片部署，这是智谱作为清华系公司的天然优势。
• Qwen 系列：阿里通义千问，对国产算力适配最积极。
• DeepSeek：社区已有昇腾适配方案。

三、OpenCode 为什么是企业内网的合理选择

先说结论：在「企业内网 + 开源模型」这个约束条件下，OpenCode 是目前能把整条链路跑通的 Coding Agent 框架。

原因很简单——模型无关性。

Claude Code 当然是好工具——它的 Agent Loop 设计、工具系统、Hooks 机制都是业界标杆。但它的核心假设是「你能连上 Anthropic 的 API」。在企业内网，这个假设不成立。

OpenCode 的设计哲学不同：它从第一天就是模型无关的。你把 GLM-5 的 API 地址填进配置文件，它就能跑。换成 Qwen 3.5、MiniMax M2.5、DeepSeek V3.2，改一行配置就行。这种灵活性在模型迭代如此快的今天，是巨大的优势——你不会被绑死在任何一家。

OpenCode 的 Agent 架构为什么适合开源模型

OpenCode 的 Agent Loop 和 Claude Code 共享同一套核心范式：

用户指令 → LLM 思考 → 选择工具 → 执行 → 观察结果 → 继续/完成

这个循环对模型的要求是：

1. 指令遵循：能准确理解系统提示和工具定义
2. 工具调用格式：能按 JSON Schema 格式正确调用函数
3. 多轮推理：能在多次工具调用之间保持上下文一致性

2026 年初的开源模型在这三项上都已达标。GLM-5 的 MCP-Atlas 67.8% 和 τ²-Bench 89.7% 就是最直接的证据——这说明它不仅能调用工具，还能在复杂的多轮工具链中保持准确性。

四、实战选型：不同场景用什么模型

说了这么多，落地的时候到底选哪个？我的判断：

场景一：资源充足，追求最强性能

首选：MiniMax M2.5

SWE-bench 80.2%，编码能力直接对标 Opus 4.6。230B 参数需要较大的算力，但如果在企业内部有专用 GPU 集群（A100/H100 或同等国产算力），这是最不需要妥协的选择。Lightning Attention 的 100 万 token 上下文在处理大型企业级项目时优势巨大。更关键的是——在标准化测试中，它的每次调用成本仅 $0.07，是所有前沿模型中性价比最高的。

场景二：综合能力均衡，需要全面的 Agent 支持

首选：GLM-5

SWE-bench 77.8% 已经很强，但 GLM-5 的真正优势在于「全面」：终端操作、工具调用、MCP 协议支持都是第一梯队。MIT 开源许可证对企业的合规性来说最友好。而且智谱作为清华系公司，对国产芯片（昇腾等）的适配做得最好。MoE 架构 744B 总参但只有 40B 激活，算力要求远低于参数量暗示的水平。

场景三：算力有限，需要轻量级部署

首选：Qwen3-Coder-Next

80B 总参数、3B 激活参数——这是目前性价比最离谱的编码模型。SWE-bench Verified 超过 70%，用 SWE-Agent 脚手架即可，这是最现实的选择。

场景四：需要多模态能力（看设计稿写代码）

首选：Kimi K2.5

原生多模态（文本 + 图片 + 视频），可以从 UI 设计稿直接生成代码。对于企业内部系统的前端开发，这个能力可能特别有价值。Agent Swarm 多智能体协作也适合复杂的多步骤开发任务。

推荐组合

如果要给企业内网搭一套方案，可以这样选：

OpenCode 的模型无关性让这种「按需切换」成为可能——改一行配置，不需要换框架。

补充：DeepSeek V3.2 在编码 Agent 赛道上 SWE-bench 约 70%，已被 GLM-5 和 MiniMax M2.5 超越，但在推理任务上仍然极强（AIME 2025 通过率 96%）。如果你的场景偏推理而非编码，DeepSeek 仍是第一选择，V4/R2 值得关注。字节跳动的 Seed 2.0 Pro 和 Seed2.0-Code（推理速度 2,146 token/s）在代码补全和实时辅助场景有潜力，但目前主要通过火山引擎 API 提供，自部署方案不明朗，暂列为「关注」。

五、半年前 vs 现在：格局变了

半年前（2025 年中），开源模型在编码能力上和前沿闭源模型还有明显差距。那时候的选择是：

• 想要最好的 Coding Agent 体验？用 Claude Code + Opus/Sonnet。
• 被困在内网？只能将就，效果打折。

现在的格局完全不同了：

「模型质量天花板」这个论点已经不成立了。 这是最关键的变化。

半年前犹豫要不要深入 OpenCode，最大的顾虑是：就算框架再好，模型不行，Agent 也跑不起来。现在这个顾虑可以放下了——至少在 benchmark 层面，开源模型已经证明了自己。

但 benchmark 和日常实战之间还有一道鸿沟。模型的「裸能力天花板」被打破了，不代表你开箱即用就能获得 Opus 级别的体验。接下来要聊的，就是这道鸿沟有多大，以及怎么用工程手段把它填上。

六、Benchmark 不等于实战：Harness Engineering 方法论

前面五个章节说的都是好消息，但如果文章就此收尾，那就太乐观了。

一个残酷的现实：SWE-bench 80% 不代表你日常使用时也有 80% 的体验。

Benchmark 测的是「在标准环境、标准脚手架下，模型能不能修好这个 GitHub Issue」。但真实的 Agent 使用场景远比这复杂——你的项目结构千奇百怪、你的需求描述不一定精确、你的工具链有各种自定义配置。在这些非标准场景下，开源模型和 Claude Opus 4.6 之间的体感差距往往比 benchmark 数字暗示的更大。

具体来说，开源模型在以下方面仍然存在短板：

• 复杂指令遵循的稳定性：给一个多步骤、有约束条件的任务，Opus 4.6 几乎总能一次做对，开源模型可能需要 2-3 次修正
• 长链推理中的「迷路」：Agent 循环跑到第 10 轮以后，开源模型更容易偏离原始目标或重复之前的错误
• 边缘情况处理：遇到不常见的报错、冷门库的 API，开源模型的应对能力明显弱于 Opus 4.6
• 代码风格一致性：同一个会话中，开源模型生成的代码风格可能前后不一致

这些差距怎么办？靠等下一个版本？当然可以，但更务实的做法是——用工程手段来补。

Harness Engineering 是什么

Harness Engineering（脚手架工程）并不是我发明的新术语——它是 Coding Agent 社区和业界中自然形成的一类实践的统称。从 SWE-bench 的 Agent 开发者到 Claude Code/OpenCode 的用户社区，大家都在做类似的事：优化系统提示、设计 Hook 拦截策略、封装自定义工具、构建项目级的 Skill 库。这篇文章的贡献在于把这些散落的实践整理成一个结构化的四层模型，方便理解和应用。

核心理念是：不只依赖模型的裸能力，而是通过精心设计的外围系统来放大模型的有效输出、约束模型的错误倾向。

SWE-bench 的两张表之间的分数差距（厂商自报 vs 标准化脚手架）就是最直接的证据——同一个模型，配上不同的脚手架，性能差距可达 5-8 个百分点。脚手架不是模型的附属品，而是 Agent 系统的核心组成部分。

对于企业内网场景，Harness Engineering 的意义更大：

1. 你无法选择模型——在闭源前沿不可用的约束下，你只能用开源模型。但你可以选择如何使用它。
2. 你的知识比模型多——关于你的代码库、业务规则、架构约束，你知道的远比任何模型多。Harness Engineering 就是把你的知识注入到 Agent 系统中。
3. 工程投入的回报是确定性的——模型何时变强不可控，但你的 System Prompt 优化、Hook 策略、Custom Tool 封装，每一步都有立竿见影的改进。

Harness Engineering 的核心理念

一个成熟的 Harness Engineering 实践包含四个层次：

Level 1: 约束层 — 告诉模型「不要做什么」（System Prompt 中的规则约束）
Level 2: 引导层 — 告诉模型「应该怎么做」（任务分解模板、输出格式规范）
Level 3: 兜底层 — 在模型犯错时自动修正（Hook 拦截、自动 lint、测试回归）
Level 4: 增强层 — 把复杂操作封装成工具，降低模型调用难度（Custom Tool + RAG）

这四个层次从上到下，工程投入递增，但也让 Agent 越来越可靠。好的 Harness Engineering 是「即使换了模型，系统依然好用」——因为工程层的价值独立于模型层。

当然，这里有一个值得坦诚面对的问题：如果模型持续变强，这些工程层是否终有一天变得多余？ 这个问题我们留到本文后半段回答——但先说结论：即使那一天到来，驱动你构建这些工程层的思维方式，本身就是不会过期的能力。

OpenCode 如何支撑每个层次

OpenCode 的架构为 Harness Engineering 提供了完整的抓手：

1. System Prompt 精调（约束层 + 引导层）

OpenCode 允许你完全控制发送给模型的系统提示。针对开源模型的弱点，你可以：

• 写更明确的任务分解指令（把一个大任务拆成多个小步骤，降低单次推理难度）
• 加入更严格的输出格式约束（减少格式错误导致的工具调用失败）
• 在提示中嵌入项目特定的规范（命名约定、代码风格、目录结构说明）
• 显式的「思考链」模板：要求模型在调用工具前先输出 reasoning，强制它慢下来思考

Claude Code 的系统提示是固定的，你改不了。OpenCode 可以改——这在模型能力不够完美时，就是你最重要的调节旋钮。

一个具体的例子：GLM-5 在处理「修改 A 文件的同时还要更新 B 文件的测试」这类跨文件任务时，容易漏掉第二步。解法：在 System Prompt 中加入 修改代码文件后，必须检查是否有对应的测试文件需要同步更新 这样的规则。成本为零，效果立竿见影。

2. Hooks 和生命周期拦截（兜底层）

OpenCode 提供了 17+ 个 Hook 点和 49+ 个事件，覆盖了 Agent 循环的每个关键节点。你可以：

• Pre-tool-call Hook：在工具执行前校验参数，拦截明显错误的调用（比如模型要删除不该删的文件）
• Post-tool-call Hook：在工具执行后检查结果，自动触发修复（比如检测到编译错误就自动重跑 lint）
• Session Hook：在整个会话层面做质量控制（比如每 5 轮检查一次是否偏离了原始目标）
• Pre-completion Hook：在模型认为任务「完成」之前，自动跑一遍验证（测试、类型检查、代码规范）

本质上，这些 Hook 让你在模型和代码之间加了一层「安全网」。模型能力不够稳定？没关系，Hook 帮你兜底。

这种「不信任模型输出，但信任验证流水线」的理念，是 Harness Engineering 的核心哲学。 你不需要模型每次都做对——你只需要系统能在模型做错时及时发现并修正。

3. Custom Tool 封装（增强层）

OpenCode 支持自定义工具。你可以把复杂操作封装成简单的工具接口，降低模型的调用难度：

• 把「读取项目配置 → 解析 → 生成对应文件」封装成一个 scaffold_module 工具
• 把「运行测试 → 分析失败原因 → 定位出错代码」封装成一个 diagnose_test_failure 工具
• 把企业内部的 CI/CD 流程封装成一个 deploy_to_staging 工具

模型需要做的从「自己想明白怎么做」变成「选对工具然后调用」——这大幅降低了对模型推理能力的要求。

关键设计原则：一个好的 Custom Tool 应该有清晰的语义名称和详细的描述。模型不需要理解内部实现，只需要知道什么时候调用、传什么参数。这就像给一个新人同事写好了操作手册——即使他对业务不熟悉，也能按手册执行。

4. Agent Skill 沉淀（经验资产化）

OpenCode 的 Skill 机制让你可以把成功的工作模式固化下来。比如：

• 你摸索出了一套让 GLM-5 高效写 Spring Boot Controller 的提示策略 → 存成 Skill
• 你发现 Qwen3 做 SQL 优化时需要额外给表结构信息 → 存成 Skill
• 你总结了一套让开源模型少犯格式错误的输出规范 → 存成 Skill

这些 Skill 是你的「工程经验数据库」，它们让 Agent 的表现不再完全依赖模型的裸能力，而是「模型能力 + 你的工程经验」的叠加。

Harness Engineering 的本质：从「模型崇拜」到「系统思维」

很多人把 AI 编码的效果等同于模型的能力——模型好就好用，模型差就难用。这种「模型崇拜」忽略了一个事实：在生产环境中，系统的表现 = 模型能力 × 脚手架质量 × 上下文精准度。

一个 SWE-bench 75% 的模型 + 精心设计的 Harness，实战表现可能超过一个裸跑的 80% 模型。SWE-bench 官方排行榜上厂商分数和标准化分数之间的 5-8% 差距，就是这个乘法的直接体现。

一句话总结：模型不够强，就用工程来凑。OpenCode 的可定制性就是为这个场景设计的。

七、企业数据盲区：让开源模型「看见」你的代码库

还有一个更深层的问题：开源模型没见过你的代码。

Claude Opus 4.6 和 Gemini 3.1 Pro 在训练时至少看过海量的开源代码，对主流框架的 API、设计模式、最佳实践有很好的内化。但你的企业代码库——内部框架、私有 SDK、业务领域模型、自定义工具链——这些东西不在任何公开训练集里。

对于开源模型来说，这个问题更突出：它不知道你的 BizService 是个什么类，不知道你的 @BizTransaction 注解做了什么，不知道你的 Hive 表命名规范是 dw_xxx_yyy_di。在这种信息不对称下，模型给出的代码可能语法正确但业务全错。

这是一个巨大的挑战，也是一个正在被逐步解决的问题：

方案一：上下文注入（最轻量，立即可用）

OpenCode 的 System Prompt 和 Skill 机制可以携带大量的项目上下文：

• AGENTS.md / SPEC.md：在项目根目录放置结构化的项目说明文件，OpenCode 会自动读取并注入上下文
• Custom Instructions：每次会话自动加载的项目规范，包括命名约定、架构说明、核心模块文档
• Tool Description：在自定义工具的描述中嵌入业务语义，让模型在调用时就能理解业务上下文

这个方案零成本、立即可用，但受限于上下文窗口大小。对于中小项目够用，大型企业级代码库就不够了。

方案二：RAG（检索增强生成）

把企业代码库和文档建成向量索引，让 Agent 在需要时自动检索相关代码片段：

• 代码级 RAG：当模型要修改某个模块时，自动检索该模块的历史实现、测试用例、依赖关系
• 文档级 RAG：当模型遇到业务概念时，自动检索内部 Wiki、接口文档、业务规范
• Commit 级 RAG：当模型遇到特定模式时，检索过去类似问题的修复方式

OpenCode 的自定义工具机制让你可以把 RAG 检索封装成一个工具——模型调用 search_codebase("BizService 的使用方式")，RAG 返回最相关的 5 个代码片段，模型基于这些上下文生成代码。

这比纯上下文注入灵活得多，但需要搭建向量数据库（Milvus、Chroma 等）和索引管道。对于有一定基础设施能力的企业来说，这是目前最平衡的方案。

方案三：模型微调（最重量级，效果最好）

用企业内部代码对开源模型做领域微调（LoRA / QLoRA）：

• 让模型内化你的代码风格、命名规范、架构模式
• 让模型学会企业特有的框架和 SDK 用法
• 让模型理解业务领域术语和逻辑

微调后的模型在企业场景下的表现会有质的飞跃——它不再是一个「通用模型 + 外部上下文」，而是一个真正「懂你业务」的模型。但微调需要算力、数据准备、评估流水线，工程投入最大。

我的判断：分阶段推进

关键是：不要等所有基础设施都完美了才开始。上下文注入是零成本的，今天就能用，效果已经比「裸跑模型」好很多。RAG 和微调是锦上添花，可以在用起来之后逐步迭代。

八、行动建议与技能迁移

如果已经在用 Claude Code（比如在个人设备上），切到 OpenCode 的迁移成本非常低。在上一篇文章中我详细拆解过：两者共享约 85-90% 的核心机制——Agent Loop、工具系统、配置体系、Hooks 生命周期都是同一套范式。深入理解其中一个，迁移到另一个几乎是无缝的。

而且，在迁移过程中你积累的 Harness Engineering 经验——如何写好 System Prompt、如何设计 Hook 拦截策略、如何封装 Custom Tool、如何构建 RAG 管道——这些能力本身就是跨模型、跨框架通用的。模型在换代，但你的工程能力一直在增值。

具体来说，建议分三步走：

1. 现在就开始：在个人设备或开发环境装好 OpenCode，接入一个开源模型 API（GLM-5 或 Qwen3-Coder-Next 门槛最低），跑几个真实的编码任务，建立体感。
2. 积累 Skill 库：把摸索出的有效提示策略、Hook 配置、自定义工具逐步沉淀成 Skill。这些 Skill 就是你的「工程经验资产」，换模型时直接复用。
3. 推动团队试点：选一个低风险的内部项目做试点，验证「OpenCode + 开源模型 + RAG」这条链路在企业环境下的可行性，为后续推广积累数据。

到这里，关于「今天能做什么」已经说得差不多了。但在行动之前，值得退一步想一个更大的问题：前面说的这些 Harness Engineering、Skill 沉淀、Custom Tool 封装——它们真的是长期有效的吗？还是终将被更强的模型淘汰？

九、另一种声音：脚手架已死，代码库才是新战场

2026 年 3 月，Amp（一个 Coding Agent 产品）发表了一篇引发行业讨论的文章——《The Coding Agent Is Dead》。核心论点极其激进：

当前这一代 Coding Agent 已经死了。模型已经强到不再需要精心设计的脚手架。一个简单的 bash 工具就够了。

Amp 的逻辑链：最新的前沿模型（GPT-5.3-Codex 等）已经被充分训练成了编码 Agent，它们不需要外部系统教它们怎么当 Agent。你精心设计的 System Prompt、工具定义、Hook 策略——这些东西的边际价值正在趋近于零。模型的蛮力碾压了一切精巧的工程设计。

基于这个判断，Amp 做了一个激进的决定：砍掉所有 IDE 编辑器插件，只保留 CLI。理由是 IDE sidebar 在「束缚」模型——这些模型不再是需要监护的助手，它们应该独立运行、脱离编辑器、甚至在你不在电脑前时也能工作。

这个观点对我们意味着什么？

先说 Amp 说得对的部分：

瓶颈确实在转移。 当模型强到一定程度，Agent 层的工程差异会被压缩。这在 SWE-bench 标准化测试中已经能看到苗头——前沿模型即使用最简单的 100 行 mini-SWE-agent 脚本，也能拿到 75%+ 的分数。精心设计的脚手架带来的额外增益从之前的 15-20% 压缩到了 5-8%。趋势是清晰的。

“为 Agent 重组代码库”是一个真正的新命题。 这是 Amp 提出的、我们在前面八章中都没有充分讨论的方向。

过去几十年，代码库的组织方式经历过多次范式转移——都是为了适应新的「消费者」：

如果 Coding Agent 真的成为代码库的核心「消费者」，那代码库应该怎么重组？一些可能的方向：

• 模块粒度更小：单个文件/模块的职责足够清晰，Agent 不需要读完整个项目就能理解局部
• 接口定义更显式：类型签名、JSDoc/PyDoc 更完整，减少 Agent 需要「猜」的信息
• 测试覆盖更完整：Agent 需要快速验证自己的修改是否正确，没有测试就是在裸跑
• 文档内嵌更多：AGENTS.md、SPEC.md 不再是可选项，而是代码库的核心基础设施
• 依赖关系更透明：显式的模块依赖图，让 Agent 知道改了 A 需要检查哪些 B

这些实践每一条都是好的工程实践，即使没有 Agent 也应该做。但 Agent 时代给了它们新的紧迫性——你的代码库对 Agent 的友好度，直接决定了 Agent 的产出质量。

但 Amp 说得不对的部分

「脚手架已死」只适用于最前沿的闭源模型。 对于我们讨论的企业内网场景——用 GLM-5、Qwen3-Coder-Next 这些开源模型——脚手架工程仍然是关键差异来源。5-8% 的分数差距在日常使用中可以放大到 30-50% 的体感差距。在这个阶段，Harness Engineering 不是「锦上添花」，而是「能不能用」的分界线。

砍掉 IDE 插件过于激进。 模型「脱离编辑器独立运行」确实是一个趋势（Claude Code 的 headless mode、Codex 的异步多任务都指向这里），但现阶段大多数开发者的工作流仍然以 IDE 为中心。完全抛弃 IDE 集成等于主动放弃了一大类使用场景——特别是需要即时反馈和可视化的场景。

我的判断：两条路都要走

不要把 Harness Engineering 和 Agent-Ready Codebase 看成对立的选择。它们解决的是不同层面的问题：

• Harness Engineering 解决的是「如何让 Agent 适应你的代码」——短期有效，效果确定
• Agent-Ready Codebase 解决的是「如何让你的代码适应 Agent」——长期价值，但需要组织层面的投入

最务实的做法：用 Harness Engineering 快速起步（因为它只需要你一个人），同时推动代码库向 Agent-Friendly 方向演进（因为这需要团队共识）。

而且，AGENTS.md 这个实践本身就是两条路的交汇点——它既是 Harness Engineering 的一部分（给 Agent 注入上下文），也是 Agent-Ready Codebase 的一部分（让代码库对 Agent 更友好）。

十、写在最后：脚踏实地，仰望星空

这篇文章从数据出发，走过了选型、工程、实战，最后落到了一个更大的问题：开发者和 AI 的关系本身正在发生什么变化？

半年前，AI 是工具。你给它一个指令，它返回一段代码。就像用搜索引擎一样——你问，它答。

现在，AI 正在变成协作者。它理解项目、规划方案、执行修改、验证结果。Agent Loop 的每一轮循环，都在模拟一个工程师的工作方式——只是速度快了几个数量级。

而前方可能是一个更深刻的变化：AI 不只是协作者，它可能成为代码库的主要消费者和生产者。在那个世界里，开发者的角色不再是「写代码的人」，而是「设计系统、定义约束、验证质量」的人。代码本身变成了 AI 的中间产物，就像编译器的汇编输出——你不需要手写它，但你需要理解它、审查它、优化生成它的系统。

这个未来听起来很远，但它的种子已经在我们讨论的每一个细节里了：

• 你写的 AGENTS.md，本质上是在定义约束——告诉 AI「在我的项目里应该怎么工作」
• 你设计的 Hook 拦截策略，本质上是在验证质量——建立一条不依赖模型自觉性的质量防线
• 你封装的 Custom Tool，本质上是在设计系统——把业务知识转化为 Agent 可用的接口
• 你推动的 Agent-Ready Codebase，本质上是在重新定义「好代码」的标准——不只是人类可读，还要 AI 可操作

所以，Harness Engineering 和 Agent-Ready Codebase 并不是你为了适应当前模型局限而做的临时妥协。它们是你在为一个新角色做准备——一个离「系统架构师」和「质量守门人」更近、离「代码手写员」更远的角色。

这个转变不会一夜发生。今天，System Prompt 精调和 Hook 拦截仍然是你最实际的武器。明天，当模型强到这些工具的边际价值趋近于零，你在构建它们过程中锻炼出的系统设计能力、业务理解深度、质量判断标准——这些能力不会过期。它们恰恰是 AI 越强、人类越需要的东西。

对于企业内网开发者来说，此刻反而是最好的起点。模型够用了，框架就位了，工程方法明确了，演进方向清晰了。不需要等一切完美——今天就可以开始，从一个 AGENTS.md 文件、一条 Hook 规则、一个 Custom Tool 开始。

每一步都在积累的，不只是技术经验，更是对「人与 AI 如何协作」这个时代命题的前沿理解。这个理解，才是在模型快速换代的洪流中，你真正带得走的东西。