跳转至

Harness 即后端：当Agent基础设施消解于统一原语

Ch01.1502 Harness 即后端：当Agent基础设施消解于统一原语

📊 Level ⭐⭐⭐ | 9.9KB | entities/harness-即后端当agent基础设施消解于统一原语.md

Harness 即后端：当Agent基础设施消解于统一原语

来源: Unknown

发布日期: 2026-05-01

原文链接: https://mp.weixin.qq.com/s/xjCRZmOMYMPqQvnRva3hKg

当前 AI 基础设施领域的核心问题已不再是模型选型，而是构建可用系统所需的基础设施规模与复杂度。围绕模型外层，业界逐渐形成了一套被称作 Agent Harness（编排基础设施）的结构，涵盖编排循环、工具调用（如 MCP、A2A 协议）、记忆管理、上下文调度与错误处理等模块。各方共识在于模型本身并非最终产品，承载其运行的基础设施才是差异化的关键。

不同方案对 Harness 的设计呈现出明显的谱系特征：从精简型编排到重度结构化编排。精简方案仅保留提示组装、模型调用与工具执行的闭环，将决策权最大程度交由模型；结构化方案则引入指令栈、编排模式与显式交接机制，对流程进行额外约束；更复杂的方案采用确定性流控制与自主 Agent 混合编排，甚至将每个决策点编码为显式节点、每条状态转移定义为有向边，整个工作流由 Harness 完整承载。这一谱系本质上反映了对模型信任程度与逻辑编码强度之间的取舍。

然而在这场讨论中存在一个未被审视的预设：Harness 被默认视为独立于传统 Backend 的额外层。Agent 的循环、工具与记忆被归入编排层，而队列、状态管理、HTTP 路由、服务端渲染、可观测性等传统后端组件则被归入另一侧。这种分层暗示 Harness 是外在于后端架构的附加物，而非后端本身的一部分。

这一分离状态很可能只是技术演进过程中的过渡形态。随着 Agent 架构被更广泛地采纳，编排逻辑与后端基础设施之间的边界将逐步消解，最终融合为统一的后端抽象模型。

架构断层：随机性与确定性的范式冲突

当前主流的 Agent 架构中，Harness 与 Backend 作为两个独立的系统运行。Harness 以独立进程的形式包裹模型，当 Agent 决定执行动作时，将 Tool Call 翻译为 HTTP 请求，进而触发后端系统中的队列发布、数据库写入等操作。后端是一个与 Agent 完全隔离的世界。

这两个世界各自运行着独立的控制逻辑。Harness 按照自身的调度策略进行重试，队列根据其内部条件执行重试，HTTP 层管理着独立的超时配置。这些分散的系统之间不存在直接关联的 Trace 机制。当故障发生时，调试意味着跨系统关联日志，从碎片化的观测数据中重建行为路径。

跨系统日志关联在传统后端工程中是常规操作，因为此前的系统大多是确定性的——相同的输入产生相同的输出，问题路径可被精确复现。但 Agent 的行为本质上是随机的。相同的输入可能产生完全不同的决策序列，相同的 Tool Call 可能触发不同的下游调用链。

深度分析

"品类折叠"作为架构范式转换的核心机制

本文提出的"品类折叠"概念——所有问题的答案收敛为"添加一个 Worker"——具有深刻的架构方法论意义。这与 Unix 的"一切皆文件"、Kubernetes 的"声明式资源模型"属于同一类架构操作：通过找到系统的最小原语集合，将表面多样的能力需求还原为同一组原语的组合。Worker + Function + Trigger 三要素的设计选择，其精妙之处在于没有引入"Agent"作为一等公民——Agent 只是 Worker 的一种特殊形式。这意味着 Agent 的加入不需要新增基础设施品类，而是自然融入已有架构。这种"无特殊身份"的设计哲学，是品类折叠能够成功的核心前提。

Agent随机性与确定性后端之间的范式冲突无法通过"加一层"解决

