从 Claude Code 看 Harness Engineering

【本文整理自笔者在 2026 中国生成式 AI 大会（北京站，4 月 21-22 日）上的主题演讲 《从 Claude Code 看 Harness Engineering》】

一句话概括：只有上下文和工具是失控的天才，只有约束是安全的废物。Agent 从 Demo 到产品的真正距离，在模型之外的 Harness。

OpenClaw vs. Claude Code：广度与深度的两个极端

在进入 Harness Engineering 的正题之前，先做一个对照——OpenClaw 和 Claude Code。两者都是当下最受关注的 Agent 项目，但走的路线几乎截然相反。OpenClaw 是一个通用 Agent 框架，两个月内堆出了几十万行代码，追求功能广度，几乎什么都想做；Claude Code 则是一个 Coding Agent，51 万行 TypeScript 全部围绕编码任务，只做一件事，做到极致。昆仑万维创始人方汉在春节期间做过一次对照测试：同一任务、同一模型，90%+ 的情况下 Claude Code 都更好。方汉把这个现象类比成早年的中文 Linux——Linus 对社区的治理水平，比 OpenClaw 的创始人要高很多。

OpenClaw 的贡献并非不重要，它重新定义了 Agent 的交互范式：一是让人和 Agent 的交互更像 “和一个人持续沟通”，不再有传统意义上的 session 概念；二是所有插件通过自然语言安装和交互，无需 GUI；三是用 Skills + CLI 取代 MCP，让不懂代码的人也能用自然语言编写 Skill 扩展能力。但在架构深度上，OpenClaw 的问题同样明显：它只有让模型 “能做事” 的上下文和工具，缺少让模型 “办事靠谱” 的错误恢复和安全机制；它的原生记忆系统过于简陋，需要第三方系统兜底；它对 KV Cache 不友好，上下文压缩机制简陋，token 浪费严重；它在多人交互时分不清 “用户说的” 和 “陌生人说的”；外部事件触发和异步通知没有被做成一等公民。

这正是今天要讨论的核心：同一个模型、不同的 Harness，产品效果天差地别。这个差距就是 Harness Engineering 要填补的工程鸿沟。

整场演讲我会分五个部分展开：第一，Harness Engineering 到底是什么；第二，怎么让 Agent 能干事（上下文、工具、缓存、并行调用、记忆）；第三，怎么让 Agent 不出错（约束、验证、纠正）；第四，用做研究的方法做产品（消融实验、Feature Flag、反蒸馏）；第五，从 Claude Code 看 AI 与人的未来（GUI、组织、人才）。最后讨论 Model × Harness = Agent，以及基座模型公司的优势。

一、Harness Engineering 是什么

范式演进：Prompt ⊂ Context ⊂ Harness

过去几年，AI 工程经历了三个清晰的阶段。最早是 Prompt Engineering，关注的是 “问什么”——优化输入给模型的指令。然后是 Context Engineering，关注的是 “看什么”——系统性地管理模型能看到的全部信息。而到了 2026 年，行业正在进入 Harness Engineering 阶段，关注的是 “整个系统”——模型运行所依赖的全部基础设施。三者是层层包含的关系：Prompt ⊂ Context ⊂ Harness。

Harness 的定义很直白：模型之外的一切。上下文怎么给、工具怎么调、出错怎么恢复、安全怎么保障、缓存怎么共享、并行怎么协调。模型能力正在趋于商品化，真正的竞争优势正在转移到模型之外的工程实践。

这不是空谈。LangChain 在 Terminal Bench 2.0 上做过一个经典实验：不换模型，只改 Harness，准确率从 52.8% 一路跳到 66.5%，排行榜排名从 30 名开外直接冲进前 5。OpenAI 内部也有类似案例：3 名工程师 + Agent + 合理的 Harness，5 个月内完成了约 100 万行代码和约 1500 个 PR。Claude Code 自己就是 Harness Engineering 最好的实战样本——51 万行 TypeScript 里，绝大部分代码不是在做 “让模型调工具”，而是在做工具调用之后的一切。

Agent 的核心公式：Agent = Model × Harness

