我对AIPHarness开发框架技术架构设计

软件架构师罗小东，多年架构和平台产品设计经验，目前在Agent场景落地结合中。

概述

这个针对的解决的场景是业务场景的二次开发，API接口结合等能力，将传统的业务交互方式提交给Agent，通过Agentic的方式与业务进行结合。

比如做成业务版的WorkBuddy。

为什么要单独开发一套Harness开发框架，主要的原因是在Agent开发与交互中，在各个场景需要大量的定制，比如文件存储就可能是云存储/数据库/文件系统，不同的业务场景交互方式差异比较大，复杂界面交互注重体验。

前期设计于26年1季度的设计，原OpenClaw范式整理出来，开发框架会有三个场景：

• • TypeScript版：专门针对于轻后端的场景，直接就是一个JS框架引入即可使用；
• • Java后端：偏向于重Java后端，还有业务系统改造还有多任务后台场景；
• • rust桌面端：桌面安装型，本地执行还有注重隐私型的场景使用，类似于Codex；

找过三方开源比如AgentScope2.0，因为需要大量定制，但会深入发现，学习源码的成本比重新开发的成本还要高。基本上Harness引擎是一样的，交互逻辑也是一样的，只是使用的场景，方便不同的能力结合。

开发框架设计

整个设计是保留和扩展，主要是为了下一步的Loop Engineering做准备的。

能力设计

在业务系统集成过程中，我们对智能体所需的基础能力进行了统一抽象与封装。通用能力包括：

• • 用户画像：记录用户属性、偏好与历史行为，为个性化交互提供依据。
• • 上下文：管理多轮对话与任务执行状态，确保交互连贯性与一致性。
• • 执行沙箱：提供隔离、安全的代码执行与操作环境。
• • 文件系统：支持文件读写与组织管理，便于数据持久化与资源复用。
• • 权限系统：统一管理资源访问与操作权限，保障系统安全。
• • MCP/SKILL 工具：基于模型上下文协议（MCP）与技能（SKILL）封装外部工具，扩展智能体能力。
• • 消息与事件：实现消息传递与事件触发机制，支撑异步处理场景。
• • 计划模式：支持复杂任务的拆解、步骤编排与动态规划。
• • 连接器：提供面向第三方系统的标准连接能力，简化集成。
• • 专家套件：面向特定行业或领域提供专业处理能力。
• • 读写工具：封装各类数据存储的读写接口，方便数据交互。
• • 故障恢复：提供异常自动恢复与降级策略，保证系统稳定运行。
• •
• • ...

在通用能力之上，针对业务系统深度集成场景，进一步扩展了以下能力：

• • 界面交互：封装前端布局、事件触发与数据回显机制，使智能体能够嵌入业务页面完成可视化交互。
• • 积分体系：抽象积分账户、流水、规则与兑换模型，满足运营类业务需求。
• • 交互模式：支持对话、指令、审批、表单等多种交付形态，适配不同业务场景。
• • 工具分层：将工具按基础、通用、领域等层级划分，便于灵活组合与复用。
• • SKILL 分层：将技能从底层原子能力到高层业务流进行分层管理，降低维护复杂度。
• • 认证系统：统一身份认证与单点登录，打通组织、角色与权限体系。
• • ...

这些扩展能力主要来源于业务系统结合实践中的抽取、沉淀与封装，是 Harness 框架能力体系的重要组成。

这部分结合主要是在业务系统结合过程中的一些抽取和封装。

框架效果

集成框架效果是一个通用的交互框架，下面是代码模块的划分：

• • adapter: 与三方业务交互的方式，比如API接口引用。
• • business: 业务结合模块，根据不同的业务结合整合不同的内容。

前端交互效果主要是做了分栏，还有提供出通用的事件与交互能力，如下：

进入交互业务首页

单独ChatBot

类Codex交互

管理配置界面

结合案例

结合案例包括内部产品还有商业项目

这里列两个示例，一个是深度结合的方式，另一个是跟传统业务结合起来的效果与能力。区别点在于深度结合会直接嵌入到代码里面，结合得更加彻底，而传统业务结合通过API接口进行交互，类似于两套系统交互。

Agentic数据分析

基于Java版与数据中台结合的场景能力，将数据中台本身的能力提交给Agent，让它帮我们做业务分析，包括ETL工作流、数据质量、数据指标、数据服务、数据标准等由Agent来处理，如下：

Agent数据指标分析

以零售门店场景为例，Agent接到"把指标能力开放出来"的需求后，会直接把数据中台里的指标资产编排成一组可交付的数据服务。左侧的交付结果可以看到，Agent把门店营收、客流与客单、成本结构、盈利能力、营销与会员、数据质量六大类指标汇总成对外接口。

Agent数据仓库ETL与血缘分析

除了对外交付指标，Agent 同样深入到 ETL 与治理环节。这些不是写死的自动化，而是真正懂数据的助手行为。

血缘侧也同样交给 Agent 打理。它可以从某张 ADS 应用层表为起点做双向展开，追踪数据从贴源层 ods_、明细层 dwd_ 到应用层 ads_ 的完整流转路径，帮助确认指标口径来源是否可靠，还能输出"孤儿表清单"这类治理结论，把血缘治理从人工梳理变成 Agent 的日常巡检。

直观的感觉就是交互模式会改变，一切由Agent来协助处理。

业务版WorkBuddy

接入的业务系统提供的API接口，通过Harness框架的集成与开发，架构如下：

以电商场景为例，整体架构自下而上分四层。底层是基础环境：阿里云、MINIO 对象存储，以及 DeepSeek 大模型，提供算力、存储与模型能力。往上是电商核心系统：商品管理、订单管理、库存系统这些传统业务模块，本身不做 Agent 化改造，而是通过 AI 服务网关把业务能力统一暴露出来，配以公共包和开发规范约束接入方式，保证业务系统与智能体之间的边界清晰。

中间是 AIP 引擎，也是 Harness 框架的核心所在：会话管理、技能管理、MCP 管理、认证管理在上层做统一调度，Harness 引擎在底层承接模型调用、工具沙箱、记忆、智能体上下文与画像等能力，让上层的智能体既接得住业务系统，又具备稳定的执行环境。

最上层是电商 Agentic 应用：AI 商品选品、AI 订单分析、AI 风控运营、AI 售后预测，每个应用场景都会落到对应的领域技能上（选品技能、订单技能等），技能再去编排下层引擎与业务 API。整条链路里，传统电商系统并不需要重写，只需把商品、订单、库存等核心域能力通过网关注册给 Agent，上层应用就能像调用一个同事那样去组合使用它们。

右侧还配套了认证服务与权限服务，以及基于阿里云 CodeUp 的持续集成，说明这套架构不是实验性拼装，而是按可交付、可运维、可上线的工程标准来组织的。

同样是提供业务的能力给Agent。

总结

基础的模块还是最终的版本，我们想要的目标场景的Agent自进化，Harness底层的标准化是需要往Loop Engineering做准备，也是目前在规划和准备进一步实施的，形成智能体的业务场景和解决方案闭环。一些Harness的建设经验分享，欢迎有兴趣的朋友讨论。