Claude Code、Cursor 这些 Agent 产品，这一年几乎人人都在用——但不少开发者都发现，即使使用同一个底层模型，不同产品的实际体验也可能相差很大。

在 Terminal-Bench 等公开的 Agent 能力评测中，同一个模型运行在不同的 Agent 实现中，最终成绩往往会出现明显差异。一些工程团队也公开分享过，仅通过调整模型外的工程系统，不更换底层模型，就把自己的 Coding Agent 从榜单 Top 30 拉到了 Top 5。

这些现象说明，模型决定了 Agent 的能力上限，而模型之外的工程设计，同样深刻影响着 Agent 的最终表现。这部分能力就统称为 Agent Harness。

什么是 Agent Harness？

严格来说，目前行业并没有一个统一的定义。不同社区会使用 Agent Runtime、Agent Framework、Execution Layer 等不同名称。本文所说的 Harness，是一种广义的工程实践概念，指的是包裹在大模型外层、把模型的推理结果转化为真正能被执行的动作的那套工程系统——包括工具调用（Tool Use）、上下文管理、记忆（Memory）、任务编排（Workflow）、执行沙箱（Sandbox）、权限控制，以及审计与可观测性。

如果把模型比作“大脑”，Harness 更像是身体和神经系统：大脑负责思考，但身体决定这个思考能不能被真正执行出来——它能访问哪些资源、调用哪些工具、执行哪些操作，以及出现问题时如何恢复、如何追踪。

很多开发者会用一个便于理解的表达来描述 Agent：

Agent = Model + Harness

HashiCorp 创始人、Terraform 的作者 Mitchell Hashimoto 今年年初写过一篇文章，描述他用 AI Agent 时养成的一个习惯：每次 Agent 犯一个错，他不是简单地重新问一遍，而是把这个错误永久性地“焊”进 Agent 的运行环境里，让它不会再犯第二次。几周之内，OpenAI 和 Anthropic 的工程团队都跟进发了相关的技术博客。这种“先固化、再泛化”的实践，让行业逐渐意识到——围绕 Agent 的工程化（Harness Engineering），其重要性可能不亚于模型本身的迭代。

对个人用户来说，Agent 出错一次，重新问一遍就好。但企业生产落地完全是另一套逻辑——如果 Agent 能调数据库、调生产 API、执行脚本，企业首先关心的往往不是“它够不够聪明”，而是：它到底能做什么，又不能做什么？

过去一年，越来越多工程团队开始把关注点从模型能力转向运行环境，也沉淀出不少值得参考的经验。

例如，Anthropic 在工程实践中提到，企业级权限控制不应仅依赖 Prompt 中的自然语言约束，与其在 Prompt 里写“不要删除生产数据”这种软性提示，不如把权限做成 Harness 层真正可执行的结构化系统。Prompt 可以表达意图，但系统边界才能真正限制行为。

Letta 联合创始人 Sarah Wooders 也提出过一个很有代表性的观点：Memory 不应该只是一个外挂能力，而应该成为 Agent 运行环境的重要组成部分。 如果企业的业务记忆，全都沉淀在一个封闭的、自己不掌控的 Harness 里，一旦要换平台，就等于从零开始，之前积累的一切都带不走。

这些共同的经验都说明，Harness 不只是让 Agent 更好用，更是在决定企业如何管理 Agent。

Agent Harness 正在标准化，新的问题随之浮现

随着 Claude Agent SDK、AWS AgentCore 等 Agent SDK、运行平台陆续发布，搭建一套基础的 Agent Runtime，正在逐渐成为越来越标准化的能力。工作流编排、工具调用、基础可观测性等能力，已经可以通过云服务或开源框架快速获得。

这意味着，“有没有 Agent Runtime”逐渐不再是差异点。当大家的 Harness 能力趋同时，企业真正的分水岭开始浮出水面。

数据基础设施领域有一个经典的设计原则——Data Gravity（数据引力）。这一概念认为，当数据规模越来越大、关联越来越复杂时，相比反复搬运数据，把计算尽可能放到数据附近，通常成本更低、效率更高。近年来，包括 VAST Data 在内的不少厂商，也开始用这一思路来讨论 AI 时代的数据平台建设。

如果把 Agent 看作一种新的计算方式，那么：Agent 应该不断把数据接到自己的 Runtime，还是尽可能建立在企业已有的数据基础设施之上？

