DeepSeek Harness 之后，企业 AI 架构正在出现一个新的共享运行层

当业务从 AI 应用走向 Agent，共性的执行能力开始从单个 Agent 内部抽离。

Agent Runtime 正在成为模型服务与业务 Agent 之间的一层共享能力。

这是「企业 Agent 平台」系列。先从最近突然升温的 Harness 说起。

一、DeepSeek Harness 把 Runtime 推到了台前

过去两年，企业建设生成式 AI，第一批架构问题几乎都围绕模型：选哪个模型，私有化部署还是调用 API，RAG 怎么做，多模型怎么统一接入。

到了 Agent 阶段，架构的问题关注点则发生了变化。一个 AI 应用调用几次模型，执行逻辑通常可以直接写在代码里；一个 Agent 要持续完成任务，还要维护上下文、调用工具、保存状态，并在失败或中断后继续执行。

一个团队完全可以自己把这些能力做出来。十个团队各做一个 Agent，就可能出现十套执行机制。

8 月 13 日公开的 DeepSeek Harness，把这层过去更多隐藏在 Agent Framework 和应用内部的能力推到了台前。截至 8 月 18 日，其官方 GitHub 仓库 Star 已超过 15 万。

15 万 Star 说明不了谁会成为最终标准，但Runtime 已经从 Agent 内部的实现细节，变成可以独立讨论和复用的一层能力。

本文所说的Agent Runtime（共享运行层），指位于业务 Agent 与模型、企业工具之间，负责承载 Agent 执行过程的运行层。Harness 可以看作这类运行机制的一种实现形态，后文统一简称 Runtime。

本文讨论的也不是 IT 基础设施向上多了一层，而是企业 AI 技术架构中，开始出现一个新的共享层。

二、LLM模型下沉，业务从“调用智能”走向“组织智能”

过去三年，企业 AI 技术架构的两端都在变化。

1. 模型侧：从单一模型绑定到统一模型服务

早期 PoC 阶段，一个业务应用直接绑定一个模型很正常。Prompt、RAG、工具调用都围绕具体模型开发，架构简单，交付也快。

应用数量增加以后，长期绑定单一模型的成本开始暴露。复杂推理看重能力，大规模简单任务关注成本和时延，敏感场景又有不同的部署要求；底层模型本身还在快速迭代。

模型网关、多模型路由和统一模型服务随之进入企业架构。业务与具体模型逐步解耦，模型开始变成可以统一接入、路由、调用和替换的智能服务。

DeepSeek、GPT、Claude 等模型在能力、成本和部署方式上的差异依然明显。“LLM 下沉”说的是架构角色的变化：底层换一个模型，不应该要求上层业务流程、工具体系和知识资产一起重构。

模型仍然决定 Agent 的能力上限，但对企业应用来说，它越来越像一组可以统一调用和组合的智能服务。本文把这一层称为模型服务层（Model Services）。

2. 业务侧：从 AI 应用到 Agent

传统 AI 应用里，什么时候检索、什么时候调用模型、什么时候访问 API，通常由代码预先定义。模型负责推理和生成，执行路径仍然掌握在应用程序手中。

Agent 开始改变这个关系。业务给出目标和约束，Agent 根据当前状态判断下一步做什么、调用什么工具、怎样处理返回结果，再决定继续、调整还是结束。

模型开始参与任务执行路径的决定。

AI 系统的基本运行单元，也由一次请求（Request）逐渐变成一个持续存在的任务（Task）。

Agent 的执行不再是一次调用后返回，而是围绕目标持续判断下一步、调用工具、处理结果，再决定继续还是结束。一个 Task 可能包含多轮模型推理和工具调用，持续数分钟、数小时，也可能等待外部事件后继续。

企业 AI 的工程重点也随之从“怎么调用模型”，转向“怎么组织模型、工具和企业自身能力，把一项工作做完”。

图 1｜过去三年企业 AI 技术架构重心的迁移

模型逐渐被抽象成共享服务，业务逐渐 Agent 化；两者之间那段持续执行任务所需的能力，也开始从应用内部被单独拿出来。

三、从 Agent 烟囱到共享运行层

单个 Agent 没有必要先建设企业级 Runtime。

PoC 阶段，把任务循环、上下文管理（Context Management）、工具调用、状态管理（State Management）和失败重试直接写进应用，通常更快。业务场景还没有稳定之前，统一平台反而容易增加约束。

Agent 数量增加并进入生产以后，成本开始集中出现。一边是规模：财务、供应链、研发、采购、客服陆续建设 Agent，每个团队都会碰到相似的执行问题。

另一边是生产要求：Demo 失败后可以重跑，状态可以暂存在内存里，工具调用也可以直接写在业务代码中。进入生产后，状态持久化、失败恢复（Recovery）、隔离执行（Isolation）和长任务（Long-running Task）会逐渐成为常态。

例如，财务团队开发经营分析 Agent，会自己封装财务系统接口、维护上下文、记录任务状态，并处理模型或接口调用失败。

