Agent Harness：为什么 2026 年是基础设施之年，而非智能之年

两天前，Philipp Schmid 发表了一篇论文让我停止了滑动：《如果 2025 年是 Agent 的开端，2026 年将是 Agent Harness 之年》。

几个月来我一直在构建自主 Agent。最初是为我的公司，后来是为我的个人生活。阅读 Phil 的文章 感觉就像终于有人给我在实践中一直挣扎的问题命名了。

这个洞见不是我们需要更聪明的模型。我们已经有了。

这个洞见是：没有基础设施的智能只是一个演示。

什么是 Agent Harness？

Phil 将 Agent Harness 定义为围绕模型的基础设施层，使长期、面向目标的工作成为可能。它处理提示预设、工具执行、生命周期管理、记忆和恢复。换句话说，就是第一个响应之后发生的一切。

一个有用的心智模型：Agent Harness 是操作系统。LLM 只是 CPU。

LangChain 的 Harrison Chase 最近形式化了 一个让我恍然大悟的分类法：

• 框架 (Framework)：构建模块：如何将模型连接到工具
• 运行时 (Runtime)：执行引擎：持久执行、流式传输、人在回路
• Harness：意见层：提示、工具、集成、记忆、上下文图

如果你曾经尝试过将一个 Agent 从”很酷的演示”变成”在生产中可靠运行”，你就知道为什么这种区分很重要。

没人谈论的问题

Agent 很少因为不够聪明而失败。

它们失败是因为在错误的时刻失去上下文、失去状态或失去对正确工具的访问。

一个非平凡的 Agent 任务轻松涉及数十次工具调用。我的一些任务会达到数百次。在此过程中，上下文窗口被填满，摘要开始生效，Agent 悄悄地忘记了一些重要的东西。

我称之为 第 100 次工具调用问题。不是因为它总是在 100 次时发生，而是因为一旦任务超出单个上下文窗口，性能下降是不可避免的。

这就是为什么 Anthropic 一直在谈论上下文持久性：初始化 Agent、持久化 artifacts、跨会话的增量进度。

这才是 2026 年真正的工程挑战。不是提示工程。上下文工程。

这实际上是什么样子

让我展示一下我的意思。我现在有几个 Agent 在运行我的生活和工作的各个部分。不是我和它们聊天的聊天机器人。这些是有意图和持久性的操作系统。

Sentinel：代码守护者

Sentinel 监控我的代码库的警告和回归。当它发现问题时，它不会通知我。它会打开一个带有建议修复的拉取请求。

我醒来时问题已经解决，而不是收到警报。

Hopper：企业耳语者

在我们公司，我们构建了一个 Agent 来审查 PR，不仅仅是代码质量。它检查副本是否与我们的用户实际说话方式一致：CISO、合规经理、安全团队。它捕捉到工程师无意中为自己而不是为用户写作的微妙时刻。

育儿教练：改变一切的时刻

我和妻子创建了一个育儿教练 Agent 来帮助我们应对抚养女儿的日常挑战。上个月，她有几次呕吐发作，让我们很担心。我们立即打电话给儿科医生，当我妻子在电话里获得医疗建议时，我给教练发了关于可能原因的短信。

有趣的是这里。Agent 检测到一个不寻常的模式：紧急、碎片化的输入和缺少后续。它没有像往常那样详细回复，而是推断我们可能很有压力，长消息是我们最不需要的。所以它发送了一个简单的询问，让我们回复一个表情符号，这样它就知道我们没事。我们发了一个心。

再读一遍。一个 Agent 在压力时刻主动关心我们。不是因为我编程了那个场景。这种行为是从 Agent 如何推理不确定性和认知负荷中涌现出来的。

最后不是紧急情况。我们去医院是为了安全，她服用了药物，我们平安回家了。但那一刻让我印象深刻，因为它展示了一些重要的东西：好的 Agent 行为通常是关于克制，而不是冗长。

那不是聊天机器人。那不是有触发器和输出的工作流。没有人构建育儿教练会想到添加”如果他们在和医生打电话就要求一个表情符号”。Agent 自己想出来了。那就是 Agent。

幕僚长：上下文感知助手

