兹拉坦发表了一篇文章分析主流 Agent 框架 LangChain 公司从零构建数据库的举措一个事实是 Agent 竞赛正从模型层悄然转向数据层。当 Agent 运行产生海量半结构化、高频写入、长生命周期的 trace 数据时传统数据库架构难免捉襟见肘而数据在观测平台、向量库、缓存系统之间反复搬运更让沉淀—提炼—反哺的闭环效率大打折扣。这揭示了一个关键分野从 Agent 框架往下做数据库与从成熟数据库往上接 Agent 框架起点不同成本结构迥异。后者意味着数据从第一行代码起即为原生公民运行、记录、提炼、评测、反哺全部在同一底座内完成无需跨系统搬运的损耗。All-in-one 数据底座的价值正在于此——让 Agent 的数据闭环成为内循环而非割裂的工程拼图。 本文从 Harness 的定义出发结合开源项目 Bub 的设计实践探讨 Agent 架构的分层理念最终落到数据库原生 Harness 的技术路线——以及 OceanBase 在这一领域的探索实践与价值。一、理解 Agent 与 Harness 的构成及关系Agent 的完整形态可以表述为「模型 Harness」。Harness 涵盖模型之外的所有工程组件——类比马具之于马匹Harness 是人驾驭模型到达目的地所需的一整套工具包括缰绳、马鞍、路线对应到技术层面就是反馈机制、记录系统与训练方法。Harness 本身具有明确的分层结构。第一层由 Coding Agent 构建方或 SDK 厂商提供包含基础工具与对外接口第二层则由用户在业务侧扩展自己需要的组件比如引入 RAG 系统、Memory 系统、BI 链路等业务逻辑。在 Agent 场景中模型本身并非一个持续状态化的系统——它根据请求返回响应而不感知具体的业务状态。真正让 Agent 能在产品和团队中稳定工作的是 Harness 所承担的上下文管理、工具调用、状态记录、运行轨迹追踪、效果评估以及数据流转等一系列职责。在此过程中我们会逐步识别并抽象出一些关键要素定义为 “原语Primitive” 。例如系统提示词System Prompt、技能Skills、任务完成方法论、多智能体间通信机制等都是随着实践沉淀下来的重要原语。将这些原语标准化并纳入 Harness一方面能提升业务表现、扩展能力另一方面也使 Harness 本身逐渐产品化。同时从 Harness 中采集的数据至关重要。它们既用于评估工作流效果经过脱敏处理后也可构成标准数据集用于训练下一代模型。模型改进后又会反哺 Harness 中原语的发现与优化甚至对过往行为进行纠偏从而形成一个持续改进的飞轮。下图源自 LangChain 的博客清晰地展示了这一闭环。二、构建可扩展的智能体以 Bub 项目为例Bub 是 GitHub 上的一个开源的 Python Agent 项目其设计体现了控制 Agent 复杂度的关键思路通过精简内核与插件化扩展实现稳定性与灵活性的平衡。当前主流 Agent 产品如 ChatGPT、通义千问、ModelScope 服务以及 Dify、Flowise 等低代码平台均已内置 Agent Loop。但一个核心问题是Agent 的能力范围必须与业务场景精准匹配。尽管 Skills 和工具可以扩展能力但为了保证任务完成的高效性仍需针对具体场景组装工具集。很多热门产品如OpenClaw、Nanobot、Hermes Agent 等产品把过多功能捆绑在一起这带来了两个问题对用户造成功能干扰和心智负担对开发者而言系统复杂度高维护困难例如 OpenClaw 的版本升级常引发广泛功能失效。这种高度耦合的设计在生产环境中难以直接使用。许多厂商因此选择基于特定版本二次封装或走向完全自研。Bub 采用了不同的架构策略构建一个轻量内核并通过插件机制扩展功能。也就是将额外功能分离为插件仅维护精心设计的精简内核实现稳定的 Agent Loop通过功能插件逐步引入业务所需能力。用户只需验证插件工作状态是否正常如果某个插件出现问题摘除这个问题插件即可恢复系统服务极大提升了可维护性。Bub 的核心设计哲学是不关注单个 Agent 的强大程度而是关注单次交互中的阶段划分。无论是 Bub 内置 Agent 还是外部引入的 Codex、LangChain均可完成工作。Bub 将交互拆分为明确阶段对话状态构建、提示词组装、Channel 的 Input/Output 定义等。这种阶段化拆解使流程控制成为可能通过 Hooks 暴露各阶段接入点而非在单个 Agent 内堆砌所有逻辑。一个关键设计是解除 Output 的强制绑定。传统系统将消息回复严格绑定到输入 Channel而 Bub 允许 Agent 在特定场景下「沉默」——不返回消息。这在个人助手场景看似缺陷但在多人协作或多 Agent 协作场景中避免噪音的沉默反而是友好特性。当前社区正涌现一系列方案来促进 Agent 设计的标准化与模块化例如Agents.md用于注入系统和任务相关的提示词。Skills将通用 SOP如文档写作、代码审查沉淀为可分发资产无需硬编码到 Agent Loop 中。MCP (Model Context Protocol) 通过插件提供各类 IM Channel 适配、定时任务、AG-UI 可视化界面等。这正是 2026 年主流 Agent 框架演进的方向。Bub 项目便是这一理念的实践它仅用数百行代码的核心接口便构建了一个灵活的基础设施。三、从上下文到数据闭环Tape 概念与数据库原生的 Harness1. 以 Tape 为核心构建数据闭环Tape是 Bub 以及我们正在开发的 AgentSeek 项目的核心概念并非简单的聊天记录。它在某种程度上与 Trace追踪类似记录了单次 Agent 运行过程中的关键事实。但与 OpenTelemetry 等可观测性体系中的 Trace 不同Tape 的视图更简洁虽有关联性但不过度关注细节。它的独特价值在于既是可观测性数据也是上下文模型Tape 承载了关键任务的可观测性同时作为 Agent 运行时的上下文模型。这意味着人与 AI 可以基于同一份数据视图来协作。Agent 可以通过读取自身的 Tape 进行行为复盘。赋能 Agent 自省与问题诊断传统上Agent 出错需工程师通过可观测性平台排查。基于 Tape用户可直接与 Agent 对话询问“刚才为何失败”工程师的排查也变为与 Agent 的自然对话因为根因信息已内置于其上下文中。支持自动化评估与分析基于 Tape 记录可以由 Agent 自主对比不同模型或同一模型在不同任务下的表现实现自动化的对照评估而无需依赖面向人的看板。服务于模型训练通过脱敏和格式化导出Tape 同样可以便捷地转化为特定任务的数据集用于模型的训练和微调从而真正打通从上下文、可观测性到模型训练的数据闭环。2. 为何需要数据库原生的 Harness以 OpenClaw 为代表的 Agent 系统其数据严重依赖文件系统如各种 .md 文件。虽然对人类和 Agent 阅读友好但极不利于数据的加工、分析和处理。现代的上下文工程需要在原始任务轨迹之上构建一层 Memory它既是对轨迹的摘要也是索引。OpenClaw 社区后来出现的无损上下文插件如 lossless-claw开始使用 SQLite 等数据库来串联调用链和记忆这正说明了数据库在此环节中的必要性。将数据库作为 Harness 的基石意味着所有 Agent 运行数据天生就是数据库中的“一等公民”。可观测性、数据提取、归档分析都能利用数据库的原生能力无需维护复杂异构的数据栈如 MySQL Elasticsearch Redis。这提供了一个统一的数据底座简化了架构降低了运维成本。OceanBase 是这一路线的优质选项为什么其核心优势包括AI 工作负载就绪OceanBase 及其衍生的工具均为 AI Agent 工作负载优化提供了向量检索、融合检索能力。SQL 能力结合向量、全文检索均为内置功能无需额外维护多个技术栈 。HTAP 能力作为混合事务/分析处理数据库可直接支持对 Agent 运行数据的实时查询和复杂分析助力数据闭环。统一存储与无缝扩展各类数据可统一存储支持运行轨迹分析、检索等工作负载探索。从端侧的单机部署如OceanBase seekdb可无缝扩展至分布式 OceanBase 集群为业务增长提供平滑升级路径。四、AgentSeek数据库原生 Harness 的探索魔搭社区的 Endless Context 项目是基于 Bub 和 Tape 理念构建的 OpenClaw 类智能体案例也是数据库原生 Agent 的一个简单呈现。通过对 Agent 架构的持续探索OceanBase 团队正在构建完全基于数据库原生能力的 Agent Harness——AgentSeek5月30日发布文末预约现场名额。AgentSeek 的核心理念让 Agent 运行时数据从第一天起成为数据库的一等公民帮助用户构建数据闭环场景。该项目整合 OceanBase 产品能力与 AgentSeek 相关 Wrapper目前处于积极推进阶段。结语从 Harness 的分层定义到 Bub 的插件化可扩展架构再到 Tape 实现的可观测性与上下文一体化最终落到数据库原生 Harness 的技术路线——Agent 基础设施的演进正从「功能堆砌」走向「数据驱动」。OceanBase 在这一领域的布局既是技术架构的自然延伸也是对 AI 时代数据底座需求的回应。
All-in-one数据底座的价值与实践：基于Harness的解读
兹拉坦发表了一篇文章分析主流 Agent 框架 LangChain 公司从零构建数据库的举措一个事实是 Agent 竞赛正从模型层悄然转向数据层。当 Agent 运行产生海量半结构化、高频写入、长生命周期的 trace 数据时传统数据库架构难免捉襟见肘而数据在观测平台、向量库、缓存系统之间反复搬运更让沉淀—提炼—反哺的闭环效率大打折扣。这揭示了一个关键分野从 Agent 框架往下做数据库与从成熟数据库往上接 Agent 框架起点不同成本结构迥异。后者意味着数据从第一行代码起即为原生公民运行、记录、提炼、评测、反哺全部在同一底座内完成无需跨系统搬运的损耗。All-in-one 数据底座的价值正在于此——让 Agent 的数据闭环成为内循环而非割裂的工程拼图。 本文从 Harness 的定义出发结合开源项目 Bub 的设计实践探讨 Agent 架构的分层理念最终落到数据库原生 Harness 的技术路线——以及 OceanBase 在这一领域的探索实践与价值。一、理解 Agent 与 Harness 的构成及关系Agent 的完整形态可以表述为「模型 Harness」。Harness 涵盖模型之外的所有工程组件——类比马具之于马匹Harness 是人驾驭模型到达目的地所需的一整套工具包括缰绳、马鞍、路线对应到技术层面就是反馈机制、记录系统与训练方法。Harness 本身具有明确的分层结构。第一层由 Coding Agent 构建方或 SDK 厂商提供包含基础工具与对外接口第二层则由用户在业务侧扩展自己需要的组件比如引入 RAG 系统、Memory 系统、BI 链路等业务逻辑。在 Agent 场景中模型本身并非一个持续状态化的系统——它根据请求返回响应而不感知具体的业务状态。真正让 Agent 能在产品和团队中稳定工作的是 Harness 所承担的上下文管理、工具调用、状态记录、运行轨迹追踪、效果评估以及数据流转等一系列职责。在此过程中我们会逐步识别并抽象出一些关键要素定义为 “原语Primitive” 。例如系统提示词System Prompt、技能Skills、任务完成方法论、多智能体间通信机制等都是随着实践沉淀下来的重要原语。将这些原语标准化并纳入 Harness一方面能提升业务表现、扩展能力另一方面也使 Harness 本身逐渐产品化。同时从 Harness 中采集的数据至关重要。它们既用于评估工作流效果经过脱敏处理后也可构成标准数据集用于训练下一代模型。模型改进后又会反哺 Harness 中原语的发现与优化甚至对过往行为进行纠偏从而形成一个持续改进的飞轮。下图源自 LangChain 的博客清晰地展示了这一闭环。二、构建可扩展的智能体以 Bub 项目为例Bub 是 GitHub 上的一个开源的 Python Agent 项目其设计体现了控制 Agent 复杂度的关键思路通过精简内核与插件化扩展实现稳定性与灵活性的平衡。当前主流 Agent 产品如 ChatGPT、通义千问、ModelScope 服务以及 Dify、Flowise 等低代码平台均已内置 Agent Loop。但一个核心问题是Agent 的能力范围必须与业务场景精准匹配。尽管 Skills 和工具可以扩展能力但为了保证任务完成的高效性仍需针对具体场景组装工具集。很多热门产品如OpenClaw、Nanobot、Hermes Agent 等产品把过多功能捆绑在一起这带来了两个问题对用户造成功能干扰和心智负担对开发者而言系统复杂度高维护困难例如 OpenClaw 的版本升级常引发广泛功能失效。这种高度耦合的设计在生产环境中难以直接使用。许多厂商因此选择基于特定版本二次封装或走向完全自研。Bub 采用了不同的架构策略构建一个轻量内核并通过插件机制扩展功能。也就是将额外功能分离为插件仅维护精心设计的精简内核实现稳定的 Agent Loop通过功能插件逐步引入业务所需能力。用户只需验证插件工作状态是否正常如果某个插件出现问题摘除这个问题插件即可恢复系统服务极大提升了可维护性。Bub 的核心设计哲学是不关注单个 Agent 的强大程度而是关注单次交互中的阶段划分。无论是 Bub 内置 Agent 还是外部引入的 Codex、LangChain均可完成工作。Bub 将交互拆分为明确阶段对话状态构建、提示词组装、Channel 的 Input/Output 定义等。这种阶段化拆解使流程控制成为可能通过 Hooks 暴露各阶段接入点而非在单个 Agent 内堆砌所有逻辑。一个关键设计是解除 Output 的强制绑定。传统系统将消息回复严格绑定到输入 Channel而 Bub 允许 Agent 在特定场景下「沉默」——不返回消息。这在个人助手场景看似缺陷但在多人协作或多 Agent 协作场景中避免噪音的沉默反而是友好特性。当前社区正涌现一系列方案来促进 Agent 设计的标准化与模块化例如Agents.md用于注入系统和任务相关的提示词。Skills将通用 SOP如文档写作、代码审查沉淀为可分发资产无需硬编码到 Agent Loop 中。MCP (Model Context Protocol) 通过插件提供各类 IM Channel 适配、定时任务、AG-UI 可视化界面等。这正是 2026 年主流 Agent 框架演进的方向。Bub 项目便是这一理念的实践它仅用数百行代码的核心接口便构建了一个灵活的基础设施。三、从上下文到数据闭环Tape 概念与数据库原生的 Harness1. 以 Tape 为核心构建数据闭环Tape是 Bub 以及我们正在开发的 AgentSeek 项目的核心概念并非简单的聊天记录。它在某种程度上与 Trace追踪类似记录了单次 Agent 运行过程中的关键事实。但与 OpenTelemetry 等可观测性体系中的 Trace 不同Tape 的视图更简洁虽有关联性但不过度关注细节。它的独特价值在于既是可观测性数据也是上下文模型Tape 承载了关键任务的可观测性同时作为 Agent 运行时的上下文模型。这意味着人与 AI 可以基于同一份数据视图来协作。Agent 可以通过读取自身的 Tape 进行行为复盘。赋能 Agent 自省与问题诊断传统上Agent 出错需工程师通过可观测性平台排查。基于 Tape用户可直接与 Agent 对话询问“刚才为何失败”工程师的排查也变为与 Agent 的自然对话因为根因信息已内置于其上下文中。支持自动化评估与分析基于 Tape 记录可以由 Agent 自主对比不同模型或同一模型在不同任务下的表现实现自动化的对照评估而无需依赖面向人的看板。服务于模型训练通过脱敏和格式化导出Tape 同样可以便捷地转化为特定任务的数据集用于模型的训练和微调从而真正打通从上下文、可观测性到模型训练的数据闭环。2. 为何需要数据库原生的 Harness以 OpenClaw 为代表的 Agent 系统其数据严重依赖文件系统如各种 .md 文件。虽然对人类和 Agent 阅读友好但极不利于数据的加工、分析和处理。现代的上下文工程需要在原始任务轨迹之上构建一层 Memory它既是对轨迹的摘要也是索引。OpenClaw 社区后来出现的无损上下文插件如 lossless-claw开始使用 SQLite 等数据库来串联调用链和记忆这正说明了数据库在此环节中的必要性。将数据库作为 Harness 的基石意味着所有 Agent 运行数据天生就是数据库中的“一等公民”。可观测性、数据提取、归档分析都能利用数据库的原生能力无需维护复杂异构的数据栈如 MySQL Elasticsearch Redis。这提供了一个统一的数据底座简化了架构降低了运维成本。OceanBase 是这一路线的优质选项为什么其核心优势包括AI 工作负载就绪OceanBase 及其衍生的工具均为 AI Agent 工作负载优化提供了向量检索、融合检索能力。SQL 能力结合向量、全文检索均为内置功能无需额外维护多个技术栈 。HTAP 能力作为混合事务/分析处理数据库可直接支持对 Agent 运行数据的实时查询和复杂分析助力数据闭环。统一存储与无缝扩展各类数据可统一存储支持运行轨迹分析、检索等工作负载探索。从端侧的单机部署如OceanBase seekdb可无缝扩展至分布式 OceanBase 集群为业务增长提供平滑升级路径。四、AgentSeek数据库原生 Harness 的探索魔搭社区的 Endless Context 项目是基于 Bub 和 Tape 理念构建的 OpenClaw 类智能体案例也是数据库原生 Agent 的一个简单呈现。通过对 Agent 架构的持续探索OceanBase 团队正在构建完全基于数据库原生能力的 Agent Harness——AgentSeek5月30日发布文末预约现场名额。AgentSeek 的核心理念让 Agent 运行时数据从第一天起成为数据库的一等公民帮助用户构建数据闭环场景。该项目整合 OceanBase 产品能力与 AgentSeek 相关 Wrapper目前处于积极推进阶段。结语从 Harness 的分层定义到 Bub 的插件化可扩展架构再到 Tape 实现的可观测性与上下文一体化最终落到数据库原生 Harness 的技术路线——Agent 基础设施的演进正从「功能堆砌」走向「数据驱动」。OceanBase 在这一领域的布局既是技术架构的自然延伸也是对 AI 时代数据底座需求的回应。