围绕这个问题，目前企业部署 Agent，大致可以看到两种不同的架构思路。

一类是独立 Runtime 模式：通过 MCP、API、Connector 把企业数据一点点接给一个新搭建、独立运行的 Agent Runtime，由 Runtime 负责工具调用、工作流和治理能力。这种方式部署灵活，也是目前很多通用 Agent 平台采用的思路。

另一种更接近“数据原生（Data-native） Agent”：Agent 尽可能建立在企业已有的数据基础设施之上，复用现有的数据模型、权限体系、计算能力和业务组件，而不是重新维护一套独立的数据运行环境。

两种方式都能够实现 Agent，但它们对企业数据基础设施的依赖关系并不相同。

DolphinX：一种更接近 Data-native Agent 的实践

对于已经拥有成熟数据基础设施的企业，与其重新建设一套 Agent Runtime，不如让 Agent 从第一天起，就建立在企业已经信任的数据与计算体系之上。

DolphinDB 本身作为高性能数据与计算平台，在企业生产环境里已经运行了很多年，管理时序、关系、数仓、文本、向量等多种类型的数据，承载批计算、流计算和异构计算，并且在金融、能源、工业这些场景里，早就沉淀了大量经过验证的业务组件。

基于这样的基础，我们在设计 DolphinX 时，并没有把 Agent 放在 DolphinDB 之外，再重新建设一套独立的 Runtime，而是选择让 Agent 建立在已有的数据与计算底座之上，尽可能复用企业已经积累的数据模型、权限体系和业务能力，而不是重复建设一套新的基础设施。

这是 DolphinX 最初的设计思路，也是我们理解企业级 Agent 的一种实现路径。

这种架构带来的变化，并不仅仅体现在部署方式上，更重要的是，很多企业原本已经解决过的问题，不需要围绕 Agent 再重新解决一遍。

Agent 长在数据入口上，调用数据无需绕路。 大多数 Agent 架构中，模型要访问企业数据，需要经过 MCP、API Gateway 或 Connector 层层转发。DolphinX 则完全不同：DolphinDB 本身就是企业的高性能数据入口，Agent 直接运行在数据之上，不需要接数据，数据就在脚下。

权限与治理规则与数据底座天然合一。 当 Agent 调用一个读取时序库的 Skill 时，它沿用的是该业务线工程师已有的 IAM 身份和访问权限；模型生成的脚本会经过静态代码分析，自动拦截 Drop Table 等高风险操作。企业已有的治理边界，不需要围绕 Agent 重新设计——因为它从一开始就长在企业的治理体系之内。

业务能力可以被沉淀为可复用的 Skill。 很多企业真正有价值的，并不是 Prompt，而是多年沉淀下来的运维经验、投研流程和业务规范。DolphinX 已内置覆盖金融业务、流计算、机器学习、运维、测试等场景的数十个 Skill。在此基础上，企业也可以将自己的内部经验沉淀为私有 Skill，Agent 面对类似任务时，就不需要每次重新摸索业务逻辑。这类幻觉问题，很大程度上是因为模型缺乏可复用的先验，而不完全是模型能力不够。知识库支持企业内部共享，不依赖上传云端，也不依赖个人本地环境。

记忆和上下文管理也是同理。 组织知识、团队经验和个人偏好可以分别沉淀，又能够在同一个业务语境下协同使用；系统会根据上下文预算动态组织提示词、历史摘要、Skill 和记忆，并支持开发者查看模型当前实际使用的上下文，让 Agent 的行为更容易理解和排查。

更进一步，当 Agent 不再是企业里的独立系统，治理方式也会随之发生变化。Agent、模型、Skill、MCP、权限以及审计日志可以统一纳入同一套管理体系，而不是分散在多个彼此独立的平台中分别维护。

结语

当业内还在争论如何用更长的 Prompt 或更复杂的思维链来约束 Agent 时，我们选择了一条更根本的路——让 Agent 从诞生之初就佩戴着企业的“基因”，即既有的数据模型、治理规则与业务经验。

企业级 Agent 的竞争，或许不会止于模型，而会越来越取决于它建立在怎样的基础设施之上。

如果你也在探索企业级 Agent 的落地，不妨体验一下 DolphinX，看看当 Agent 建立在企业已有的数据与计算基础设施之上，会带来怎样不同的开发与运行体验。

欢迎下载 DolphinX 进行体验，也欢迎与我们交流你的实践和思考。