我有一个可以访问我的日历的幕僚长 Agent。它每天发送简报，提醒我优先级，并在整个星期让我保持正轨。

每个月，我和妻子有一个”零议程”星期六。没有会议，没有任务，没有消息。Agent 知道这一点。所以当它在一个这样的星期六有更新要分享时，它决定保持安静并尊重边界。

但它在日历中注意到了一些东西：下午 3 点有一个食物送达。我需要在家。

所以它给我发了一条消息：“快速提醒，你有一个下午 3 点送达的货物。享受你的零议程星期六。我现在保持安静。”

这就是自动化和代理之间的区别。它理解了规则（保持安静），识别了一个例外（时间敏感的送达），并行使了判断力。没有人编程那个特定场景。Agent 自己想出来了。

使之成为可能的基础设施

没有将 Agent 视为长期运行系统的基础设施，这一切都无法工作。

1. 持久执行

Agent 必须能够在故障中生存。重启、网络问题、API 错误不能重置进度。这就是工作流编排器变得必不可少的地方：像 Temporal、LangGraph、Inngest 和 Trigger.dev 这样的工具提供检查点、恢复和准确地从你离开的地方继续的能力。

所有工具的模式都是一样的：将 Agent 任务视为持久工作流，而不是临时函数调用。

2. 记忆架构

向量数据库本身不是记忆。有用的 Agent 需要：

• 情景记忆：发生了什么？（事件、交互、结果）
• 语义记忆：我知道什么？（事实、偏好、学习模式）
• 程序记忆：我如何做事？（技能、工作流、最佳实践）

这就是为什么专用记忆系统正在涌现：Mem0、Zep 和 Letta 都在解决给 Agent 持久化、结构化记忆的问题，这超越了简单的检索。

大多数 Agent 框架给你一个向量数据库并称它为记忆。这就像给某人一个文件柜并称它为大脑。

3. 目标管理

真正的 Agent 不只是响应提示。它们有目标。它们跟踪进度。它们知道何时被阻塞并需要升级。它们可以放弃不再有意义的目标。

这就是 Phil 谈论的 harness 层。将语言模型变成可以实际随时间追求结果的东西的基础设施。

我们仍在解决的挑战

我不会假装这已经解决了。诚实的挑战：

摘要失去细微差别。当你压缩长上下文以适应新窗口时，你会失去纹理。Agent”知道”发生了什么，但失去了_如何_发生的细节。

记忆检索是概率性的。语义搜索很好但不是完美的。有时最相关的记忆不是具有最高余弦相似性的那个。

协调是脆弱的。当你有多个 Agent 一起工作时，在没有持续人工监督的情况下保持它们对齐确实很困难。

这些是工程问题，不是模型问题。这种区分很重要。

思维的转变

我开始构建 Agent，因为简单的自动化不够。中间有 LLM 的工作流仍然在现实世界的复杂性下崩溃。

真正的 Agent 需要：

• 跨会话持久化
• 从它们的行动中学习
• 自主追求目标
• 优雅地处理故障
• 知道何时寻求帮助

随着时间的推移，我发现自己反复重建相同的基础设施部分。记忆。持久性。目标跟踪。上下文边界。

最终，这些部分固化为可重用的 harness 抽象。

这就是解锁。不是更聪明的模型。更好的 harnesses。

接下来是什么

2026 年将是我们不再对 AI 在演示中_能_做什么印象深刻，而是开始期待 AI 在生产中_实际_做什么的一年。

获胜的公司不会有最聪明的模型。它们会有最强大的 harnesses：让 Agent 可靠运行、持续学习并安静地提供价值的基础设施。

问题不是”我如何让我的 AI 更聪明？”

问题是”我需要什么基础设施才能让我的 AI 实际完成它的工作？”

这就是 Agent Harness 论文。从我的角度来看，有 Agent 监控我的代码、组织我的日程并指导我的家庭，这不是预测。

它已经在这里了。

---

我是 Hugo，一位构建 AI Agent 系统的 CPTO。我在 hugo.im 写下我学到的东西，并在 X 和 LinkedIn 上分享快速观点。

---

原文链接: https://www.hugo.im/posts/agent-harness-infrastructure