一个常被忽视的深刻洞察是：Agent 的随机性不是 Bug，而是 Feature。Agent 的价值恰恰在于对相似甚至相同的输入产生差异化的响应。试图通过约束使 Agent 变得更加确定，与其基本功能目标相矛盾。当前 Harness 设计的根本前提，是尝试在旧的确定性范式（传统后端）内部运行新的随机性范式（LLM 驱动的 Agent）。传统的解决路径是"在中间加一层适配"（如独立的 Harness 层），但本文的核心论点在于：加一层只是延缓了冲突，真正的解决路径是让后端本身吸收随机性——当 Agent 作为 Worker 原生参与后端时，Agent 的随机行为不再需要通过额外桥接层与确定性系统交互，而是直接在统一的执行环境中运行。

实时三大特性的涌现性

统一原语架构的三个实时特性——实时发现、实时扩展、实时可观测——不是功能模块，而是架构模式本身的涌现属性。实时发现源于 Worker 注册即上线的机制设计；实时扩展源于 Worker 可被运行时添加且无需重启；实时可观测源于每一次 Function 调用自动附带 Trace ID，跨 Worker 自动传播。三者之间形成正反馈循环：实时发现让 Agent 知道系统能做什么，实时扩展让 Agent 能够按需新增能力，实时可观测让整个系统在被 Agent 动态修改后仍然可追踪。这种涌现性设计比传统的"选型+集成"范式更具可维护性——功能不是被"实现"的，而是被架构"允许"的。

递归能力作为系统自增长引擎

沙箱 Worker 创建其他 Worker 的能力，将系统的边界从"预先设计的功能清单"转换为"运行时不断扩展的注册表"。当一个 Agent Worker 能够在运行时创建沙箱 Worker、注册新 Function、新 Function 立即可被全系统调用——系统的扩展速度从"部署周期"提升到"调用延迟"。这种递归能力使得基础设施从"拼装工具"变为"生长平台"，每一个 Worker 的加入都在增加系统可能性的组合空间。递归能力的门槛在 Worker 创建 Worker，但真正的限制不在技术层面，而在治理层面：如何在不设物理边界的情况下防止无限递归？如何审计运行时创建的新 Worker？这些都是统一原语架构需要配套解决的问题。

精简与重度架构之争的消解

文章最后提出的观点极为精妙：当所有 Agent 都被视为 Worker 时，精简 Harness 与重度 Harness 不再是两种对立的架构范式，而只是同一组原语之下的不同组合方式——前者注册少量函数，由模型自主决定触发路径；后者注册更多函数，引入审批门控与条件逻辑来控制步骤编排。底层原语相同，差异仅在于设计模式的选择。这意味着 Harness 设计之争本质上是对"共享原语的差异化使用方式"的讨论，而非"两套不同基础设施之间的取舍"。脚手架移除也不再是重构集成层，而是函数层面的调整。

实践启示

  1. 最小原语集合的识别是架构设计的第一要务：Worker + Function + Trigger 三要素之所以有效，是因为它们覆盖了"连接、调度、执行"三个原子能力。在设计任何 Agent 系统架构时，优先问"什么是我不可再分的最小原语"，而不是"应该选哪些中间件"。

  2. 品类折叠比功能堆叠更具长期价值：当一个新需求出现时，如果答案总是"添加一类新产品/组件"，说明架构尚未收敛到正确的最小原语。如果答案收敛为"添加一个 Worker"，说明原语设计有效。参考 Harness 范式 中对统一抽象的讨论。

  3. 实时可观测性应内建于架构而非外挂：使用统一 Trace ID 跨 Worker 传播并在架构底层自动输出结构化遥测数据，比在应用层手动拼装可观测性方案更为可靠。如果 Agent 系统的 Debug 需要管理员跨系统关联日志，说明架构设计尚未到位。

  4. 递归扩展能力需要同步设计治理机制：允许 Worker 创建 Worker 是强大的能力释放，但必须有配套的安全隔离（沙箱）、资源限额、审计日志和递归深度控制。否则系统可能因不受控的递归扩展而崩溃。生产级 Agent Harness 的相关设计经验可作为参考。

  5. 从 Harness vs Backend 的二分法走出来：在规划 Agent 基础设施时，不再将编排层和后端层视为独立的两层。统一原语模式下，Agent 是后端的原生参与者，而不是通过额外集成层与后端交互的外部实体。这一认识的转变直接影响技术选型和团队分工。