Agent 生态会形成统一基座吗

随着 Agent 产品不断出现，有一个问题会越来越绕不过去：不同业务里的 Agent，到底能不能建立在统一的通用基座上？

如果这种分离真的成立，那么车机助手、Coding Agent、Data Agent、客服 Agent、研究 Agent，就不必各自从头实现状态管理、工具调用、Context 构造、任务恢复、轨迹记录和评测系统。它们可以共享一套通用运行机制，只根据业务定义自己的任务、状态、工具和评价标准。

这听起来很像操作系统和应用程序，或者云平台和业务服务之间的关系。但 Agent 是一个由概率模型驱动、依赖动态 Context 和外部环境的闭环系统。它能不能形成类似的软件生态分层，并不那么显而易见。

我现在越来越愿意把这个问题拆成三句：

1. Agent 系统里，哪些部分确实可以通用化？
2. 哪些内容没法被通用框架替代？
3. 通用 Runtime 和业务 Agent 之间，应该建立怎样的边界？

为什么 Agent 需要通用基础设施

不同 Agent 的业务差异非常大。

车机 Agent 面对车辆状态、驾驶安全和用户偏好；Coding Agent 操作代码仓库、终端和测试环境；Data Agent 面对数据库 Schema、指标口径和权限系统；客服 Agent 则要处理订单、退款和用户关系。

但如果你看这些系统的内部实现，会发现大量能力反复出现：

• 模型调用与模型路由
• Session 和状态持久化
• 历史对话与 Memory
• Context 的选择、压缩和注入
• 工具注册、调用和结果返回
• 权限、审批与安全控制
• 长程任务的暂停、恢复和重试
• Trace、Snapshot 与 Replay
• 评测任务的执行与结果记录
• 成本、延迟和资源预算
• 人工介入与回滚

这些能力并不属于某个特定行业。

无论 Agent 操作的是车窗、代码还是数据库，它都要回答一些共同问题：

• 当前任务进行到哪一步了？
• 模型在做决策时看到了什么？
• 它为什么选择了这个工具？
• 工具执行后世界发生了什么变化？
• 失败后从什么状态恢复？
• 新版本是否比旧版本更好？

正是这种跨业务的重复性，让通用 Agent Runtime 有了现实基础。

通用化的动力，并不来自某个协议或某个热门框架，而来自不同团队正在重复支付相同的工程成本。

可以被通用化的，是运行机制，不是业务理解

通用 Agent 基座不应该试图理解所有业务，而应该提供与业务相对无关的运行机制。

我会把它粗略抽象成：

Agent Runtime = Execution + State + Context + Action + Observation + Evaluation

执行机制

Runtime 负责驱动 Agent 循环：观察 → 构造 Context → 模型决策 → 执行行动 → 更新状态。它需要管理任务何时开始、何时继续、何时暂停、何时结束。

状态管理

Agent 不是一次性文本生成程序，而是持续运行的状态系统。Runtime 可以统一提供 Session、Checkpoint、状态持久化、分支、回滚、过期管理和并发控制。

Context 运行机制

Runtime 可以负责从多个来源收集 Context，控制优先级，去重和压缩，记录信息来源，限制 token 预算，并保存最终发送给模型的 Context 快照。业务层不该为每个 Agent 重新实现完整的 Context 管线。

能力执行

工具具体做什么由业务定义，但工具如何被可靠执行，可以由基座统一负责：注册、参数校验、超时、重试、权限检查、结果回传、副作用审计。

可观测性和回放

Runtime 应天然记录模型版本、Prompt 和 Skill 版本、实际 Context、工具调用、工具结果、状态转移、人工介入和评价结果。它还应支持从历史状态重新运行候选版本，让 Agent 优化从经验判断走向可比较实验。

评价执行机制

通用 Runtime 可以负责运行回归测试、配对评测、多次采样、Champion–Challenger、Shadow Test，以及成本和延迟统计。

但评价的具体内容，不能由 Runtime 自己定义。

无法被通用化的，是业务世界语义

通用 Runtime 可以保存状态，却不能决定什么状态重要。

比如车机用户说：“有点闷。”

