前言本文动机是从CV到NLP的三年 LLM转型的历程趁着harness agent 热度 主观视角下对当前一些事情的理解观点希望对读者有所启发和帮助并且我也将我的观点和新发布的opus4.7 进行了一波讨论这也是我决定发出来的原因这里克制下——不多讨论技术细节只讲认知理解。关于“harness” 这个概念这本身这是抽象概念harness和model 实际上是一种微妙的“博弈” 而”Harness 工程“上从其实是两个维度投影① 脑手分离的工程设计 核心标准在于Harness层能否在不调用LLM的情况下运行单元测试。关键在于界定Harness、Session、Capability和Sanbox之间的边界。② Harness与其核心Model的关系 从生命周期来看Harness是Agent的长期人格而Model只是其短期意识。二者两位一体不可孤立看待。我们无法时刻完美约束LLM的决策因此这不是非黑即白的二元命题。Harness 的本质不是“教模型怎么做”而是“替系统承担责任”。Model 负责生成候选行动Harness 负责把这些行动放进权限、事务、审计、回滚、记忆协议里。所以我会隐喻成“制度-认知体”或者“宪法-执行者”前者可以越来越隐形但不会消失。这一关系的本质是智能下放给模型责任上提给系统。这比“约束模型”更准确因为高水平 harness 不是不断干预模型而是只在必须负责的地方接管。。**agent 工程也不是 prompt engineering也不是 framework 选型而是随着越来越强的模型配上一层足够薄的认知壳和足够厚的制度壳把概率智能变成可测试、可审计、可回滚、可运营的安全系统Less is more!目前业界两种观点claude code 和 managed agent 代表A公司的观点 他们觉得harness和model是长期共存关系所以设计了脑手分离的概念GPT\国内知名研究员\meta等 是更偏向模型最终内化所有harness的极端理念虽然是两种观点共同点是模型必然增强只是控制环境是0还是0.1的近似区别和大于同的时候那么本质上从时间维度来看是一回事他们做的事情方向也会一致。为了避免长篇大论我针对几个目前常见的观点进行解读和分析我会把这些看似不同的观点串联成一个本质带你解读笔者心中的理念。从第一性原理出发贯穿技术harness 哲学、能力训推贯通、产业认知差、趋势内化极限形成闭环。这套东西的价值远超代码本身因为它定义了一种评判标准——有了这个标准你写的每一行代码都有方向你做的每一个决策都有依据。提示我会在下一篇claude code核心技巧中解释为什么上下文缓存是其他项目很难复刻的为什么你需要精通transformers 推理架构文章目录前言1. 关于AI coding 让代码变廉价这个观点并不完全赞同2. 关于 framework 之争2.1 自媒体和卖课的潜在观点——“传统软件开发模式就能做AI Agent”Prompt Cache 的经济账Claude Code 源码里的真实 cache-aware 设计Tokenizer 边界的真实事故Structured Output 的失败率差异可复现实验公开案例Agent 轨迹能力的公开 benchmarkClaude Sonnet 4.5 在优化实现条件下的表现约70% 相同模型搭配LangGraph简单ReAct框架的表现约45% 仅因测试框架差异同一模型产生了25个百分点的性能差距 该数据并非主观判断而是可在排行榜上验证的客观事实。性能差距主要源于测试框架的工程细节差异包括文件读取策略、补丁应用方式、错误反馈格式设计以及子代理划分方案。Reasoning 模型的 thinking budget 问题2.2 为什么不用 framework开源的更快更好别重复造轮子零个主流 framework。如果 framework 真的更快更好至少有一个会用。这是市场选择的事实不是个人偏好。” 那么思路下为什么呢2.3 为什么 LangGraph / AutoGen / CrewAI 这类 framework 做不出 Claude Code 级别的 harness更快是幻觉——总拥有成本账Framework 的隐藏 prompt反模式手搓的原语量级其实很小换模型的真实代价Framework 触及不到的控制点清单所以我的观点这和harness和model两位一体的驾驭关系类似并不是hard式去理解而是两位一体共存。3. Harness 的本质稳定控制 × 模型的博弈3.1 维度一脑手分离Brain-Hand Separation3.2 维度二Harness ↔ Model3.2.1 此消彼长的关系是**动态的**不是静态的3.2.2 细粒度的真正含义是控制点密度而非代码量3.2.3 恒定原则一个不变量3.2.4**时间维度上的 Harness**4 Harness 的理论极限5 Agent 工程师是应当基本最初级的训练、推理基本知识和实践经验6 开源模型落地 vs 顶级商业模型 Demo 的认知差核心观点三重错位被低估的三个维度① Agent能力差距呈阶跃式而非线性② 开源模型的“工具调用方言”问题③ 工业界成本优先级反转认知差的传导危害7 给读者的一些结论1. 调用黑盒心智是严重工程缺陷 ✅2. Claude Code cache-aware tool edit 是绝佳例证 ✅ 大模型原理必不可少3. 训练自己的子智能体垂类能力是正确的长期方向 ✅4. 模型训练和推理作为 CLI 在工程上打通调用闭环 ✅8、自我纠正和改进注意加强 1不仅要懂还要**建立自己的反馈闭环**加强 2警惕过度工程化到推理层的反向陷阱结尾1. 关于AI coding 让代码变廉价这个观点并不完全赞同看了Claude code 源码的设计用AI coding 尝试复刻和吸收后我发现了一个非常有趣的现象表象LLM 能一次吐出几百行代码看起来边际成本趋近于零。本质像 claude-code这种级别的工程它的价值不在代码行数在于设计但是最重要的是在细粒度的工程决策密度——每一个小函数、每一处 prompt 拼接、每一个 tool schema 的字段顺序、每一次 context 裁剪策略都是踩过坑之后沉淀下来的隐性知识。AI 能生成看起来对的代码但生成不出**为什么必须这么写的约束集合**。所以恰恰是 agent/harness 这类项目让我觉得好的代码反而变贵了——因为能写的人变多了能判断一段 harness 代码是否正确的人没变多Bug 从编译错误/逻辑错误转向概率性行为退化调试成本指数上升细粒度意味着每一行都承担语义不像 CRUD 代码可以大段复制你可以很廉价去获得大方向的思路方案但是核心思路和细粒度上AI无法帮助你完成就像在Claude code开源前其实就已经公开过很多优化思路我照猫画虎的用AI CODING了一个低配版等真的出来后 我发现落差还是比较大的。换句话说代码在贬值系统性工程代码在升值AI coding 拉大了这个差距而不是缩小。且AI coding 作用是提升效率、且放大你个人在专业领域内的能力和更进一步的可能。接下来是一个很好的问题我们可以带着前言上我讲的harness概念来看待所有问题。2. 关于 framework 之争很多媒体和卖课的、还有开发者们都在选择什么framework更合适去开发在这个code is cheap framework 同样cheap的时代我们先从底层触发思考问题framework解决了什么问题解决的是谁的问题*不同领域背景但是都要做AI Agent相关的开发者*2.1 自媒体和卖课的潜在观点——“传统软件开发模式就能做AI Agent”这个结论本身没问题但是不全面缺后半句“不一定做的好”不明白模型本身的原理和由来还有基本工程经验就会发生很多难以估计的问题以下举例Prompt Cache 的经济账Anthropic 官方文档公开Claude prompt cache 命中价格 原价的 10%写入 1.25x读取 0.1xCache 基于前缀精确匹配任何前缀 token 变化 → 整段失效最小缓存单位1024 tokensSonnet可举证推演假设一个 coding agent 单轮上下文 30K tokens10 轮对话不懂缓存30K × 10 × $3/M $0.9/session懂缓存稳定前缀30K × $3/M 30K × 9 × $0.3/M $0.17/session成本差 5.3 倍这不是优化这是不懂就直接烧掉 80% 预算。只关注开发的人看到 API 价目表只有输入 $3/M、输出 $15/M两行根本看不见这笔账**一个只懂 API 调用的人根本看不见这个优化空间存在——因为在他的心智模型里调用成本只是 token 数不存在前缀稳定性这个维度。Claude Code 源码里的真实 cache-aware 设计系统 prompt 分段固定部分工具定义、指令放前面动态部分当前文件、用户消息放后面明确标注 cache_control 断点TodoWrite 工具为什么 todo list 要作为一个独立 tool 而不是塞进 system prompt因为塞进 system prompt 会破坏前缀缓存作为 tool result 放在对话尾部前缀稳定文件读取结果的截断规则超过阈值的文件 content 不进 system prompt 而走 tool result本质是保护 cache 前缀这些设计在代码里是摆在明面上的不明白transformer推理基础和VLLM等引擎使用的人是完全看不出每个决策背后都是为了对齐 KV cache 的物理结构。Tokenizer 边界的真实事故公开案例GPT-4早期SolidGoldMagikarp分词异常 - 特定分词器中的罕见标记会导致模型输出混乱。缺乏分词器知识的团队难以排查此类问题。Llama 3的|begin_of_text|标记 - 若在工具返回结果中被用户数据污染会直接截断上下文表现为模型突然失忆现象。Qwen工具调用问题 - 某些版本会输出tool_call而非标准JSON格式若框架仅支持JSON解析将导致100%失败但表象常被误判为模型不稳定。问题的根源都在于分词处理和模型训练数据分布因此仅通过应用层调试永远无法定位真正原因。Structured Output 的失败率差异可复现实验公开案例可做的 A/B 实验任何团队 1 天内可验证让一个 agent 输出 JSON 调用工具跑 1000 次做法 JSON 解析成功率纯 prompt engineering“请输出 JSON” 85-92%Few-shot 示例 93-96%重试逻辑 97-98%constrained decoding需要懂 logit processor 99.99%长 horizon agent 假设每轮调用成功率 97%20 轮累计成功率 0.97²⁰ 54%。99.99% 则是 99.8%。这是能不能做生产系统的差距而它依赖的是懂采样 / logits这种训推知识。Agent 轨迹能力的公开 benchmarkSWE-bench Verified2025 年末数据Claude Sonnet 4.5 在优化实现条件下的表现约70%相同模型搭配LangGraph简单ReAct框架的表现约45%仅因测试框架差异同一模型产生了25个百分点的性能差距该数据并非主观判断而是可在排行榜上验证的客观事实。性能差距主要源于测试框架的工程细节差异包括文件读取策略、补丁应用方式、错误反馈格式设计以及子代理划分方案。Reasoning 模型的 thinking budget 问题关键信息OpenAI o-series / Claude extended thinking 文档计费说明Reasoning token 按标准输出 token 价格收费无限制的 o1-style 调用可能产生 10K-32K thinking tokens/次成本示例一个软件开发智能体运行 100 次可能产生 $50-200 的费用优化建议设置 thinking budget 上限复用 thinking token采用 cache-aware 的 reasoning 路由策略这是直接可算的钱不是理论。2.2 “为什么不用 framework开源的更快更好别重复造轮子”成熟项目的技术选型事实(这里不带hermes是因为涉嫌抄袭)这是最硬的证据直接列开源项目实际用的东西| 项目 | 使用 LangGraph/AutoGen | 实际架构 | |------------|----------------------|----------------------------| | Claude Code | ❌ | TypeScript 框架 | | Cursor | ❌ | 自研 Rust TS 框架 | | Cline | ❌ | 自主开发的 VS Code 扩展 | | Aider | ❌ | 纯 Python 自主开发 | | Opencode | ❌ | 自主开发的 GO 实现 | | OpenHands | ❌ | 自研事件流架构 | | SWE-agent | ❌ | 自研 ACI 架构 | | Devin | ❌根据泄露信息 | 自主研发架构 |零个主流 framework。如果 framework 真的更快更好至少有一个会用。这是市场选择的事实不是个人偏好。” 那么思路下为什么呢2.3 为什么 LangGraph / AutoGen / CrewAI 这类 framework 做不出 Claude Code 级别的 harness核心矛盾是framework 的抽象层次 和 harness 所需的控制粒度 不在同一个数量级。LangGraph 把世界抽象成Node / Edge / State这个抽象对workflow 编排够用但对一个真正的 coding agent 来说关键博弈发生在更低的层次关键控制点framework 是否暴露tool schema 的字段命名、顺序、description 措辞❌ 通常被封装system prompt 的结构化分段 / 动态注入时机❌context 压缩策略何时总结、保留哪些 tool result❌ 或过于通用tool call 的并行/串行/打断/重试语义⚠️ 粗粒度子 agent 的 context 隔离边界⚠️token budget 的实时反压❌模型特定的 quirkClaude 的 thinking、OpenAI 的 strict mode❌ 被抽象掉了Claude Code、Cursor、Cline 这些之所以都自己写harness就是因为这些点一旦被 framework 包住你就只能靠破坏式修改去绕——而破坏式修改等于放弃 framework 的收益生态、升级、社区此时 framework 就是净负债。LangChain/LangGraph 自己的公开问题GitHub issue 里可查LangChain 历史上多次重大 breaking change已有项目被迫重写LangGraph 在复杂 tool call 场景下的 state 管理有公开的性能 issueLangChain 被 Octomind、Fabric AI、Bryan Bischof 等技术博客公开批评后弃用文章标题级别的“Why we no longer use LangChain for building our AI agents” (Octomind, 2024)“Fuck you, show me the prompt” (Hamel Husain)——直指 framework 隐藏 prompt 的反模式这些不是争议是工业界已经发生的事实。更快是幻觉——总拥有成本账可举证的时间线对比基于多个团队复盘阶段框架路线原生开发路线首日演示半天 ✅2-3天实际场景适配1-2周需调整prompt/解析逻辑1周首次性能优化2-4周问题定位困难抽象层阻碍数日代码透明可见底层模型替换1-2月可能存在集成兼容问题数日仅需修改适配层合规安全审查不可控框架自主发起网络请求完全可控长期维护1年需持续适配框架变更稳定可靠框架方案仅在首日演示阶段具备速度优势后续每个环节都会滞后。快速原型 ≠ 产品化效率。Framework 的隐藏 prompt反模式LangChain 的 ConversationBufferMemory / ReActAgent 的实际 prompt 你看不见要挖源码当模型表现异常时你不知道 framework 注入了什么升级 framework 版本底层 prompt 可能悄悄变了硬证据去 langchain/libs/langchain/langchain/agents/react/agent.py 看源码会发现大量硬编码的 prompt 片段版本间还在不断调整。你的 agent 的行为实际上取决于你不知道的第三方代码。这是安全和合规的硬伤——企业场景下你甚至无法解释你的 agent 为什么这么回答。手搓的原语量级其实很小可数代码行数以 Aider 为例开源可查模块 代码量LLM client streaming retry ~500 行Tool parsing execution ~800 行Context / history 管理 ~600 行File edit (diff/patch apply) ~1500 行整个 harness 核心 ~3500 行对比 LangChain几十万行 几百个依赖。重复造轮子这个指控反转了——用 framework 才是引入巨量你不需要的代码手搓反而是更小的总代码量。换模型的真实代价真实案例2024-2025 多个团队公开复盘从 GPT-4 迁移到 Claude 3.5LangGraph 项目成功率从 82% 掉到 47%不是模型问题是 tool schema 序列化方式没改同样的迁移手搓项目通过一个 adapter 几天内解决这就是前几轮讨论的模型方言问题的具体代价。Framework 的模型无关是市场宣传不是工程事实。Framework 触及不到的控制点清单精确控制工具模式tool schema中的字段令牌顺序以优化缓存效率支持在对话轮次turn内动态插入或删除系统提示片段对工具返回结果实施结构化有损压缩保留语义信息去除空白字符为每个工具单独配置重试/超时/权限策略实现子代理sub-agent的上下文完全隔离同时保持内存共享机制支持中断正在执行中的工具调用并注入新指令实现工具调用的真正并行执行并按完成顺序合并返回结果建立基于令牌预算的实时反压机制超额时自动压缩历史记录支持针对特定模型关闭或替换思维链CoT前缀很多framework能原生做到的可能 1-2 条其余都要绕过或魔改。而每一条都是生产级 agent 的必需能力。所以我的观点这和harness和model两位一体的驾驭关系类似并不是hard式去理解而是两位一体共存。在高控制需求、长时序、高副作用场景里通用 framework 的边际价值明显下降。初学者framework 是脚手架帮你建立 agent 心智模型 → 正收益中段framework 的抽象开始和你的需求错位你开始 patch monkey → 零收益高段你已经知道每个 token、每个 tool call、每个 context 截断意味着什么 → framework 是负收益因为它在你和模型之间强加了一层你不需要的翻译这和数据库领域很像入门用 ORM精通后写裸 SQL。Agent 领域的ORM 时代正在结束。Framework 通常只解决第 1 层的一部分编排对 2、3 层几乎无能为力。不绑定 framework不代表从零写。我观察到的成熟做法是抽取原语而非框架一个薄薄的LLM client带 retry / streaming / tool parsing一套自己控制的Message / Tool / Context数据结构可插拔的context compactor/tool executor/approval gate这些加起来可能就 2000-3000 行但你对每一行都有完全的控制权。这正是 Claude Code等展现的——目前是**顶级 harness 都是手搓的没有一个是基于固定framework的。就像harness 和Model ,开发者和framework之间也有关系到达一定程度就是使用更薄的组件来复用而不是锁死一个完整framework.因此对于不同的开发者使用的武器和工具也是不同的。能保留 prompt、context、tool call、budget、recovery 这些控制点的薄抽象有价值把这些包掉的厚框架越往生产走越容易变成债务。所以长期看很多团队不会彻底“反框架”而是会沉淀自己的微框架或原语层。3. Harness 的本质稳定控制 × 模型的博弈“稳定控制和模型之间的博弈”展开成三层Determinism vs. Emergence希望 tool 调用路径可预测但模型的价值恰恰在于能跳出你预设的路径。harness 的艺术是在关键节点插桩白名单工具、结构化输出、guardrail在其他地方放手。Context economycontext window 是零和资源。harness 的本质是一个context 调度器——决定什么进、什么出、什么压缩、什么永久驻留像 AGENTS.md / skills/。Error recovery loop模型会出错好的 harness 不是防止出错(很关键 兜底retry那种都不是harness设计思想而是预防)且让错误可观测、可回滚、可让模型自己看见并修复。Claude Code 的tool_use_error反馈就是典型例子**。3.1 维度一脑手分离Brain-Hand Separation我完全认同这是harness 工程设计的第一性原理。展开说比如让模型直接生成 shell 去 rm 文件、让 harness 用正则去猜模型意图两种失败模式会相互放大harness bug 导致模型看到脏 context → 模型做出错误决策 → 错误决策触发更多 harness 异常。Claude Code 里每一个 tool 都有极其保守的输入校验和错误回写格式就是在强行维持这个分离。判断一个 agent 项目工程水平高低只看一个指标就够——harness 层有没有自己的单元测试且这些测试跑起来不需要调用 LLM。做不到的说明脑手还没分开。3.2 维度二Harness ↔ Model顶级 agent 具备超高细粒度——最大化稳定可控环节其余交给模型这个观察非常关键。把它形式化一下Agent Capability f ( Harness Control Surface , Model Capability ) \text{Agent Capability} f(\text{Harness Control Surface}, \text{Model Capability})Agent Capabilityf(Harness Control Surface,Model Capability)这里有三个结论3.2.1 此消彼长的关系是动态的不是静态的不是模型越强 harness 越薄那么简单。真实曲线是弱模型时代GPT-3.5harness 必须做大量脚手架——规划、反思、self-consistency、强结构化输出。harness 厚重。中段模型GPT-4 早期harness 开始瘦身但要加很多纠偏逻辑——重试、验证、回滚。harness 依然重但重点转移。强模型Claude 3.5 / GPT-5 级别harness 反而在特定维度重新变厚——不是为了纠偏而是为了放大模型的自主性并行 subagent、长 horizon 任务、精细 context 调度。所以不是单调递减而是重点迁移从替模型思考→纠模型的错→给模型腾空间。3.2.2 细粒度的真正含义是控制点密度而非代码量顶级 harness 的细粒度体现在控制点的数量和位置而不是代码行数。举例每个 tool call 前权限检查、参数规范化、路径沙箱每个 tool call 后结果截断、错误格式统一、token 计费每轮 turn 前context 组装策略、system prompt 动态片段、历史压缩每轮 turn 后工具解析、状态提交、中断点这些控制点每一个都极薄可能就几行但位置选得极准。这就是你说的最大化稳定可控环节——在模型能力的边界上密集布点边界之外一行不写。3.2.3 恒定原则一个不变量无论模型多强有一类东西永远在 harness 这边涉及外部世界副作用的操作。写文件、发网络请求、执行命令、修改数据库这些操作的幂等性、可回滚性、可观测性必须由 harness 保证因为模型可以想错但不能做错又没留痕。这是脑手分离在 model 侧能力上升时唯一不退让的防线。Claude Code 的 file edit 一定走 structured diff、一定有 pre-read 校验就是这个不变量的体现。3.2.4时间维度上的 Harness两个维度都是空间维度控制面 vs 执行面、粗粒度 vs 细粒度。我觉得还有一个经常被忽略的时间维度Harness 是 agent 的记忆与身份载体model 是当下的意识。模型每次调用是无状态的context window 结束一切归零Harness 承担了持久化记忆sqlite / vectors、skills 系统、AGENTS.md 这类跨会话契约、session resume这些东西模型不可能自己维护因为它每次醒来都是新的所以 harness 的一个核心使命是把模型的短期意识拼接成 agent 的长期人格。你 workspace 里的memory、skills、context_storage 正是这个维度的体现。在这个维度上harness 和 model不是此消彼长而是正交互补——模型再强也替代不了跨时间一致性这件事因为这本质上不是智能问题是工程协议问题。因此其实harness同时具备两种理解1.harness的控制思想 2.harness工程 前者是思路是hareness层围绕agent后者是系统环境工程ALL anything他们都是harness的概念没有谁对谁错我姑且这么理解就是harness概念层、和harness工程。图中四个象限是最实用的决策工具右上长期契约 Harness 必须做 你 bom-agent 该重投入的地方skills、memory、AGENTS.md右下单次会话 Harness 必须做 防线必须有但不需要扩张沙箱、事务左下单次会话 Model 能做 放手让模型干CoT、规划左上几乎是空的 这个象限本身在物理上罕见因为跨会话持久几乎必然意味着需要 Harness 介入4 Harness 的理论极限之前讨论过我认为Harness 和Model 可以无限趋近近期 LLM 研究训练已从 Agent RL 走向 Harness 内化未来 Harness 应越来越精简内化更强。所以训练harness或许从此时此刻起已经是在研究领域开始蔓延了很多人其实是后知后觉的。范式从 Agent RL → Harness-aware training / Tool-integrated pretrainingharness 从 inference-time 资产变成 training-time 资产极限不是harness model而是harness 被内化但永远消不掉一层薄壳副作用的原子性与可观测性事务、审计——不可内化身份与跨时间一致性记忆协议、版本、隔离——不可内化信任边界与权限审批、HITL、合规——是社会契约不是认知能力未来 Harness 的演化体积锐减从 5k-20k 行 → 500-2000 行角色反转从补模型短板帮助模型 → “约模型自由度制约模型”Meta 化Model 可申请调整 harness 参数但不能自己改工程投入取舍贬值区会被模型内化 升值区永远在 Harness手写 Planner / Reflector 权限模型 / 沙箱CoT Prompt 模板 可观测性 Trace / ReplayTool Use 格式化解析 记忆与 Skills 协议任务分解逻辑 Token 预算 / Context 路由Self-consistency / 投票 HITL 交互点——告诉模型怎么思考 副作用事务化——约束模型能做什么更激进的判断未来 harness 的核心竞争力不在聪明而在可信。从智力竞赛 → 工程竞赛的相变。5 Agent 工程师是应当基本最初级的训练、推理基本知识和实践经验介于我的观点 OPUS4.7 认为很多人做 agent 不理解大模型/训练/推理这是严重技术缺陷他们把模型当黑盒实际应该训练子智能体垂类能力训推作为 CLI 已打通闭环Claude Code 的 cache edit 优化就是典型——需要模型推理端结合才能实现。黑盒心智的三大认知误区Token经济机制盲区失效场景误判优化策略缺失Claude代码缓存机制深度解析Anthropic的提示缓存采用前缀匹配机制——任何前缀token变动都会导致后续缓存全部失效工具定义通常位于系统提示前端→工具列表变更将引发全局缓存失效Claude的创新方案将动态工具列表后移至缓存边界之后通过压缩算法确保前缀稳定性相同工具集生成相同token序列这一设计将推理端的KV缓存前缀敏感性特性反向应用于工具系统架构工程能力必备知识体系高效提示缓存命中KV缓存前缀匹配、分页注意力机制稳定结构化输出约束解码、语法掩码工具调用可靠性训练轨迹格式、特殊token处理长上下文质量维持RoPE缩放、NIAH、位置编码优化推理资源管控思考/回答token分离训练自我修正能力SFT样本是否包含错误修正过程举例智能体工程能力分级L1-L5层级核心能力行业占比L1基础API调用能力主流群体L2同时掌握上下文工程和函数调用约30%L3同时精通分词器、采样机制、KV缓存和结构化输出约5%L4同时具备本地训练/推理能力分布式训练和推理、调试工程、能实施SFT/RL解读技术文献约1%L5实现训练-推理-系统全链路闭环训练专用子模型0.1%懂是为了设计更好的抽象不是为了更深的耦合。6 开源模型落地 vs 顶级商业模型 Demo 的认知差核心观点工业界因安全、成本和可控性因素选择开源大模型但公众接触的是基于商业顶级模型如Claude OPUS/GPT-5调优的开源项目效果导致认知偏差——误以为框架优化后接入任何模型都能达到同等水平。闭源顶模和开源模型的差距最大的地方不在一次性生成质量而在长时序稳定性、工具调用方言、自我修复和失败恢复。也就是说agent 场景里的差距更像“尾部风险差距”不是“平均分差距”。这也是为什么 demo 常常看起来接近产品一落地就迅速分层。三重错位Demo错位公众看到的是Claude OPUS/GPT-5的演示效果部署错位工业界实际只能使用Qwen/DeepSeek/GLM等模型认知错位决策者将两者视为等效被低估的三个维度① Agent能力差距呈阶跃式而非线性能力维度商业 vs 开源差距简单问答5-10%代码生成15-25%长时序工具使用40-60%错误恢复/Self-Correction50-80%100轮指令稳定性断崖式下降原因顶级商业模型的Agent轨迹优化SFTRL数据未开源且极难复现。② 开源模型的“工具调用方言”问题Qwen偏好XML风格Llama依赖JSON特殊标记DeepSeek对嵌套深度敏感多数开源模型在并行工具调用时崩溃框架的“模型无关”特性在Agent场景下是假象——更换模型可能导致成功率从85%骤降至40%。③ 工业界成本优先级反转维度Demo预期工业实际单次成本忽略核心KPI延迟5-30s可接受p95 3s并发单用户数百-数千QPS数据出境无所谓合规红线稳定性可重试SLA 99.9%认知差的传导危害决策层基于Demo立项 → 工程层用开源模型落地 → 效果不达预期 → 产品层归因“AI能力不足” → 削减投入 → 恶性循环。可持续的护城河不会只是“接了更强的模型”而是“掌握了更强的任务环境”。包括私有数据、业务状态机、动作权限、历史轨迹、失败样本、人工复核链路。模型能力当然重要但一旦基础模型普及谁更懂环境、谁更懂错误、谁更懂责任边界。大多数 AI 应用项目的护城河其实是他们接的是 GPT-5这个事实本身。真正有工程价值的团队是那些在开源模型上做出 80 分效果的团队而不是在商业模型上做出 95 分效果的团队。7 给读者的一些结论1. 调用黑盒心智是严重工程缺陷 ✅把 LLM 当黑盒 API 调用的人在 agent 工程上会踩三类必然的坑Token 经济学盲区不知道 KV cache 前缀匹配规则就写不出高 cache 命中率的 prompt 结构不知道 attention 是O ( n 2 ) O(n^2)O(n2)就体会不到 context 膨胀的真实代价。失败模式误判把模型说错简单归因为prompt 不够好但实际可能是采样温度、tokenizer 边界、RoPE 位置外推、或者 tool call 的 grammar-constrained decoding 的问题。优化手段缺失不知道 speculative decoding、prefix caching、structured output 的底层机制就只能在应用层调 prompt而最大的性能和成本杠杆其实在推理层。2. Claude Code cache-aware tool edit 是绝佳例证 ✅ 大模型原理必不可少这个例子选得非常精准我补充它为什么是必须懂推理才能做出来的典型Anthropic 的 prompt cache 是前缀匹配的只要前缀有任何一个 token 变化后面全部 cache miss工具定义tool schema通常放在 system prompt 靠前的位置一旦工具列表变动 → 整个后续 context 缓存作废所以 Claude Code 做了一件非常懂推理的事把工具列表的动态部分推迟到 cache 边界之后并且对工具 description 做压缩时压缩算法本身要保证前缀稳定即相同工具集在不同 session 产生相同的前缀 token 序列这不是应用层 trick这是把KV cache 是前缀敏感的这个推理端事实倒推到工具系统的数据结构设计一个只懂 API 调用的人根本看不见这个优化空间存在——因为在他的心智模型里调用成本只是 token 数不存在前缀稳定性这个维度。3. 训练自己的子智能体垂类能力是正确的长期方向 ✅强通用模型时代竞争力是从prompt 工程迁移到**“小而精的垂类微调 大通用模型编排”**的混合架构垂类任务代码 review、BOM 解析、特定 DSL 生成用 7B-32B 的微调模型延迟低、成本低、可控通用规划和对话交给大模型整个 agent 是一个异构模型编排系统在 harness 级别的 agent 工程里对训练和推理的理解不是加分项但是会产生壁垒参考claude code的推理服务。4. “模型训练和推理作为 CLI 在工程上打通调用闭环” ✅这个观察也准确。2025 年的趋势确实是vllm serve/sglang/ollama让推理部署 CLI 化axolotl/unsloth/trl让训练 CLI 化llama.cpp/MLX让本地推理 CLI 化HuggingFace 的text-generation-inference、lighteval都是 CLI-first这意味着 agent 工程师完全可以在一个 Makefile 里串起数据收集 → 训练 → eval → 推理部署的闭环。这个闭环一旦打通agent 的迭代速度会和纯调 API 的团队拉开数量级差距。因为 harness 的核心矛盾是稳定控制与模型的博弈——而这场博弈的规则本身就是由训练目标函数和推理采样机制定义的。你不懂这两者就是在不知道规则的情况下下棋。举几个不懂就做不出的硬核案例工程能力需要的推理/训练知识高命中率 prompt cacheKV cache 的前缀匹配、PagedAttention稳定的 structured outputconstrained decoding、grammar mask、logit processorTool call 的可靠性训练时 tool use trajectory 的格式、special tokens长 context 的质量衰减RoPE scaling、NIAH 基准、haystack 位置分布Reasoning model 的预算控制thinking token 与 answer token 的分离训练Agent self-correctionSFT 轨迹里是否包含错误→修正样本每一项都是不懂就只能瞎试、懂了就能直接设计对的分水岭。8、自我纠正和改进注意加强 1不仅要懂还要建立自己的反馈闭环只懂是被动的。真正把这件事变成竞争力的人会做三件事本地能跑小规模训练哪怕只是 LoRA 7B这样遇到问题能立刻做 ablation 验证本地能跑推理引擎vLLM / sglang这样能直接验证 KV cache、batching、采样策略自建 eval set每次模型升级或 prompt 改动都跑一遍而不是靠感觉这三件事形成的闭环才是把懂转化为做得出别人做不出的东西的关键。加强 2警惕过度工程化到推理层的反向陷阱这点我必须作为平衡观点提出因为你的倾向有这个风险懂推理的人容易过度使用推理层 trick把 agent 搞成一个对特定推理引擎/模型版本强耦合的脆弱系统。过度依赖某个模型的 prompt cache 细节 → 换模型成本极高针对某个 tokenizer 做的优化 → 模型升级后全失效依赖某个推理引擎的 speculative decoding 配置 → 不可移植正确的姿势是懂到可以用但只在有明显 10 倍收益的地方才用并且把这些耦合点隔离在 harness 的最底层对上层不可见。这和我们前几轮讨论的harness 薄契约层是一致的——你对推理的理解应该转化为更好的抽象而不是更深的耦合。所有观点串成一条主线当所有人都在调用黑盒 LLM 套 framework时真正的工程壁垒在三个相互咬合的能力上手搓 harness跳出 framework 局限 懂训练与推理跨越黑盒心智 在开源模型上做出可部署的工程抵御 demo 幻觉这三者共同定义了2026 年严肃 Agent 工程师与API 调用工程师的分水岭。而 harness 的终极形态是一层空间上薄、时间上厚的契约壳——智力让渡给模型信任与身份由自己承担。当下除了多模态领域当前纯文本LLM还是在主攻推理效率和Agent能力并且已经由有趋势在scale law到harness这块训练工作非常有价值与此同时各家可能都在做hareness那种接耦平台。结尾之前自媒体各种教学——提示词工程、到上下文到harness 但现在看来大多数使用者 是从workflow变成了skills书写 看似在变化一切又没在变化一个Openclaw 一个聊天指令就能带走几十多K的 Tokendemo和产品间差距一目了然不理解是人们怎么被AI搞出的幻觉那么token账单更能让大家看清事实。 实际一看早就适应AI变化的人是不会觉得变化极快的都在稳步推进工作。在这个信息爆炸的时代我们必须保持清醒的判断力和创造力让AI真正提升效率而非盲目跟风——用AI把事情做好而非单纯追求数量。