AI Agent Harness 与 Backend 的分离：行业共识正在面临挑战

在当前 AI 基础设施的讨论里，几乎所有团队都默认了一个前提：Agent 的 Harness（编排循环、工具调用、内存管理、错误处理）是独立于传统 Backend 的一层“外挂”。Anthropic 偏好极简循环，让模型自己决定一切；OpenAI 增加指令栈和显式交接；CrewAI 用确定性 Flow 做路由校验；LangGraph 则把整个流程编成节点和边。表面上看，这只是“信任模型多少”的权衡，底层却藏着一个更大的认知鸿沟——大家默认 Harness 永远是 Python/TS 进程，而 Backend 是另一套队列、状态、HTTP 路由的确定性世界。

生产环境中，这个分离正在制造真实灾难。我见过一个 4 个 Agent + 5 个 Backend 服务的系统，单次调用路径就爆炸成 80 条随机分支。Harness 自己重试，队列自己重试，HTTP 层自己超时，三套日志完全割裂，排查一次故障像拼拼图。更致命的是，Agent 天生随机性不是 bug，而是它的核心价值——它让计算机第一次能处理“相似输入却需要不同输出”的场景。可当随机性乘以 Backend 的确定性路径，调试成本就呈指数级增长。

我起初也和大多数架构师一样，认为 Backend 就是“服务集合 + 库 + 架构图”，越拆越复杂。后来深入思考才发现，这个认知其实是自上而下的幻觉。真正的 Backend，本质上只由三个原语组成：Worker（执行工作的进程）、Trigger（触发条件）、Function（具体工作单元）。一切架构讨论，最终都能收敛到这三者。

这不是学术抽象，而是可落地的统一模型。以 iii 为例（一个开源的引擎实现），它把 Agent 直接变成 Worker：Agent 连接引擎，注册自己的 Function 和 Trigger，状态通过state::set持久化，任务交接通过队列-backed Trigger，广播通过 pub/sub。工具就是 Function，内存就是 State，编排就是 Trigger 的组合。Harness 不再是 Backend 之上的脚手架，它本身就是 Backend 的一部分。

// 注册一个研究工作者（示例基于 iii 风格，重构为生产可用）registerFunction({id:"researcher::analyze",// 稳定标识符，跨语言、跨进程唯一handler:async(input:ResearchTask)=>{// 模型调用 + 工具执行逻辑constresult=awaitmodel.call("analyze",input);returnresult;}});// 绑定触发器：同一个 Function 可被多种方式触发registerTrigger({type:"http",path:"/research",functionId:"researcher::analyze"});registerTrigger({type:"state",condition:{status:"pending"},functionId:"researcher::analyze"});

只需这几行，研究者既能通过 POST 请求调用，也能在任务进入 pending 状态时自动触发，还能随时加 cron。Function 本身不变，Trigger 负责组合——这就是原语的威力。

传统分离方案 vs 原语统一方案的真实权衡

（数据来源于生产实践对比，iii 引擎已支持 TS/Python/Rust SDK，OpenTelemetry 原生集成）

这种统一带来的三个“Live”特性，是传统架构永远无法自然产生的：

• Live Discovery：Worker 连接即获得全系统 Function 目录，新 Function 出现时全网推送通知。Agent 永远看到最新系统能力，不再有“过时上下文”风险。
• Live Extensibility：运行时添加 Worker，无需重启、无需配置变更。生产系统像活体一样生长。
• Live Observability：一次 Agent 调用工具 → 入队 → 下游 Function → 写状态，全链路一个 Trace，跨语言、跨 Worker、跨 Agent-Backend 边界。日志自动结构化关联，再也不用靠时间戳拼凑。

更惊艳的是递归能力：iii 支持硬件隔离的 microVM Worker，Agent 自己就能在运行时iii worker add启动一个沙箱 Worker。这个沙箱注册自己的 Function，立即加入全系统目录，用完即断开。Agent 不再是消费者，它能成为基础设施的生产者。这才是真正的“基础设施即设计模式”。

原语足够小，一切类别都会坍缩。

Unix 的“一切皆文件”让系统可组合；React 的“组件即函数”让 UI 心智模型统一。在 iii 这里，答案永远是“加一个 Worker”。要队列？加 Worker 注册队列 Trigger；要实时流？加 Worker；要沙箱？加 Worker；要 Agent？加 Worker。平台不再是产品目录，而是单一原语的无限组合。语义从基础设施转移到 Function 本身，复杂度被彻底简化。

这个转变不是渐进优化，而是范式级跃迁。行业当前还在争论 Harness 该薄还是厚，其实是在一个即将消失的设计空间里内卷。当 Harness 用和 Backend 完全相同的原语构建，薄厚就变成“注册多少 Function、如何组合 Trigger”的实现细节。移除脚手架也不再需要重构集成层，只需简化 Function 注册即可。

Agentic 时代真正的胜负手，不是模型能力，而是基础设施能否把随机性原生纳入确定性系统。当原语选对，边界就自然溶解：Harness 不是 Backend 之上的层，Harness 就是 Backend；Backend 就是一切能连接引擎的东西。

你在落地 AI Agent 时，是继续把 Harness 当作独立胶水层，还是已经开始用统一原语重构 Backend？欢迎在评论区分享你的生产实践和踩过的坑——我们一起把这次范式转变推向更深的生产力。

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。