这一请求可能涉及当前车速、外部空气质量、车内温度、车窗状态、空调状态、用户历史偏好、驾驶安全、当前控制权限。Runtime 可以把这些信息保存和注入 Context，但无法自动决定：

• 应该开窗还是开空调
• 是否应该先询问用户
• 高速行驶时能否执行
• 什么行为才算真正满足用户

这些判断属于业务世界语义。

同样，Coding Agent 的 Runtime 可以跑测试，但它不能替业务定义：

• 哪些测试是发布门槛
• 哪些代码变化属于高风险
• 测试通过是否足以代表任务完成
• 是否需要人工代码审查

所以 Agent 系统里存在一个核心边界：

通用层负责机制，业务层负责意义。

通用 Runtime 回答：Agent 如何运行、如何保存、如何行动、如何恢复、如何被观察？

业务 Agent 回答：Agent 生活在什么世界、要完成什么任务、哪些行动是合理的、什么结果才算正确？

合理的 Agent 系统不是两层，而是三部分

一个更完整的抽象，我会写成：

Agent System = Runtime + Business Agent Package + Environment

Runtime

提供通用执行机制：模型调用、状态、Context、工具执行、权限、Trace、Replay、Evaluation、Lifecycle。

Business Agent Package

定义业务世界：Task、State Schema、Context Provider、Skill、Workflow、Policy、Capability、Evaluator、Simulator、Risk Boundary。

Environment

提供真实可操作对象：车辆、数据库、文件系统、代码仓库、浏览器、企业系统、外部 API。

Runtime 不理解业务，但能够加载业务包；业务包不负责重造运行时，而是声明自己依赖什么世界和能力；Environment 提供实际状态与行动。

我觉得这个三分法，比简单的“框架 vs 应用”更接近 Agent 的真实结构。

真正需要建立的，是 Agent 应用契约

如果通用 Runtime 与业务层要稳定分离，中间必须存在一个清晰契约。

这个契约不应该只是一个 Prompt 文件，也不应该只是工具列表。它至少需要描述下面几层。

任务契约

一个任务需要定义初始输入、所需状态、可采取的行动、完成条件、失败条件、时间和成本预算、是否允许人工介入。

如果没有明确任务契约，Agent 只能靠模型自己猜任务是否完成。

状态契约

业务层需要定义：世界中有哪些状态，状态从哪里获得，状态何时失效，哪些任务依赖哪些状态，哪些状态可以写入 Memory，哪些状态涉及隐私和权限。

Runtime 负责保存和版本化状态，但状态的业务含义必须由业务层声明。

Context 契约

Context 不应只是任意文本，而应带有来源、时间、版本、有效期、优先级、敏感级别、注入原因，以及与任务的关系。

这样系统才能回答：这段信息为什么进入模型？它是否已经过时？Replay 时能否恢复？

行动与副作用契约

一个工具不能只有名称、描述和参数，还应说明前置条件、权限、是否只读、是否有副作用、是否可逆、是否幂等、风险等级、成功后的状态变化、如何验证执行结果、失败后如何补偿。

Agent 操作真实世界时，副作用语义往往比函数调用格式更重要。

评价契约

业务层需要明确：什么是成功，什么是不可接受的失败，哪些指标必须满足，哪些结果需要人工判断，哪些风险不能被平均分抵消，Replay 保真度达到什么程度才能得出结论。

Runtime 可以执行评测，但不能替业务定义真实价值。

统一基座不能保证行为一致

即使同一个业务 Agent Package 可以被不同 Runtime 加载，也不意味着它会产生完全相同的行为。

Agent 行为大致可以看成：

B = F(Package, Runtime, Model, Context, Tools, Environment)

只要其中任意一项变化，最终行为就可能变化：

• 不同模型的工具选择能力不同
• 不同 Runtime 的 Context 顺序不同
• 不同 Memory 机制保留的信息不同
• 不同推理预算导致规划深度不同
• 不同工具错误反馈影响恢复策略

因此，未来 Agent 的可移植性，更可能意味着：

• 可以加载
• 可以运行
• 可以观测
• 可以回放
• 可以评价
• 可以比较

而不是：

• 换模型、换 Runtime 后仍然行为完全等价