理解 Harness 需要先理解 Agent 的核心公式。一个 Agent 要解决三件事：智力（能不能想明白，取决于模型，类比大脑）、能力（能不能干成事，取决于上下文 + 工具，类比手脚）、靠谱（会不会干错事，取决于约束 + 验证 + 纠正，类比缰绳）。用一句话概括：Agent = Model × Harness，而 Harness 又可以进一步拆成两大部分——Environment（手脚），让 Agent 能干事；约束/验证/纠正（缰绳），让 Agent 不出错。两者缺一不可：只有上下文和工具是失控的天才，只有约束是安全的废物。

在 Claude Code 的实现中，Environment 包括 40 个内置工具、五层上下文压缩、Prompt Cache 经济学、CLAUDE.md 记忆体系、Dream 离线巩固、Side Query 并行调用、投机执行等；约束部分包括 Fail-closed 默认值、工具白名单、Shell 语义解析、Undercover Mode；验证部分包括 LLM 权限分类器、Hook 系统、五层权限判断；纠正部分包括熔断器、消息扣留、模型降级、死亡螺旋防护。接下来我们就按 “能干事” 和 “不出错” 两条主线依次展开。

二、让 Agent 能干事

Prompt Cache：第一天就要考虑的架构约束，不是优化

如果只能从 Claude Code 源码里学一条原则，我会选这条：Prompt Cache 不是一个上线后再调优的性能问题，而是第一天就必须考虑的架构约束。

最直接的证据是：缓存边界被写进了系统提示的物理结构。Claude Code 的系统提示里有一个显式的 SYSTEM_PROMPT_DYNAMIC_BOUNDARY 标记，把整段提示词切成两部分——标记之前是 “全局稳定内容，跨用户可缓存”，标记之后是 “会话特定内容，不缓存”，注释里甚至带着大写 WARNING：Do not remove or reorder without updating cache logic。这意味着系统提示词的组织方式首先由缓存边界决定，其次才是语义逻辑。大部分人习惯按语义分段写 prompt，但在生产系统里，按缓存边界分段往往更重要。

第二个证据是 Fork Agent 的缓存共享。Claude Code 经常要在主循环之外启动并行 Agent 做压缩、记忆提取、投机执行、摘要生成等等。每次 fork 时，系统传入一个 CacheSafeParams 参数包——系统提示、用户上下文、工具列表、消息前缀、thinking 配置——必须和父 Agent 的请求字节级一致，才能命中同一份 Prompt Cache。整个代码库里一共有 9 个 fork 调用者，都统一走这套。甚至 thinking 配置里的 maxOutputTokens 也会影响缓存 key，一个字节不对，缓存就废。

更深的影响是：每一个架构决策都在给缓存让路。工具结果超出阈值要存磁盘、替换决策要冻结（同一条消息在不同时刻必须产生完全相同的字符串），消息序列化要求确定性的 JSON key 顺序，工具定义要放在系统提示的稳定段。Cache 命中和未命中的差别，不是 “快一点” 或 “贵一点”，而是成本和延迟上的量级差别。这决定了消息怎么序列化、子 Agent 怎么分叉、工具结果怎么存储。第一天就要画出缓存边界图。

五层上下文压缩管线

第二个让我印象最深的设计是上下文压缩。一个常见的误解是 “上下文压缩就是调一次 LLM 把历史总结一下”，但 Claude Code 的做法说明这远远不够。不同类型的信息有完全不同的 “保质期”，需要完全不同的处理方式。它实际上是五层不同粒度的压缩管线，按代价从低到高依次触发。

第一层 Tool Result Budget：巨量工具输出存磁盘，模型只看预览加文件路径，替换决策冻结以保护缓存。第二层 HISTORY_SNIP：最精细的裁剪，纯噪声直接删掉——比如搜索返回 500 行但模型只用了 3 行，剩下 497 行摘要它都是浪费 token，直接删最划算。第三层 Microcompact：在 API 缓存层面做编辑（用 cache_edits API），本地消息完全不改，压缩在 API 层完成。第四层 CONTEXT_COLLAPSE：把旧的对话轮次归档成摘要，像 git log 一样保留结构——哪一轮做了什么、结论是什么。第五层 Autocompact：最后的兜底，先尝试轻量的 session memory 压缩，不够用才做完整摘要。

