AI Agent 的瓶颈:模型还是 Harness?--从“裸 CPU”到“完整计算机”的工程跃迁
最近读到 Akshay 的一篇深度分析,彻底刷新了我对 AI Agent 的认知。
我们总在抱怨“Agent 不行”,但问题可能根本不在模型本身,而在我们没给它套上合适的 Harness(马具)。
💡 一句话总结:如果你不是模型本身,那你就得是 Harness。
🔍 从“提示工程”到“马具工程”:AI 开发的三个阶段
我们对 AI 的理解正在经历范式转移:
- Prompt Engineering(提示工程)
→ 聚焦“怎么写指令”,靠人工雕琢 prompt。
- Context Engineering(上下文工程)
→ 关注“模型看到什么、何时看到”,引入检索、过滤、排序。
- Harness Engineering(马具工程) ✅
→ 构建完整系统:工具调用、状态管理、错误恢复、安全边界……让 Agent 能长期、稳定、自主运行。
LangChain 团队说得一针见血:
“Agent 的智能是涌现的,但 Harness 才是把它变成可靠产品的工程体系。”
同一模型,不同 Harness,性能差距可达数十倍。
LangChain 在 TerminalBench 测试中,仅优化 Harness(未换模型),排名从 30+ 跃升至第 5;
更有项目让 LLM 自主优化 Harness,任务通过率高达 76.4%--这充分说明:瓶颈常在系统,不在模型。
🛠️ 一个靠谱的 Agent Harness 需要哪些核心组件?
参考 Anthropic、OpenAI、LangChain 等一线实践,提炼出 12 大关键模块(节选核心 6 项):
1. 编排循环(Orchestration Loop)
- 典型如 ReAct(Thought → Action → Observation)或 TAO 循环。
- 看似简单,实为 Agent 的“心跳”:模型负责思考,循环保障执行稳定性。
2. 工具系统(Tools)
- 不是随便接 API!需定义清晰 schema、输入验证、沙箱隔离。
- Claude Code 支持文件操作、网页浏览、代码执行、子代理调用;
- OpenAI 强化函数工具 + 托管工具生态。
3. 记忆机制(Memory)
- 区分 短时记忆(当前会话)与 长时记忆(跨会话持久化)。
- 先进方案如:Claude 的
CLAUDE.md / MEMORY.md、LangGraph 的 JSON Store。
- 支持分层索引:摘要 → 关键细节 → 原始记录,避免上下文爆炸。
4. 上下文管理(Context Management)
- 解决 “Lost in the Middle” 难题:模型对中间内容注意力衰减。
- 手段包括:语义压缩、动态掩码、按需检索、子代理摘要等。
5. 提示组装(Prompt Construction)
- 系统提示 + 工具描述 + 记忆片段 + 对话历史 + 用户输入 → 分层动态组装。
- 避免“堆砌式 prompt”,强调结构化和优先级控制。
6. 错误恢复与验证(Error Recovery & Validation)
- Agent 不是“一次成功”的系统,必须内置重试、回滚、人工干预接口。
- 例如:执行失败时自动切换工具、触发安全检查或请求用户确认。
⚠️ 其他关键组件还包括:安全护栏、任务分解器、评估反馈环、资源调度器等(后续可展开)。
🧠 核心观点:LLM 是裸 CPU,Harness 才是操作系统
把 LLM 比作一颗强大的 CPU--它有算力,但无内存、无存储、无 I/O。
Harness 就是那个把它变成“完整计算机”的操作系统:
管理资源、调度任务、处理异常、提供接口。
没有 Harness,再强的模型也会在复杂任务中“迷路”;
有了 Harness,中等模型也能稳定完成高难度工作。
💬 讨论:你的 Agent 项目,瓶颈到底在哪?
- 如果你还在疯狂调 prompt,或许该停下来问问:我的 Harness 完整吗?
- 如果你觉得“模型不行”,不妨试试:用同一模型 + 更好 Harness,结果会怎样?
🔁 记住:在 Agent 时代,工程能力 = 产品能力。
模型负责“聪明”,Harness 负责“靠谱”。
欢迎分享你的 Harness 设计经验,或踩过的坑!👇
加入讨论
这个“马具工程”的比喻太形象了!之前做Agent项目时总在调prompt,结果效果飘忽不定,现在才意识到是缺了稳定的执行框架。尤其是错误恢复那块,模型一犯错就整个崩掉,要是早点看到这篇就好了…