统一基座提供的是可操作性和实验一致性，而不是智能等价性。

这一点我觉得特别值得反复强调。很多人一听到“统一基座”，就会默认它应该带来“同样的智能表现”。但在 Agent 里，那几乎是不现实的。

生态更可能统一什么

Agent 生态可能按照由外向内的顺序逐渐收敛。

最容易统一的是连接和数据格式，例如模型接口、工具调用和外部资源接入。

接下来更可能通用化的是：

• 状态持久化
• Trace
• Checkpoint
• Replay
• 权限
• 沙箱
• 成本统计
• 任务生命周期

再往后，才可能出现更复杂的业务包契约，例如 Task、State、Action、Evaluation、Simulation。

越靠近业务真实价值，标准化就越困难。

所以我现在的判断是：未来更可能形成多个 Runtime 并存的生态，而不是一个框架统一所有 Agent。不同 Runtime 可以在性能、安全、易用性、实时性和部署方式上竞争，但逐渐共享某些稳定的运行和数据抽象。

需要警惕过度抽象

通用化并不总是好事。

一个抽象若想覆盖所有 Agent，很容易掉进两种坑。

抽象过弱

只提供最基础的模型调用和工具循环，真正困难的状态、评价、回放和风险问题，仍然留给业务自己实现。这种框架虽然“通用”，但复用价值有限。

抽象过强

试图用统一 Workflow、统一状态结构和统一评价模型表达所有业务。这种框架最终可能过于复杂，限制模型能力，难以适应特殊业务，还把业务语义藏进大量配置和 Hook 中。

因此，合理边界不是抽象得越多越好，而是：

通用层提供稳定机制，同时允许业务层保留对世界语义的完整表达能力。

通用基座真正带来的生态价值

如果这一分层能够成立，Agent 生态会发生几个重要变化。

业务开发者不再重复造基础设施

他们可以把精力集中在业务状态、任务定义、工具语义、成功标准、风险边界和模拟环境上。

Runtime 可以独立演化

Runtime 厂商可以专注执行效率、状态可靠性、Context 编译、Trace、Replay、安全和权限、长程任务恢复。

评价和训练平台能够消费统一轨迹

如果运行数据结构逐渐统一，评测平台和训练平台就可以直接使用任务状态、Context、决策、工具结果、人工修正和最终评价。这会使 Agent 的业务执行、系统优化和模型训练更容易形成闭环。

业务 Agent 可以形成独立生态资产

一个真正成熟的业务 Agent，不再只是 Prompt 和几个工具，而是一个包含任务、状态、策略、评价和模拟环境的完整软件包。

我对 Agent 生态发展的判断

所以我认为，Agent 生态形成“通用基座与业务定制层分离”的方向是合理的，但需要准确理解这种统一。

它不会表现为：

所有 Agent 都运行在同一个框架中。

而更可能表现为：

多个 Runtime 提供相似的运行机制，业务 Agent 以任务、状态、能力和评价为核心进行定义，二者之间逐渐形成稳定契约。

统一的是：

• 生命周期
• 状态与轨迹
• 执行机制
• 可观测性
• 回放与评价能力

无法完全统一的是：

• 业务世界
• 任务目标
• 状态语义
• 行动副作用
• 风险边界
• 真实成功标准

结语

Agent 生态真正需要寻找的，不是一个万能框架，而是一条稳定的分界线：

哪些能力属于所有 Agent 都需要的运行机制，哪些能力属于具体业务不可替代的世界语义？

如果这条边界能够建立，Agent 开发就会逐渐从“每个团队重新实现一套 Agent”，转向：

在通用 Runtime 上，对具体业务世界进行建模。

届时，Agent 的核心竞争力也不会只是模型能力或者 Prompt 技巧，而会越来越集中在：

• 谁能更准确地定义任务
• 谁能更完整地表达业务状态
• 谁能更可靠地验证结果
• 谁能更真实地模拟环境
• 谁能把运行轨迹转化为可持续改进的数据

所以，未来 Agent 生态真正可能共享的，不是一套统一的智能，而是一套让不同智能系统能够被可靠运行、观察、比较和改进的基础设施。