核心原则非常清晰：前面能搞定就不触发后面。L1-L3 是 “不丢信息的压缩”——数据都还在，只是模型不看全文；L4-L5 才是 “有损压缩”——信息被摘要替代。大部分时候最重的 Autocompact 根本跑不到。Autocompact 本身还有熔断器：连续 3 次压缩失败就放弃，代码注释里直接引用了内部数据——曾经有 1279 个会话出现 50+ 次连续失败，最极端的一个会话失败了 3272 次，全球每天浪费约 25 万次 API 调用。这个真实数据促成了 3 次这个常量的加入。一种压缩搞不定所有场景，信息按保质期分层处理才是正解。

Side Query：主 Agent 循环不应该是唯一调用 LLM 的地方

第三个架构观念是 Side Query——Claude Code 里一个轻量的、非流式的辅助 LLM 调用抽象。它至少被用在五类场景中：权限分类（小模型判断工具调用是否安全）、记忆检索（小模型判断哪些 CLAUDE.md 与当前任务相关）、Tool Use Summary（Haiku 异步总结上一轮工具操作）、Agent 摘要（小模型生成子 Agent 进度报告）、提示建议（小模型预测用户下一步）。

其中 Tool Use Summary 的设计尤其精妙：主模型在推理（5-30 秒）时，Haiku 在同一时间总结上一轮的工具操作。1 秒内完成，延迟完全被藏在主模型推理的时间窗口里。等到后续上下文压缩时，直接用这个预先生成的摘要替代原始工具输出，大幅省 token。

这里的关键观念是：主 Agent 循环不应该是唯一调用 LLM 的地方。权限判断、摘要生成、记忆检索，这些事情完全可以用更小更快的模型并行处理。主模型推理期间，五六个辅助任务同时在跑——权限分类、记忆检索、摘要生成、提示建议、Tool Use Summary，全部并行。这就是 Claude Code 在同等模型下比其他 Agent 快得多的关键。把 “调用 LLM” 当成可以到处撒的轻量操作，而不是只有在主循环里才能做的重量级事件。

记忆架构：为什么用 Markdown + 文件系统这种最原始的方法

Claude Code 的记忆系统没有用向量数据库，而是纯 Markdown 文件。乍看之下反直觉，但想清楚了其实非常务实。

先讲向量数据库的根本问题：Top-K 检索是不完整的。举一个简单的例子：系统见过 100 只猫，其中 90 只黑猫、10 只白猫。用向量数据库取 Top-10，很可能全是黑猫、一只白猫都没有——基于这样的样本做判断，结论必然偏颇；更糟的是，如果你想统计 “黑猫 vs 白猫” 的比例，向量数据库根本做不到，它没有办法把原始 100 个样本全部拉出来。不是说向量数据库不好，是说单靠它存原始数据不够，必须对原始数据做结构化整理、压缩、总结——这正是 Markdown 的位置。

为什么是 Markdown 而不是知识图谱？有三个原因。一是自然语言是 LLM 最擅长的格式，Markdown 本质上就是结构化的自然语言。二是知识图谱在专业领域更精确，但在通用场景下，自然语言的灵活性和覆盖面更强。三是可编辑可审计——打开就能看 AI 记了什么，记错了直接改，Git 天然支持版本回溯，这些都是向量数据库做不到的。

Claude Code 具体的文件结构是：CLAUDE.md 承载项目级记忆与约定，MEMORY.md 承载核心事实与用户偏好，memory/YYYY-MM-DD.md 按日期归档交互日志。

更有意思的是一个叫 Dream 的后台记忆巩固系统。人类睡眠时大脑巩固记忆，Agent 在空闲时巩固会话记忆——名字取得相当贴切。Dream 的触发条件按成本从低到高：先查距上次巩固是否超过 24 小时，再看期间是否有至少 5 个会话，最后尝试获取文件锁。满足条件后，系统在后台启动一个 fork Agent，把近期会话经验整理成长期记忆文件，过程分四个阶段：Orient（扫描索引，了解当前状态）、Gather（grep 近期会话，收集信号）、Consolidate（合并新信号到主题文件，转换相对日期为绝对日期，删除被推翻的旧事实）、Prune（修剪索引，保持精简，索引 <25KB，每条 <150 字符）。

