Agent Harness：生产级LLM Agent“轮子掉落”时的真正幕后基础设施

你搭建了一个聊天机器人接入了几个工具的ReAct循环在演示环境中一切看起来都很丝滑。可当你尝试把它推向生产环境时问题瞬间暴露模型忘了三步之前的操作记录工具调用在后台静默失败上下文窗口被冗余数据迅速填满导致整体性能断崖式下跌。我起初也和大多数工程师一样把全部注意力放在模型本身——觉得只要换个更强的LLM或者再优化一下Prompt就能解决问题。后来我系统性地对比了Anthropic的Claude Code文档、OpenAI的Agents SDK源码以及LangGraph的最新实现才发现真正的差距根本不在模型而在于模型周围那层完整的基础设施——现在被正式称为Agent Harness。Harness不是一个简单的包装层而是将无状态LLM转化为目标导向、工具调用、自纠错生产级Agent的全部软件基础设施。它包含编排循环、工具集成、内存管理、上下文工程、状态持久化、错误恢复和安全护栏等全部环节。LangChain在TerminalBench 2.0上的跃升就是一个活生生的例子他们只改动了围绕同一模型的基础设施就从榜单30名开外冲到第5名。另一项研究甚至让LLM自己去优化Harness结果超越了人工设计方案达到76.4%的通过率。Harness的本质我们用自然语言重新发明了冯·诺依曼架构Beren Millidge早在2023年的论文《Scaffolded LLMs as Natural Language Computers》中就把这个比喻讲透了。一个裸露的LLM就像一台没有RAM、没有磁盘、没有I/O的CPU。上下文窗口充当RAM速度快但容量极有限外部数据库是磁盘容量大但访问慢工具集成则是设备驱动而Harness就是整个操作系统。我们其实已经在自然语言层面把经典的冯·诺依曼计算架构重新实现了一遍。另一个生活化的类比是建筑脚手架它本身不参与盖楼却能让工人触达原本无法企及的高度。楼盖好了脚手架就该拆除。模型能力越强Harness就越应该“瘦身”——这正是当前最核心的演进方向。三层工程能力Prompt、Context与Harness的真实边界工程实践可以清晰分为三个同心圆Prompt Engineering只负责模型每次接收到的指令内容。Context Engineering决定模型“看到什么、何时看到”解决“迷失在中间”Lost in the Middle效应。Harness Engineering把前两者全部包进来还包括工具编排、状态持久化、错误恢复、验证闭环、安全执行和生命周期管理。真正的生产级Agent行为是Harness这层完整系统涌现出来的结果而非模型单方面“聪明”就能实现。编排循环为什么必须是“笨循环”却能承载全部智能编排循环是整个Harness的心跳。它实现的是Thought-Action-ObservationTAO循环也就是经典的ReAct模式。表面上看就是一个while循环但复杂性全在它管理的各个环节里。Anthropic把自己的运行时明确定义为“dumb loop”——所有智能都在模型里Harness只负责轮次管理和状态流转。下面是我重构后的生产级伪代码示例增加了关键中文注释便于理解边界条件# 生产级Agent Harness编排循环重构版defagent_harness_loop(user_query:str,max_turns:int50):history[]# 会话历史短期记忆stateinitialize_state()# 持久化状态支持checkpointforturninrange(max_turns):# 1. 组装prompt上下文工程核心promptassemble_prompt(system_promptSYSTEM_PROMPT,toolstool_schemas,# 注入工具定义memory_filesload_relevant_memory(),# JIT加载historyhistory,current_queryuser_query)# 2. LLM推理responsellm.invoke(prompt)# 支持structured tool_calls# 3. 输出分类与处理ifnotresponse.tool_calls:returnresponse.content# 最终答案循环终止# 4. 工具执行带权限检查和sandboxfortool_callinresponse.tool_calls:ifnotpermission_check(tool_call):continue# 安全护栏拦截try:resultexecute_sandboxed_tool(tool_call)# 沙箱执行history.append(format_observation(result))exceptExceptionase:history.append(format_error(e))# LLM可自我恢复# 5. 上下文压缩防止窗口爆炸ifapproaching_context_limit(history):historycompact_history(history)# 保留架构决策未解决bugreturnMax turns exceeded工具、内存与上下文生产环境中最容易踩坑的三个维度工具层负责注册、 schema 校验、参数提取、沙箱执行和结果格式化。Claude Code提供了六大类工具文件操作、搜索、执行、Web访问、代码智能、子Agent生成而OpenAI则支持函数工具、托管工具和MCP服务器工具。内存系统需要同时处理多个时间尺度。短期是单会话历史长期则跨越会话。Claude Code采用三级架构轻量索引每条约150字符常驻、按需加载的主题文件、仅通过搜索访问的原始记录。关键原则是Agent把自己的记忆当成“提示”在行动前必须验证实际状态。上下文管理是许多Agent静默失败的根源。研究显示关键内容落在窗口中间位置时模型性能会下降30%以上。生产策略包括对话历史压缩保留架构决策丢弃冗余工具输出、观察结果掩码、即时检索用grep/glob代替全文件加载、子Agent委托只返回1000-2000 token的浓缩摘要。主流框架Harness实现的对比矩阵为了让决策更清晰我整理了一个核心对比表基于2026年初最新实践维度Anthropic Claude CodeOpenAI Agents SDKLangGraph编排循环Gather-Act-Verify “笨循环”Runner类async/sync/stream显式状态图 条件边内存管理三级分层索引主题文件搜索SessionsSQLite/Redis命名空间JSON Store checkpoint上下文策略JIT检索 子Agent摘要previous_response_id 链式观察结果掩码 结构化笔记错误恢复工具层捕获并返回ErrorMessage4类错误区分transient/LLM-recoverableReducer合并 时间旅行调试验证闭环Rules Visual LLM-as-JudgeSDK内置guardrails嵌套子图 显式验证节点适用场景代码智能、长任务Ralph Loop代码优先工作流多Agent、复杂状态机七大架构决策每位Harness设计师必须正面回答的问题单Agent优先还是多AgentAnthropic和OpenAI都建议先把单个Agent能力拉满ReAct交替执行还是Plan-and-Execute后者可带来3.6倍速度提升上下文压缩策略选哪种时间清除、摘要、掩码、结构笔记、子Agent委托验证循环是前馈引导还是后馈传感器权限模型是宽松还是严格工具范围该多大Vercel把80%工具砍掉后性能反而提升Harness厚度如何Anthropic押注“薄Harness模型进步”图框架押注显式控制Harness就是产品本身TerminalBench的排名变化已经把结论讲得很清楚同样的模型Harness设计不同性能能差20个名次以上。模型会越来越商品化而Harness才是真正需要硬核工程的地方——它管理上下文这种稀缺资源、设计能提前抓住失败的验证循环、构建不产生幻觉的记忆系统。未来趋势已经清晰Harness会随着模型能力提升而持续瘦身但永远不会消失。它是让Agent行为可靠、可调试、可审计的最后一道工程屏障。你在构建下一个生产级AI Agent时会把Harness放在什么优先级是继续依赖“聪明Prompt”走捷径还是系统性地投资一套可演进的Harness架构欢迎在评论区分享你的生产踩坑经历或架构决策我们一起把AI Agent从Demo真正推向可信的生产环境。我是紫微AI在做一个「人格操作系统ZPF」。后面会持续分享AI Agent和系统实验。感兴趣可以关注我们下期见。