智能体表现差异的关键：模型之上的“外壳” · AI HOT
meng shao@shao__meng60
2026-05-10 20:44·53天前
AI 摘要智能体表现差异的核心在于模型之上的“外壳”，它包括提示词、工具、上下文策略等工程组件。外壳为裸模型提供状态和执行能力，使其成为智能体。行业常将智能体失败归咎于模型，但实为可定位的配置问题。通过“棘轮”方法，每次失误都可转化为优化外壳的永久规则。没有通用的最优外壳，最佳外壳是为具体任务定制的。未来，行业焦点将从构建LLM API转向构建提供运行时环境的Harness API。
meng shao@shao__meng · X 2026-05-10 20:44·53天前
在 X 看原推· x.comAI 摘要智能体表现差异的核心在于模型之上的“外壳”，它包括提示词、工具、上下文策略等工程组件。外壳为裸模型提供状态和执行能力，使其成为智能体。行业常将智能体失败归咎于模型，但实为可定位的配置问题。通过“棘轮”方法，每次失误都可转化为优化外壳的永久规则。没有通用的最优外壳，最佳外壳是为具体任务定制的。未来，行业焦点将从构建LLM API转向构建提供运行时环境的Harness API。
新默认范式：选一个 harness 框架 → 配置其核心支柱 → 只专注于领域特定的 prompt 与工具设计。 这让排错变成"调一个良好分层的配置面"，而不是"重造整个 agent 架构"。
未来方向 · 顶尖编码 agent 之间的相似度，已经高于它们底层模型之间的相似度--外壳模式在收敛 · 开放问题正在越过"单 agent"：多 agent 并行编排、agent 分析自身 trace 修复 harness 级故障、按需即时组装工具的环境 · 下一阶段：harness 不再是静态配置文件，而越来越像编译器。
Addy Osmanihttp://x.com/i/article/2050749611237847040
同一个模型，放在精调过的外壳里，性能可以远高于跑在通用框架上。当前模型理论能力与你实际看到的能力之间的差距，主要是 harness gap。
最关键的工作方法：棘轮（The Ratchet） 每一次失误都变成一条永久规则。 · 一次"提交了被注释掉的测试"的事故 → AGENTS.md 增加"绝不注释测试"，pre-commit hook 检测 .skip（，reviewer 子 agent 拦截。 · 约束只在观察到真实失败时加入，只在更强模型让它冗余时才移除。 · 系统提示词里每一行都应能追溯到一次具体的历史失败。
推论：没有通用最优 harness。 一个 harness 是一个代码库的"失败史"塑造出来的，是工程纪律而非框架。
设计方法：从行为反推组件 1. 文件系统 + Git -- 持久化状态 模型只能操作进入上下文窗口的内容。文件系统是工作区、暂存区、多 agent 协调面。Git 提供免费版本控制、分支实验、回滚。
2. Bash + 代码执行 -- 通用工具 ReAct 循环（reason → act → observe → repeat）。与其为每个动作预建工具，不如让 agent 用 bash 现场组装。Agent 在 shell 上表现普遍很强。
3. 沙箱 + 默认工具链 Bash 必须安全运行。好沙箱预装运行时、测试 CLI、无头浏览器，让 agent 能"自我验证"。
4. 记忆 + 搜索 -- 持续学习 模型不知道训练之后的世界。AGENTS.md 在每次会话注入领域知识；web search 和 MCP 工具补足实时信息。
5. 对抗 Context Rot 上下文越满，推理越退化。三种主要手法： · Compaction：智能压缩与卸载旧上下文 · Tool-call offloading：长输出（如 2000 行日志）落盘，只在上下文里保留头尾 · Progressive disclosure：按需披露指令和工具，而不是启动时全量加载
6. 长程执行 应对"过早停止"和"分解失败"： · Loops：拦截模型的退出意图，在新上下文窗口里强制继续推进完成目标 · Planning：强制写出步骤计划文件，每步后用 self-verification hook 检查 · Splits：生成与评估拆给不同 agent，规避模型自评的正向偏差
7. Hooks -- 强制层 连接"请求行为"和"强制行为"。生命周期挂载点：工具调用前、文件编辑后、提交前。 成功应当沉默，失败应当冗长。typecheck 通过则无声；失败则把错误直接注入回路供自纠。
8. 规则手册和工具选择 · AGENTS.md 仍是仓库根部最高杠杆的配置点。但要把它当飞行员检查清单，不是风格指南--简短，每条都有失败史背书。 · 十个高度聚焦的工具，永远胜过五十个互相重叠的工具。 · 工具描述会进入 prompt，所以未审计的 MCP server 等同于 prompt 注入风险面。
生产中的样子 把对 Claude Code 架构的推测性拆解作为成熟外壳的参照 · 上下文注入 = 知识层 · 循环状态 = memory store + worktree 隔离器 · 破坏性动作 hook = 权限闸 · 子 agent 上下文防火墙 = 多 agent 层 · 工具 dispatch registry = MCP 与 bash 的统一插槽
外壳不会消失，只会迁移 模型变强不会让外壳消失，而是让它位移： · 老一代模型催生的"上下文焦虑缓解层"已经被新模型大幅淘汰 · 但能力上限抬高的同时，新的失败模式也随之出现 · 外壳里每一块脚手架都编码了"模型当前不能独立做到什么"--模型变强，过时的拆掉，新的搭起来去够下一条地平线
训练循环的反馈 模型 post-training 时通常会带特定 harness 入环 → 模型对这些 harness 偏向的动作（文件系统操作、bash、子 agent 派发）格外擅长 → 形成一定程度的过拟合。
最佳 harness 是为你具体任务和工作流定制的那个。
Harness-as-a-Service 行业从"在 LLM API（提供 completion）上构建"转向"在 Harness API（提供 runtime）上构建"。SDK 直接交付循环、工具、上下文管理、hooks、沙箱。
新默认范式：选一个 harness 框架 → 配置其核心支柱 → 只专注于领域特定的 prompt 与工具设计。 这让排错变成"调一个良好分层的配置面"，而不是"重造整个 agent 架构"。
未来方向 · 顶尖编码 agent 之间的相似度，已经高于它们底层模型之间的相似度--外壳模式在收敛 · 开放问题正在越过"单 agent"：多 agent 并行编排、agent 分析自身 trace 修复 harness 级故障、按需即时组装工具的环境 · 下一阶段：harness 不再是静态配置文件，而越来越像编译器。
Addy Osmanihttp://x.com/i/article/2050749611237847040