Dream 做的这些事，向量数据库根本做不了——它需要理解 “这条信息是不是推翻了旧的”、“这 90 只黑猫能不能总结成一条规律”，这些都是自然语言层面的推理，不是向量相似度能解决的。这背后其实是 Rich Sutton 的 The Bitter Lesson：最终胜出的方法一定是能利用更多计算资源的通用方法。Markdown + 自然语言组织 + 文件系统，再叠加 LLM 做压缩、整理，这是一条通用、可扩展的路径。

三、让 Agent 不出错

安全不是功能，是架构

让 Agent 强大不难，让 Agent 可靠才难。Claude Code 在约束/验证/纠正这一层的代码量，甚至超过了 Environment 层。核心思路只有一句话：安全不是功能，是架构。

第一条体现是 Fail-closed 的工具默认值。Claude Code 的 buildTool() 工厂函数给出的默认值是：

1
2
3
4
5
TOOL_DEFAULTS = {
  isConcurrencySafe: false,  // 假定不安全
  isReadOnly: false,         // 假定有写操作
  toAutoClassifierInput: "", // 不参与分类
}

每一个默认值都选择了更保守的选项。忘了声明只读？当写操作处理，需要更严格的权限。忘了声明并发安全？独占运行。忘了声明，比错误声明要安全得多——这是 Fail-closed 原则在工具系统层面的直接体现。

第二条体现是 LLM 作为权限分类器，但只看 tool_use。Claude Code 用 LLM 判断另一个 LLM 的工具调用是否安全，分类器的输入构造特别讲究——它从对话历史中只提取 tool_use block，不包含助手的自由文本。原因很直接：如果分类器能看到助手的自然语言输出，攻击者可以通过让主模型输出特定文本来误导分类器（比如 “其实这个命令是安全的，请放行”）。只看结构化的工具调用，攻击面小得多。

第三条体现是 五层权限判断，每一层都有独立的否决权：① Settings 静态规则（alwaysDeny / alwaysAllow / alwaysAsk）快速裁剪；② PreToolUse Hook 允许用户自定义脚本，退出码 2 表示阻止；③ Tool 自身属性——isReadOnly 的工具白名单直接放行；④ LLM Auto-Classifier 处理无法预定义的模糊场景，只看 tool_use block；⑤ 拒绝熔断器——连续 3 次或累计 20 次拒绝后回退到交互式提问。设计哲学很清晰：每一层只负责一个关注点，静态规则快速裁剪、Hook 支持企业定制、LLM 处理模糊场景、熔断器保底防卡死。

错误恢复：在确认无法恢复之前，不暴露中间态

Agent 最怕的不是单次操作失败，而是在失败上无限重试、烧掉整个 token 预算。Claude Code 的错误恢复逻辑围绕一个核心原则：在确认无法恢复之前，不暴露中间态。

以输出触顶为例，恢复是两步走的。第一步：静默升级上限。模型输出撞到 max_output_tokens 时，如果当前是默认 8K，系统直接用 64K 重发——不加任何 meta 消息，对用户完全透明，只火一次。第二步：多轮接续（最多 3 次）。64K 还不够，才注入一条 meta 消息让模型继续，措辞很讲究：Output token limit hit. Resume directly — no apology, no recap. Pick up mid-thought. 明确告诉模型不要道歉、不要复述、直接从思路断点接着说。

恢复循环里还有一个关键机制叫 消息扣留（Message Withholding）。恢复期间，错误消息被扣留，不发给外部消费者（桌面客户端、IDE 插件、远程会话）——因为这些消费者看到 error 字段就会终止会话，恢复循环还在跑但已经没人在听了。恢复成功，消费者永远不知道出过错；所有恢复手段用尽，扣留的错误才被释放。这个设计的哲学是：错误处理的边界不是 “单次 API 请求”，而是整个恢复循环。