供应链团队开发库存 Agent，也会建立类似机制。研发、采购、客服继续往下做，各自都会长出一套自己的执行环境。

单个项目都合理，叠加到企业层面后，会出现一些很具体的问题：同一个 ERP 或 CRM 接口被多个团队分别封装；一个 Agent 支持断点恢复，另一个失败后只能从头执行；不同团队采用不同的上下文和状态管理机制；底层模型或工具升级，还要逐个 Agent 修改。

企业得到的不只是很多 Agent，还有很多彼此独立的 Agent 执行环境。新的Agent 烟囱（Agent Silo）就这样形成了。

企业过去解决过应用烟囱、数据烟囱和接口烟囱。Agent 数量增加以后，如果仍然沿用每个团队独立建设的方式，同样的结构会再出现一次。

Agent 数量增加解决的是规模问题，进入生产解决的是成熟度问题。两个维度叠加以后，把执行机制继续留在每个 Agent 内部的成本会越来越高。

图 2｜从 Agent 烟囱到共享运行层

业务差异化留在 Agent，共性执行机制进入共享运行层。

共享，不等于把代码放到公共库，把上下文、工具、状态和失败处理做成几个公共 Library，可以减少重复开发，但还不足以形成共享运行层。

Runtime 要承担共享层的角色，需要形成稳定的能力模块（Building Block）和接口。能力模块应当能够跨场景复用、与其他能力组合，并允许底层实现独立替换；内部复杂度由 Runtime 吸收，上层 Agent 只依赖相对稳定的接口。

判断一项能力是否应该进入共享运行层，可以看三点：

1. 多个业务是否持续重复需要？

2. 本身是不是构成业务差异化？

3. 接口是否已经相对稳定?

上下文管理、工具执行（Tool Execution）、状态管理、失败恢复、隔离执行和长任务，大多会沿着这条路径演进。

以工具执行为例。不同 Agent 都可能需要调用 ERP、CRM、数据库或其他企业服务，但连接、执行和异常处理没有必要由每个团队重复实现。业务 Agent 更应该关注“调用什么能力”，以及“调用结果对业务意味着什么”。

状态管理也一样。业务关心的是订单到了哪个环节、分析任务执行到什么阶段；状态如何持久化、任务中断后如何恢复，更适合由共享运行层承担。

这些能力单独看都不是稀缺技术。组合成一致的Agent 执行模型（Agent Execution Model）后，不同 Agent 才能按照相同机制运行、恢复和升级。

业务 Agent负责“做什么”；

模型服务层提供“智能”；

企业工具与系统提供“可以做什么”；

Agent Runtime负责“任务如何持续、稳定地执行”。

Agent 越少、场景越不稳定，这一层越没有必要提前建设；Agent 越多、生产要求越高，把这些能力留在业务代码里的成本就越高。Runtime 是 Agent 规模扩大、进入生产以后，从业务代码中逐步抽离出来的一层共享能力。

四、对 CIO 来说，关键是判断共享边界

统一 Runtime 并不是 Agent 架构的必选项，也没有必要在 PoC 阶段提前建设。

如果企业只有少量 Agent，业务和技术方案还在快速变化，让团队自行完成执行逻辑通常更高效。随着 Agent 数量增加、生产要求提高，重复建设开始跨团队出现，共享运行层才有平台化的价值。

判断边界可以简单一些：

仍然体现业务差异、还在快速变化的能力，留在 Agent；跨业务反复出现、接口逐渐稳定、又不构成业务差异化的执行能力，进入 Runtime。

对 CIO 和企业架构团队来说，需要回答“企业当前的 Agent 规模和生产成熟度，是否已经到了需要抽象共享运行层的阶段，而不是要不要跟进一个新的 Harness”。

把 Runtime 放回整个企业 AI 技术架构中，它处在模型能力与业务 Agent 之间：模型负责提供智能，Runtime 负责让 Agent 持续完成任务。

而当 Agent 进一步从“给建议”走向“直接采取行动”，架构还会出现新的问题。那已经超出本文讨论的 Runtime 范围。

图 3｜企业 AI 架构的演进

DeepSeek Harness 值得企业关注的地方，也可以归结到这一点：

模型服务之上、业务 Agent 之下，需要一层共享的 Agent Runtime。

图 3 右侧的“控制智能”暂不展开。

当 Agent 开始代表企业采取行动，身份、权限、策略、审批、审计等问题会从单个应用问题变成企业级架构问题。下一篇将从 Runtime 继续往上一层，讨论企业为什么需要统一的 Control Plane。「企业 Agent 平台」系列

这个系列沿着一条企业决策链展开：

架构为什么要变 Agent 怎么控制 平台怎么建设 目标架构怎么设计 PoC 怎么验证

如果你也在思考企业 Agent 平台的架构与建设路径，欢迎关注这个系列，也欢迎转给正在推进 Agent 的同事一起讨论。

#Agent

#AgentRuntime

#Harness

#Deepseek

#AI架构

#企业架构

#CIO

参考资料：

DeepSeek Harness 官方 GitHub 仓库

O’Reilly Early Release《Building AI Agent Platforms》