# Inngest: Your Agent Needs a Harness, Not a Framework

> 原文链接：https://www.inngest.com/blog/your-agent-needs-a-harness-not-a-framework
> 作者/来源：Inngest
> 阅读日期：2026-04-02

## 一句话总结
Inngest 认为 AI agent 需要的是**基础设施级别的 harness（连接、保护和编排组件的层），而非应用级别的 framework**，并通过 Utah（Universally Triggered Agent Harness）项目展示了这一理念的实际实现。

## 核心论点
文章的核心区分是 **harness vs framework**。**Framework** 为每个实现从头构建重试逻辑、状态持久化、任务队列和事件路由。**Harness** 则利用已有的持久化、事件驱动基础设施来统一处理这些关注点。关键洞察是："每个 LLM 调用或工具调用都成为一个 step——一个可独立重试的工作单元"。

这个区分的本质是：**agent 面临的不是 AI 问题，而是基础设施问题**。持久化执行、step 级别的可观测性、自动重试、事件路由、调度和并发控制——这些都是成熟的基础设施问题，不需要为 AI 重新发明轮子。

文章通过 **Utah（Universally Triggered Agent Harness）** 项目来具体展示这一理念。Utah 是一个 Telegram/Slack agent，结合了 Think → Act → Observe 循环（使用 durable steps）、provider-agnostic 的 LLM 支持、文件和 shell 工具、sub-agent 委托（通过 `step.invoke()`）和 singleton 并发控制（防止消息冲突）。

文章特别指出 **context management 是最难的问题**，需要两层剪枝（two-tier pruning）、session compaction、预算警告和溢出恢复来防止 context window 耗尽。

## 关键概念
- **Harness vs Framework**：核心区分。Framework 封装应用逻辑和 AI 特定抽象；Harness 提供基础设施层——"连接、保护和编排组件，但不做工作本身"。
- **Durable Execution（持久化执行）**：每个 step 是可独立重试的工作单元。如果某个 LLM 调用失败，系统可以从该 step 重试，无需重新执行之前的所有迭代。
- **Six-Function Design（六函数设计）**：用六个独立函数替代单体 agent——主 agent 循环、回复函数、打字指示器、全局错误处理、定时心跳、sub-agent 隔离。这体现了关注点分离原则。
- **Two-Tier Pruning（两层剪枝）**：context 管理策略，包含 session compaction、预算警告和溢出恢复。
- **Step-Level Observability（step 级可观测性）**：每个 step 都有追踪和审计日志，使 agent 行为完全可检查。
- **Utah (Universally Triggered Agent Harness)**：Inngest 的参考实现，展示了 harness 理念在实际聊天 agent 中的应用。

## 实践建议
1. **将 agent 的基础设施需求与 AI 逻辑分离**：重试、持久化、事件路由等应该由基础设施层处理，而非在 AI 代码中重新实现。
2. **将每个 LLM/工具调用设计为可独立重试的 step**：这是实现持久化执行和错误恢复的关键粒度。
3. **采用六函数设计模式**：将单体 agent 拆分为独立的关注点——主循环、回复、错误处理、心跳等。
4. **实施多层 context 管理**：两层剪枝 + session compaction + 预算警告 + 溢出恢复的组合策略。
5. **使用 singleton 并发控制**：防止多个消息同时触发同一 agent 实例，避免状态冲突。
6. **利用事件驱动架构解耦触发器和处理逻辑**：使 agent 能响应多种触发源而不改变核心逻辑。

## 独到观点
这篇文章最独特的贡献在于**将 agent 工程重新定义为基础设施问题而非 AI 问题**。这个视角的转换非常重要——它暗示了 agent 工程的最佳实践不应该从 AI 研究中寻找，而应该从分布式系统、消息队列和编排引擎等成熟的基础设施领域中借鉴。六函数设计模式也是最具体的 agent 架构参考实现之一。此外，文章对 context management 作为"最难问题"的定位也预见了后来 context engineering 讨论的核心地位。

## 与其他文章的关联
- 与 [LangChain: Anatomy of Harness](04-langchain-anatomy-of-harness.md) 形成互补：LangChain 定义了 harness 的组件分类，Inngest 则从基础设施角度定义了 harness 的边界。
- "不是 AI 问题而是基础设施问题"的观点是对 [Anthropic: Building Effective Agents](06-anthropic-building-effective-agents.md) 中"反 framework"立场的具体化和延伸。
- Context management 的挑战与 [Manus: Context Engineering](10-manus-context-engineering.md) 和 [Anthropic: Context Engineering](09-anthropic-context-engineering.md) 中的讨论高度相关。
- Durable execution 和 step-level retry 为 [OpenAI: Harness Engineering](01-openai-harness-engineering.md) 中 agent 长时间自主运行（6小时+）提供了底层基础设施方案。
- 六函数设计与 [Anthropic: Harness Design](03-anthropic-harness-design-long-running.md) 的多 agent 架构有相似的关注点分离思路。