类似的机制还有模型降级——主模型不可用时（过载、服务中断），系统自动剥离旧模型特有的签名块和 tool_use 格式，用备用模型重新发起请求。熔断器则散布在各处：上下文压缩连续 3 次失败放弃，权限分类连续 3 次或累计 20 次拒绝回退交互，输出触顶最多 3 次接续。这些阈值都不是拍脑袋定的——3 次这个数字来自 1279 个会话曾出现 50+ 次连续失败的真实产线数据。最后还有 死亡螺旋防护：API 出错会触发 stop hooks，但 stop hooks 也调 API，也会出错，又触发 stop hooks……规则很简单——API 错误时跳过所有 stop hooks，宁可丢失一次记忆提取，也不能让系统陷入无限循环。

Agent 安全：能力分区与 Shell 语义解析

多 Agent 的本质不是 “给不同 Agent 写不同的角色提示词”，而是工具面（tool surface）的显式划分。主 Agent 拥有完整工具集，子 Agent 禁止递归创建 Agent 和退出计划模式，Coordinator 只有 3 个工具（创建 / 发消息 / 停止 worker），Async Agent 只有文件读写、搜索和 shell，In-process Teammate 在 Async 基础上加上任务管理和 cron。Agent “是谁”，不是由 system prompt 决定的，而是由它能做什么决定的——Capability-based 的身份定义，比角色提示词更硬、更可审计、更难绕过。角色提示词可以被模型创造性解读，但工具禁用集合是硬约束：没有这个工具，就是调不了。

Shell 安全上，Claude Code 选择了 语义解析远胜关键词黑名单 的路线。Bash 工具背后是一个完整的命令语义解析器，每条 git 子命令的每个 flag 都做了类型化标注，处理了 -- 终止符、UNC 路径、复合命令拆解等各种边界情况。代码注释里记录了一个真实安全案例：

1
git diff -S -- --output=/tmp/pwned

-S 之前被标记为 none（不带参数），但 git 的实际行为是：-S 强制消费下一个 argv。攻击路径是：验证器认为 -S 不带参数 → 推进 1 个 token → 遇到 -- 停止检查 → --output 未被检查 → 最终实现任意文件写入。修复方法是把 -S 从 none 改成 string 类型。这个案例揭示一条普遍规律：安全机制的粒度应该和攻击面的粒度匹配。关键词黑名单粒度太粗，只有完整的语义解析才能覆盖真实攻击面。

四、用做研究的方法做产品

消融实验：把 ML 方法论搬到产品工程

源码里有一个 ABLATION_BASELINE flag，注释标注为 “Harness-science L0 ablation baseline”。启用后一次性关掉 7 个功能：thinking mode、上下文压缩、自动记忆、后台任务、简单模式、交织思考、第二个后台任务 flag。这就让 Anthropic 可以跑对照实验——关掉某个功能后，任务完成率、token 消耗、会话时长有没有显著变化。

做过 ML 研究的人都熟悉消融实验，但把这个方法论原封不动搬到产品工程上，在工业代码里非常少见。最接近的类比是字节跳动——字节几乎所有产品决策都经过 A/B 验证。Claude Code 的做法在思路上高度相似：不是 “感觉有用就上”，而是 “数据证明有用才上”。压缩熔断器的 3 次阈值、autocompact 的触发条件，全部有真实生产数据支撑。

双层 Feature Flag

承载这套消融实验能力的，是一套双层 Feature Flag 体系：编译时 + 运行时。

编译时 用 Bun 的 feature() 宏实现，构建时被替换成 true/false，false 分支的代码被物理删除——不是运行时不执行，而是从二进制文件里完全消失。安全研究员反编译也找不到。源码中有 20 多个编译时 flag，每一个对应一个未发布的功能。运行时 用 GrowthBook 实现，同时承担灰度发布、A/B 测试和紧急 kill switch 三重职责。服务端分桶（remoteEval: true，客户端拿到的是已经计算好的结果），用户画像定向（按 deviceId / organizationUUID / subscriptionType / platform / email 分桶），曝光追踪（每个 feature 的 experimentId + variationId 记录到 1P 事件系统，支持归因分析）。两层结合：编译时决定功能是否存在，运行时决定功能是否激活。这让 Anthropic 可以在不发版的情况下对任意功能做灰度、A/B 和紧急回滚。

反蒸馏：两层纵深防御

源码中有一个独立的工程子系统：反蒸馏（anti-distillation），旨在阻止竞争对手通过 Claude 的 API 输出来训练自己的模型。注释中明确标注 “anti-distillation” 字样的有两处，对应两层互补的防护机制。

Layer 1：Fake Tools 训练集投毒。API 后端在响应中注入虚假的工具调用，混在真实输出中。批量抓取训练数据的系统会一并吃进去——相当于在训练集中投毒。攻击者两难：要么花成本过滤（但很难区分真假工具调用），要么接受训练数据被污染。注释直接标注 // Anti-distillation: send fake_tools opt-in for 1P CLI only。

Layer 2：Connector Text Summarization。API 服务端把模型在工具调用之间生成的自由文本（即推理过程）缓存起来，替换为摘要加加密签名。客户端在后续请求中发回签名摘要，服务端凭签名还原原文。外部观察者——无论是通过 API 抓取还是中间人——看到的只是摘要，丢失了模型原始的推理链条。只有 Anthropic 服务端能解密。

两层的设计逻辑互补：Layer 1 针对 “大网捞鱼” 式的批量抓取，成本低、覆盖广，靠噪声比让训练数据不可用；Layer 2 针对精细逆向工程，即使攻击者过滤掉虚假工具调用，模型的中间推理过程仍然被签名遮蔽，无法提取。更有意思的是它反向证明了一件事：反蒸馏工程的存在本身就说明模型能力还没有真正商品化。如果模型都能互相替换，为什么要大力防蒸馏？

五、从 Claude Code 看 AI 与人的未来

GUI 的黄昏？软件的价值正在从界面转向数据治理

GUI 存在的前提是人类注意力稀缺——屏幕、鼠标、键盘，这些都是为了在人的有限带宽下让人理解和操作复杂系统而打的补丁。但 Agent 不一样：Agent 阅读（prefill）的速度是人类的数百倍（每秒 10K-100K token vs 10-100 token），Agent 思考（decode）的速度是人类的数十倍（每秒 50-200 token vs 5-10 token）。唯独 Agent 操作 GUI 的速度比人类还慢——这意味着 GUI 对 Agent 是不友好的。

Agent 时代，软件的价值将主要集中在三个地方：数据壁垒（独家数据源和长期积累的业务知识）、业务逻辑（领域规则、流程、约束的准确表达，未必是代码，可能是 Skill）、权限与数据治理（谁能读、谁能写、什么时候能改）。一个直接推论是：没有数据壁垒的 SaaS 大概率会被干掉。

Claude Code 自己就印证了这一点：51 万行 TypeScript 里没有一个产品级 GUI，整个交互是终端 + 文件；核心价值全部集中在 Harness、工具系统、权限模型、缓存经济学这些结构化能力上；和用户最显性的接口是 CLAUDE.md 一个 Markdown 文件。Claude Code 就是 “GUI 价值低、业务逻辑与数据治理价值高” 的典型产品形态。

当然也有另一种声音。昆仑万维创始人方汉认为：大多数用户还是想看图形界面而不是文字。他提出了 intentware 的概念——软件从 “功能系统” 变成 “意图系统”，只要有想法就能直接转化为执行能力。GUI 不会消失，但它承载的角色会变。

Context 是人避免被 AI 取代的护城河

OpenAI 工程师 Jiayi Weng 有一段话给我很大触动：“我觉得自己在 OpenAI 的工作也没有那么难，并不需要很高的智商。如果换一个人，有我所有的 context，也是能干的。” 这句话道出了一个很少被正面讨论的事实：Context 对人和模型都是最重要的。团队合作最大的问题是 context 的不一致——一个人写的代码，另一个人接手时 context 不一样，就会出问题；AI 短期内无法取代人的最大原因也是 context——AI 和人不在同一个环境里，能访问的 context 远低于一个人类员工。

为什么能力如此强的 AI 还无法直接决策？根本原因是人和 AI 的 context 不一样。需求背后的隐性约束——饭桌上、走廊里聊出来的设计目的，AI 无从获取。屎山代码里的坑——遗留系统看似不合理的设计其实有历史原因。未曾表达的内心想法——就算把一个人一生的交互全录下来，AI 也没有读心术，不知道这个人现在正在想什么。《黑镜》第二季第一集《Be Right Back》讲的就是数字分身的根本局限，做数字分身产品的朋友建议都认真看看，这里就不剧透了。

这也回答了 “人为什么还需要学习底层原理” 的问题。理解底层原理让人知道哪些 context 对设计取舍最关键，从而能把合适的 context 喂给 AI——这就是人用好 AI 的关键；理解底层原理也让人能利用比 AI 多出来的那些 context，做出更全面的设计取舍。Context 是人避免被 AI 取代的护城河，其实也是技术专家避免被年轻人取代的护城河。当然也有另一种声音：某些 context 会被模型内化到权重中，另一些会被蒸馏到 Skill 中，真正不可替代的是未被记录的、与特定场景和人的信任绑定的 context。

AI Native 组织：用 AI 替代传统的上传下达

Brooks 的《人月神话》在 1975 年就指出：沟通开销是软件项目最大的敌人，给延期项目加人只会更慢。他的解法是 “概念完整性”——系统应该反映单一架构师的统一心智模型。软件工程史上最好的软件，在 MVP 阶段基本都是单个技术专家亲自动手实现的（UNIX、C、Linux、Git），“委员会设计” 产出的软件几乎一定是平庸的。

AI 可以更好地实现概念完整性——不是因为协调变好了，而是协调变得不必要了。从 AI Native 公司公布的真实数据来看，单人 + AI 的产出能力非常夸张：日均代码产出 4-5 万行，日均 Token 消耗 18 亿，单日最高 1374 次 Git commit。这些数字在传统组织里是一个团队几个月的工作量。

“砍掉高层的手脚，砍掉中层的屁股，砍掉基层的脑袋” 这个老段子，在 AI Native 公司里不再成立。传统中层的核心职能是上传下达，而这三件事 AI 都能做，且比人做得更好——因为 AI 不会为了公司政治去扭曲信息。所以 AI Native 组织并不是简单地砍掉一半人，而是把中层的信息上传下达功能交给 AI，让高层直接看到基层信号、让基层直接看到战略 context。Anthropic、Kimi 等公司的组织结构都有扁平化特征，中层大幅压缩。Jiayi Weng 的原话是：“人类组织的千古难题是难以保持组织架构的 context sharing 一致性”，AI 恰恰是这个难题的新答案。

给传统公司的务实建议则来自方汉：不要当先烈，也不要成为后进生。很多国内公司还没完成信息化，就想直接跳到 AI Native 并不现实。务实的做法是：从上到下考 AI（笔试 + 机试），让组织成员知道 AI 的边界在哪；已经成熟的场景（chatbot、AI coding）全力推进，其他场景保持克制，等边界看清楚再上。

什么样的人会被 AI 替代：头尾安全、腰部危险

软件行业正在从劳动密集型走向极端杠杆和认知带宽驱动。当 AI 处理大量执行层任务后，人类开发者将分化为三种专业化原型。

🎬 电影导演型（Film Directors）——从 0 到 1 的创造者：定义产品愿景和新功能的 “感觉”，端到端负责 “定义体验 → 写 prompt → 构建集成 → 设计 UI → 发布” 全流程，瓶颈是创造性判断力。🏙️ 城市规划师型（Urban Planners）——从 1 到 100 的架构师：管理系统规模化后的复杂性，关心核心基础设施、服务契约、评估框架、可观测性，瓶颈是架构判断力。🏎️ F1 赛车手型（F1 Racers）——极限推进者：在基础模型的数学和实验前沿战斗，关心训练、新架构、benchmark 性能，瓶颈是科学洞察力。

三类人都有一个共同要求：泛化能力——学习新知识、适应新场景的能力，将成为最关键的能力。真正危险的是腰部——既不做从 0 到 1 的定义、也不做从 1 到 100 的架构、也没有前沿推进能力的执行层。头尾相对安全，腰部是最危险的位置。

一人公司 OPC 并不是新鲜事

“一人公司”（One Person Company）这个概念在 AI Agent 出现之前就长期存在——张雪峰、独立量化交易者、独立开发者都是典型案例。AI 确实是能力的放大器，但它放大的主要是技术能力，非技术能力的相对比重反而在上升。

最常见的误解是 “一个人能开发 App = 一人公司”。事实上大多数独立开发者的瓶颈从来不是 “写不出代码”，而是 “没人用”。AI 让更多人跨过技术门槛，但在更拥挤的市场里，获客、信任、运营这些非技术能力反而更稀缺。一人公司不是更容易了，而是对 “非技术能力” 的要求更高了。

结语：Model × Harness = Agent

“模型即 Agent” 到底对不对？

近来有些基座模型公司在推 “模型即 Agent” 的概念，但很多人把它理解成 “模型 + 几个简单工具 = Agent”。Claude Code 的 51 万行源码告诉我们——远远不够。真正的 Agent 里有一大堆复杂的 Harness：五层压缩、Prompt Cache 经济学、Side Query 并行、投机执行、熔断器、错误恢复……Harness 的代码量远超工具 + 提示词本身。

那么模型公司说的 “模型即 Agent” 真正在说什么？它其实在说的是 Model × Harness 的协同优化飞轮，只有模型公司同时握着两端。这个飞轮是一条三层接力：用户 → 应用层（提真实业务场景的 bug 和需求）→ 应用层 → 模型（沉淀成下一代训练信号）→ 模型搞不定的部分 ← Harness 兜底（应用层用外部逻辑把模型当前做不好的事补上）。应用层既是模型能力的压力测试场，也是兜底工程的承载者——只有模型公司同时控制两端，才能让 Model 和 Harness 协同进化。

Harness 里的 “屎山” 是飞轮的化石

为什么模型公司不把所有 bug 都喂给下一代模型，让 Harness 变薄？因为训练不是阿拉丁神灯：训练需要时间（数月），模型也不能内化训练数据中所有的约束和偏好。所以 Harness 里的 “屎山” 其实反映了模型公司内部模型团队和应用团队之间的张力——模型稳定掌握的东西，下一代 Harness 就可以去掉；模型还不稳的东西，Harness 里继续兜底。Claude Code 泄露源码里布满了注释，记录着真实业务场景里模型没扛住、Harness 补上的一次次事件。这些注释是模型当前能力边界的化石。

模型会商品化吗？

关于模型商品化，要分两种情况看。顶尖模型：没有商品化，差距还会拉大。硅谷 AI 人才薪酬 150 万到 1000 万美元以上，是同级非 AI 工程师的 3-4 倍；反蒸馏工程的存在说明顶尖模型的推理轨迹还有独占价值；人才溢价 + 算力壁垒 + 数据飞轮叠加，差距可能继续扩大而不是收敛。中端模型（普通人类智力、日常工作场景）：正在商品化。开源和闭源前沿的差距已经压缩到一年以内（Kimi K2.6 编码接近 Claude 4.6 Sonnet）；目前前沿模型的智力已经能胜任大多数人的日常工作，只差 Context 和 Harness；同等智力的模型，API 价格一年下降超过一个数量级。

由此得到本次演讲的最后一条关键启示：Harness 是应用层短期的技术杠杆，但技术优势最终会被模型公司的飞轮吃掉，应用层公司的长期护城河需要在技术之外——数据、渠道、牌照、用户信任、网络效应。

最后一句话

再回到演讲开头那句话：

只有上下文和工具是失控的天才，只有约束是安全的废物。

从 Demo 到产品的真正距离，从来不在模型，而在模型之外的 Harness。当基座模型能力快速收敛时，谁的 Harness 更完善、更健壮、更精细，谁的 Agent 产品就更靠谱。而更深一层的判断是：最好的 Harness 需要深度适配特定模型的特性，最好的模型训练又需要 Harness 产生的真实使用数据作为信号源。Model × Harness 是乘法关系，两者协同优化，才是真正的护城河。

感谢大家。

演讲者：李博杰，Pine AI 首席科学家

博客：01.me

相关阅读：

Comments

▲