1. 为什么我要用纯 Java 去啃 Agent Harness 这块硬骨头

第一次听到“Agent Harness”这个词，很多人会下意识把它和“Agent 框架”画等号。我在团队内部做过一次小范围调研，十个人里有七个认为 Harness 就是又一个编排 Agent 的工具库。这个理解偏差，恰恰是我决定动手做 BizBuddy 的起点。Harness 的本意是“马具、挽具”，它的核心不是去定义马怎么跑，而是给马套上缰绳、鞍具和负载，让一匹力气再大的马也能被稳定地驾驭、被安全地调度、被可观测地管理。放到 AI Agent 的语境里，Agent Harness 解决的是“Agent 已经能干活了，但企业不敢让它真干活”这个问题。

BizBuddy 的定位就是这样一个企业级 Agent Harness 平台。它不负责训练模型，也不负责发明新的推理范式，它负责的是把 Agent 关进一个可控的笼子里：谁能调用、能调用哪些工具、调用几次、花了多少钱、出了事怎么回滚、审计日志留多久。这些听起来一点都不性感，但真正在企业里落地过 AI 应用的人都知道，决定项目生死的从来不是模型多聪明，而是这些“脏活累活”有没有人干。

关键词里出现了 AgentScope 和 RuoYi-Vue-Plus，这两个词其实透露了 BizBuddy 的技术底色。AgentScope 是阿里开源的多智能体框架，它把 Agent 的通信、消息、记忆这些抽象做得比较干净；RuoYi-Vue-Plus 则是国内 Java 圈子里非常成熟的后台管理脚手架，权限、菜单、数据字典、代码生成一应俱全。BizBuddy 的取舍很明确：Agent 的“大脑”部分尽量复用成熟生态，而 Harness 的“缰绳”部分必须自己用纯 Java 牢牢攥在手里。为什么是纯 Java？因为企业级场景里，你的 Agent 平台大概率要和现有的 Spring Boot 微服务、MyBatis-Plus 数据层、Sa-Token 权限体系长在一起，跨语言方案在演示阶段很酷，进了生产环境就是运维噩梦。

这篇文章适合三类人看：一是正在做 AI 应用落地、被合规和成本问题卡住的 Java 工程师；二是想理解 Agent Harness 和 Agent 框架本质区别的技术负责人；三是手里有 RuoYi-Vue-Plus 这类脚手架、想快速长出 AI 能力的团队。我会把 BizBuddy 从架构设计到关键取舍的完整思路摊开讲，包括我踩过的坑和那些文档里不会写的经验。

2. BizBuddy 的整体骨架：Harness 层到底该管什么

2.1 从“Agent 能跑”到“Agent 敢用”的鸿沟

大部分 Agent 框架的 Demo 都很惊艳：给一个目标，Agent 自己拆解任务、调用搜索、写代码、发邮件，一气呵成。但你把同样的东西放到企业内网，问题立刻爆炸。第一个问题是权限，Agent 调用数据库查询工具时，用的是谁的账号？如果是超级管理员，那它一句错误的 SQL 就能把核心表删了；如果是普通账号，那它很多该干的活又干不了。第二个问题是成本，一个复杂任务 Agent 可能循环调用大模型几十次，token 消耗像开了水龙头，财务月底看到账单会直接来找你。第三个问题是可观测性，Agent 决策链路是黑盒，出了错你连它为什么选那个工具都不知道，更别提复现。

BizBuddy 的 Harness 层就是来填这条鸿沟的。我把它的职责归纳成四件事：准入控制、执行沙箱、成本熔断、全链路审计。准入控制决定“这个 Agent 能不能被这个用户在这个场景下唤起”；执行沙箱决定“Agent 调用的每个工具在什么边界内运行”；成本熔断决定“这次任务最多烧多少钱、多少 token、多少时间”；全链路审计决定“事后能不能把每一步决策还原出来”。这四件事没有一件是模型层能解决的，它们全是工程问题，而工程问题恰好是 Java 的主场。

2.2 为什么 Harness 不等于 Agent 框架

这里必须把概念掰清楚，因为关键词里“harness和agent区别”本身就是热搜词，说明很多人在这上面犯迷糊。Agent 框架（比如 AgentScope）关注的是 Agent 内部的认知循环：感知、规划、记忆、行动、反思。它回答的是“Agent 怎么思考”。Agent Harness 关注的是 Agent 外部的运行环境：资源、权限、边界、监控。它回答的是“Agent 怎么被管”。

打个比方，Agent 框架是给赛车手设计的驾驶舱和方向盘，让他能开得快、开得稳；Agent Harness 是赛道的护栏、限速牌、维修区和裁判系统。你驾驶舱再先进，没有护栏，车冲出赛道就是车毁人亡。BizBuddy 选择把 AgentScope 这类框架当作“驾驶舱”来用，而自己专注做“赛道基础设施”。这个分工带来的直接好处是：Agent 框架迭代再快，我的 Harness 层接口保持稳定，上层业务代码不用跟着框架版本反复重写。

2.3 纯 Java 技术栈的选型逻辑

有人会问，做 AI 平台为什么不用 Python？Python 生态在模型侧确实无敌，但 BizBuddy 的 Harness 层几乎不碰模型推理，它碰的是 Web 服务、权限、数据库、消息队列、定时任务、分布式锁。这些领域 Java 的成熟度和稳定性是碾压级的。我列一下 BizBuddy 的核心技术选型，以及每个选择背后的理由：

这张表里最值得说的是“自研轻量状态机”这一条。我一开始想用 Flowable，毕竟它是 Java 流程引擎的老大哥。但实际画完 BizBuddy 的任务流转图后发现，Harness 层的状态机其实很浅：任务创建、准入校验、执行中、工具调用、成本检查、完成或熔断，总共不到十个状态。引入 Flowable 意味着多一套表、多一套 API、多一个运维对象，收益完全不成正比。自研一个基于枚举和事件驱动的状态机，两百行代码搞定，调试还方便。这就是典型的“企业级不等于堆组件”，能简单就别复杂。

3. 准入控制：把权限做到工具调用粒度

3.1 传统 RBAC 在 Agent 场景下的失效

传统后台系统的权限模型是 RBAC：用户属于角色，角色拥有菜单和按钮权限。这套模型在 Agent 场景下直接失效，因为 Agent 的“操作”不是点按钮，而是动态调用工具。同一个 Agent，在处理报销任务时应该只能读财务表，在处理招聘任务时应该只能读简历库。你没法给 Agent 预先分配一堆静态角色，因为它的任务组合是运行时才确定的。

BizBuddy 的做法是把权限下沉到“工具调用”这一层。每个工具在注册时声明自己的权限标识，比如tool:finance:read、tool:hr:resume:read。Agent 在执行任务前，Harness 层会根据当前用户身份、任务类型、Agent 配置，动态计算出一个“工具白名单”。Agent 只能调用白名单里的工具，调用白名单外的工具会直接被拦截并记录审计事件。这个设计的关键在于：权限判断发生在工具真正执行之前，而不是执行之后，杜绝了“先干了再补票”的风险。

3.2 工具白名单的动态计算

动态计算白名单听起来玄乎，实现起来其实是一套规则引擎。我用的是“用户角色 + 任务标签 + Agent 能力声明”三者求交集的方式。举个例子，一个财务部门的用户发起“月度报表分析”任务，任务标签是finance，他调用的 Agent 声明了finance:read、chart:render、email:send三个能力。Harness 层先取用户角色对应的工具集，再取任务标签对应的工具集，最后和 Agent 能力声明求交集，得到最终白名单。

这里有个容易踩的坑：交集运算的顺序会影响结果。我最初把 Agent 能力声明放在最后求交，结果发现某些场景下 Agent 声明的能力比用户权限还大，导致越权。正确顺序应该是先算“用户权限 ∩ 任务标签”，得到“本次任务允许的工具集”，再和 Agent 能力声明求交。这样 Agent 永远不可能拿到超出用户和任务范围的工具。这个顺序问题我在测试环境跑了一周才发现，因为大部分测试用例里用户权限都是全量的，掩盖了越权路径。

3.3 行级权限与数据脱敏的联动

工具白名单解决了“能不能调用”，但没解决“调用时能看到哪些数据”。比如一个查询订单的工具，财务能看全部订单，区域经理只能看本区域订单，这就是行级权限。BizBuddy 复用了 MyBatis-Plus 的行级权限插件思路，在工具执行 SQL 前动态拼接数据范围条件。具体做法是：工具声明自己操作的数据实体，Harness 层根据当前用户的数据范围配置，往 SQL 里注入region_id in (...)这样的条件。

更狠的一层是数据脱敏。Agent 调用工具拿到数据后，Harness 层会在返回给 Agent 之前做一次脱敏过滤。手机号、身份证、银行卡这些敏感字段，根据用户权限决定是明文、掩码还是直接剔除。为什么要放在 Harness 层而不是工具内部？因为工具是开发者写的，你没法保证每个工具都记得脱敏。放在 Harness 层统一处理，相当于给所有工具套了一层“安全滤网”，开发者写工具时可以专注业务逻辑。这个设计我强烈推荐，它把安全责任从“每个开发者”收敛到了“平台一次配置”。

4. 执行沙箱：让 Agent 的工具调用有边界

4.1 工具调用的三类风险与隔离策略

Agent 调用的工具五花八门，但风险可以归为三类：资源风险、副作用风险、数据风险。资源风险是工具执行太慢或太耗内存，把整个平台拖垮；副作用风险是工具执行了不可逆操作，比如发了邮件、扣了款、删了数据；数据风险是工具返回了不该返回的数据。BizBuddy 对这三类风险分别设计了隔离策略。

资源风险靠线程池隔离加超时控制。每个工具调用都跑在独立的线程池里，按工具类型划分池子，比如“查询类”池子给 20 个线程，“写入类”池子给 5 个线程。超时时间在工具注册时声明，默认 30 秒，查询类可以放宽到 60 秒，写入类收紧到 10 秒。超时后线程被强制中断，任务标记为失败并触发熔断检查。这里有个细节：Java 的线程中断不是强制的，工具代码如果不检查中断标志，超时了也停不下来。所以我在工具开发规范里强制要求：所有耗时循环必须检查Thread.currentThread().isInterrupted()。

4.2 副作用工具的两阶段提交

副作用风险是最棘手的。Agent 说“帮我发一封通知邮件”，邮件发出去就收不回来了。BizBuddy 的方案是给副作用工具加“两阶段提交”：第一阶段是“预执行”，工具只做校验和准备，不产生真实副作用，返回一个“执行凭证”；第二阶段是“确认执行”，Harness 层在确认所有前置条件满足后，才用凭证触发真实操作。如果任务在中途失败，凭证直接作废，副作用不会发生。

这个设计借鉴了数据库事务的思路，但实现上轻量得多。工具开发者只需要实现prepare()和commit()两个方法，Harness 层负责编排。我拿“发送邮件”工具举例：prepare()阶段校验收件人格式、检查邮件模板是否存在、生成邮件草稿并存入临时表；commit()阶段才真正调用邮件服务发送。如果 Agent 在发邮件前还需要查数据、做计算，这些步骤都在prepare()之后、commit()之前完成，任何一步失败都不会真的发邮件。实测下来，这个机制拦住了至少三次“Agent 算错数据差点发错通知”的事故。

4.3 工具执行的资源配额与降级

除了线程池和超时，BizBuddy 还给每个工具调用加了资源配额：单次调用最多消耗多少内存、最多发起多少次外部请求、最多读写多少行数据。这些配额在工具注册时声明，Harness 层通过字节码增强和代理拦截来监控。超配额的工具调用会被降级处理：要么返回缓存结果，要么返回一个“资源不足”的标准错误，让 Agent 自己决定是否重试或换方案。

降级策略我踩过一个坑。最初我让超配额的工具直接抛异常，结果 Agent 收到异常后疯狂重试，反而放大了资源消耗。后来改成“返回标准降级响应 + 在响应里附带重试建议”，Agent 拿到降级响应后，大部分情况下会选择换一个工具或降低查询范围，而不是无脑重试。这个细节说明：Harness 层和 Agent 的交互协议设计，比单纯的资源限制更重要。你限制得再死，Agent 不理解你的限制意图，照样能把系统玩坏。

5. 成本熔断：给 Agent 的 token 消耗装上电表

5.1 token 计量的三个层次

成本控制是 Agent 平台最容易被低估的部分。BizBuddy 把 token 计量分成三个层次：单次调用计量、单任务累计计量、单用户周期计量。单次调用计量最细，每次 Agent 调用大模型，Harness 层都记录输入 token、输出 token、模型名称、耗时；单任务累计计量把一次任务里所有调用加起来，和任务预算对比；单用户周期计量按天或按月统计，和用户配额对比。三层任何一层超限，都会触发对应的熔断动作。

计量数据从哪来？大模型 API 的响应里通常带 usage 字段，但有些自部署模型不返回。BizBuddy 的做法是双保险：优先用 API 返回的 usage，如果没有就用本地 tokenizer 估算。估算会有误差，但用于熔断判断足够了，因为熔断阈值本身会留 20% 的缓冲。这里的关键是：计量必须实时，不能等任务结束了再算总账。我见过有平台是任务结束后才统计成本，结果一个失控的 Agent 一晚上烧掉几百万 token 才被发现。BizBuddy 每完成一次模型调用就更新 Redis 里的计数器，超阈值立即中断任务。

5.2 熔断阈值的动态调整

固定阈值在真实场景里很难用。月初用户配额充足，阈值可以放宽；月底快超支了，阈值要收紧。不同任务类型也不一样，一个“生成周报”的任务可能 5000 token 就够，一个“代码审查”的任务可能要 50000 token。BizBuddy 的阈值是动态计算的：基础阈值由任务类型决定，再乘以用户当前配额余量系数，再乘以时段系数（高峰期收紧）。最终阈值 = 基础阈值 × 配额余量系数 × 时段系数。

这个公式看起来简单，但系数怎么定很有讲究。配额余量系数我用的是剩余配额 / 总配额的平方根，这样配额充足时系数接近 1，配额快用完时系数快速下降，起到“越接近上限越谨慎”的效果。时段系数在业务高峰期设为 0.8，低峰期设为 1.2，鼓励用户错峰使用。这些系数不是拍脑袋定的，是跑了两个月真实数据后调出来的。我建议刚开始做的时候先用固定阈值，积累一两个月数据后再上动态调整，否则你连基线都没有，调参就是瞎调。

5.3 熔断后的优雅降级

熔断触发后直接报错是最差的做法，用户体验断崖式下跌。BizBuddy 的熔断降级分三档：第一档是“换模型”，如果任务用的是高成本模型，熔断后自动切换到低成本模型继续执行，虽然质量可能下降，但任务能完成；第二档是“减步骤”，如果任务有多个可选步骤，熔断后跳过非核心步骤，只完成主干；第三档是“转人工”，如果前两档都不行，任务挂起并通知人工介入，同时把已完成的部分结果保存下来。

这三档降级策略的触发顺序是固定的，但每档是否启用可以按任务类型配置。比如“财务对账”任务不允许换模型，因为模型换了结果可能不一致，但允许转人工；“营销文案生成”任务允许换模型，因为文案质量差一点可以接受。这个配置化设计让不同业务线可以根据自己的容忍度来定策略，而不是被平台一刀切。

6. 全链路审计：Agent 决策的黑盒怎么打开

6.1 审计事件的粒度设计

审计不是简单记日志，记什么、记多细，直接决定事后能不能复盘。BizBuddy 的审计事件分四个粒度：任务级、步骤级、调用级、决策级。任务级记录任务的创建、开始、结束、结果；步骤级记录 Agent 规划的每个步骤及其状态；调用级记录每次工具调用和模型调用的输入输出；决策级记录 Agent 为什么选择这个工具、为什么跳过那个步骤。前三个粒度是标配，第四个粒度是 BizBuddy 的差异化。

决策级审计怎么实现？Agent 在规划时通常会输出“思考过程”或“推理链”，Harness 层把这些文本连同当时的上下文快照一起存下来。上下文快照包括：当前任务状态、可用工具列表、历史调用摘要、成本余量。这样事后复盘时，你能看到 Agent 在“当时那个信息环境下”为什么做了那个选择。我靠这个功能定位过一次诡异的问题：Agent 反复调用同一个查询工具，查了五次同样的数据。看决策级审计才发现，是因为工具返回结果里有个字段格式不一致，Agent 以为每次都是新数据。如果没有决策级审计，这个问题能查到你怀疑人生。

6.2 审计数据的存储与查询

审计数据的特点是“写多读少、量大、查询模式固定”。BizBuddy 用 MySQL 存最近 7 天的热数据，用 ClickHouse 存全量冷数据。写入路径是异步的：审计事件先发到 Redis 队列，后台消费者批量写入。为什么不用同步写？因为审计写入不能拖慢主流程，Agent 执行一次任务可能产生上百条审计事件，同步写 MySQL 会把响应时间拉高一个数量级。

查询路径按场景分流：日常排查走 MySQL，支持按任务 ID、用户 ID、时间范围快速检索；合规审计走 ClickHouse，支持复杂的聚合分析和长周期扫描。这里有个经验：审计数据的索引设计比存储引擎选择更重要。我在 MySQL 里给task_id、user_id、event_type、created_at建了联合索引，查询性能提升了十几倍。ClickHouse 里则用task_id做分区键，按天分区，查询时能快速裁剪数据范围。

6.3 审计与合规的衔接

企业级平台绕不开合规。BizBuddy 的审计模块预留了合规导出接口：按监管要求的时间范围、字段格式导出审计报告。导出时做两件事：一是脱敏，把审计事件里的敏感数据按规则掩码；二是签名，给导出文件生成哈希签名，防止篡改。这两件事听起来简单，但真到合规检查时，没有它们你就得手工处理，几百 GB 的审计数据手工脱敏是不现实的。

我还想强调一点：审计日志的保留策略要提前定。不同行业要求不一样，有的要求保留半年，有的要求三年。BizBuddy 的做法是分级保留：决策级和调用级保留三年，步骤级保留一年，任务级保留半年。过期数据自动归档到冷存储，而不是直接删除。这个策略是在和法务、运维反复沟通后定的，技术团队自己拍脑袋定保留期，很容易定得太短或太长，太短不合规，太长浪费存储。

7. 和 AgentScope、RuoYi-Vue-Plus 的集成取舍

7.1 AgentScope 在 Java 侧的适配层

AgentScope 原生是 Python 的，BizBuddy 要在 Java 侧用它，中间必须有个适配层。我的做法不是把 AgentScope 整个搬过来，而是只借用它的核心抽象：消息模型、Agent 通信协议、记忆接口。适配层用 Java 重新实现这些抽象，保持和 AgentScope 语义一致，但底层用 Java 的并发原语和数据结构。这样做的代价是要维护一份适配代码，收益是 Harness 层完全掌控在 Java 手里，不用为了一个 Python 依赖把整个部署链路搞复杂。

适配层最关键的是消息序列化格式。AgentScope 的消息模型比较灵活，支持嵌套结构和多种内容类型。我在 Java 侧用 Jackson 做序列化，但自定义了MessageDeserializer来处理多态内容。这里踩过一个坑：AgentScope 的消息里时间戳是浮点秒，Java 习惯用毫秒长整型，直接反序列化会丢精度。后来在适配层统一做了单位转换，所有时间戳进 Java 侧就转成毫秒。这种跨语言集成的细节问题，文档里通常不会写，但你不处理就会在某个深夜被一个时间差 bug 叫醒。

7.2 RuoYi-Vue-Plus 脚手架的复用与改造

RuoYi-Vue-Plus 帮我省了至少两个月的前端和基础后台工作。菜单、角色、用户、租户、操作日志、代码生成，这些企业后台的标配它都有。但直接拿来用有两个问题：一是它的权限模型是传统 RBAC，和 BizBuddy 的工具级权限不兼容；二是它的代码生成器生成的 CRUD 代码，和 Harness 层的状态机风格不一致。

我的改造策略是“复用基础设施，重写业务层”。用户、角色、菜单、租户这些基础表直接沿用，但在角色和工具之间加了一张关联表role_tool，把工具权限挂到角色上。代码生成器生成的代码只用作参考，实际业务代码手写，保持和状态机风格统一。这样既享受了脚手架的便利，又不会被它的设计约束绑死。我见过有团队为了“保持脚手架一致性”，硬把 Agent 任务塞进 CRUD 模型里，结果状态流转写得极其别扭。脚手架是工具，不是圣旨，该改就改。

7.3 集成后的性能与稳定性验证

集成完成后我做了三轮验证。第一轮是功能验证，跑通所有工具调用、权限校验、熔断降级、审计记录的主流程；第二轮是压力验证，用 JMeter 模拟 500 并发任务，观察线程池、Redis、MySQL 的表现；第三轮是故障注入，手动杀掉 Redis、断开 MySQL、模拟大模型超时，看 Harness 层能不能优雅降级。

压力验证暴露了一个问题：审计事件的 Redis 队列在高峰期会积压，因为消费者写入 ClickHouse 的速度跟不上生产速度。解决方案是给队列加了个“溢出策略”：队列长度超过阈值时，低优先级的审计事件（比如步骤级）直接采样丢弃，只保留高优先级的决策级和调用级。这个策略听起来有点粗暴，但审计数据本来就不需要 100% 完整，采样保留关键事件是业界常见做法。故障注入则验证了熔断和降级逻辑确实生效，Redis 挂掉后任务会快速失败而不是卡死，这点对用户体验很重要。

8. 踩过的坑和那些文档不会写的经验

8.1 线程池隔离的“假隔离”问题

我一开始给每个工具类型分了独立线程池，以为这样就隔离了。结果压测时发现，一个慢查询工具把“查询类”线程池占满后，“写入类”线程池虽然空闲，但任务还是卡住了。排查后发现，任务在进入工具调用前，会先经过一个公共的“准入校验”环节，这个环节用的是公共线程池。公共线程池被占满，所有任务都进不来，工具线程池再空闲也没用。

解决方案是把准入校验也做成异步非阻塞的，用 CompletableFuture 编排，不占用独立线程。或者给准入校验单独一个小线程池，和工具线程池完全隔离。我选了后者，因为异步改造涉及的面太广。这个坑的教训是：隔离要隔离到最外层，只隔离执行层不隔离准入层，等于没隔离。

8.2 成本计量的“重复计数”陷阱

成本计量有个隐蔽的坑：Agent 重试时，同一次逻辑调用可能产生多次物理调用，如果每次都计量，成本会被重复计算。我最初就是每次物理调用都加 token，结果发现一个任务的实际成本和计量成本对不上，计量值偏高。排查后发现是 Agent 在工具调用失败后重试，重试的调用也被计了费。

修复方案是引入“逻辑调用 ID”：Agent 发起一次逻辑调用时生成一个 ID，所有重试共享这个 ID。计量时按逻辑调用 ID 去重，只计第一次成功的调用。但这里又有个细节：如果重试是因为第一次调用真的消耗了 token（比如模型返回了部分结果后超时），那第一次的消耗还是要计的。所以最终逻辑是：按逻辑调用 ID 聚合，取所有物理调用中 token 消耗的最大值，而不是求和。这个逻辑我调了三次才调对，前两次要么少计要么多计。

8.3 审计日志的“写入放大”问题

审计日志写入放大是个容易被忽视的性能杀手。一条 Agent 决策可能触发十几个审计事件，每个事件都要序列化、入队、写库。压测时发现，审计写入占了整个任务耗时的 30%。优化手段有三个：一是批量写入，消费者攒够 100 条或超过 1 秒再写；二是压缩，审计事件的 JSON 用 GZIP 压缩后存储，查询时解压；三是采样，非关键事件按比例采样。

这三个手段里，批量写入效果最明显，直接把写入耗时降到了 5% 以下。压缩对存储成本帮助大，但对写入性能帮助有限，因为压缩本身也耗 CPU。采样要慎用，采样率定高了会丢关键信息，定低了没效果。我的经验是：决策级和调用级不采样，步骤级 50% 采样，任务级 10% 采样。这个比例是根据实际排查需求定的，大部分问题靠决策级和调用级就能定位，步骤级和任务级主要用于统计。

8.4 和现有微服务体系的“最后一公里”

BizBuddy 不是孤立系统，它要和公司现有的用户中心、消息中心、监控告警打通。这“最后一公里”往往是最耗时的。用户中心对接花了三天，因为对方的接口文档和实际行为不一致；消息中心对接花了两天，因为消息格式要来回对齐；监控告警对接花了一周，因为要定义清楚哪些指标告警、告警给谁、告警级别怎么定。

我的建议是：集成工作要提前排期，不要等到主体功能做完才想起来。主体功能做完时，团队往往已经疲惫了，这时候再去做繁琐的集成，容易敷衍了事。BizBuddy 的集成工作是和主体功能并行做的，虽然前期看起来进度慢，但后期没有集中爆雷。另外，集成接口要定义清楚“契约”，包括字段含义、错误码、超时行为、重试策略，这些不写清楚，联调时就是无尽的扯皮。

9. 这套 Harness 思路还能怎么延展

BizBuddy 目前跑在公司内部的三个业务线上，日均处理任务量在几千级别。回头看，这套 Harness 思路的价值不在于它用了多先进的技术，而在于它把企业落地 AI 时那些“不性感但致命”的问题系统性地解决了。权限、沙箱、成本、审计，这四件事任何一件没做好，AI 应用就只能在 Demo 阶段打转。

如果让我给正在做类似平台的同行一个建议，我会说：先把 Harness 层的接口定死，再去选 Agent 框架。接口定死了，框架可以换，模型可以换，业务代码不用动。我见过太多团队先选框架再设计接口，结果框架一升级，整个平台跟着重写。Harness 层的价值就在于它是“稳定层”，稳定层不稳定，上面盖什么都是危房。

后续我打算在 BizBuddy 上继续加两个能力：一是“工具市场”，让不同业务线把自己开发的工具注册上来，经过安全审核后供其他线复用；二是“Agent 行为基线”，用历史审计数据训练一个正常行为模型，Agent 行为偏离基线时自动告警。这两个能力都建立在现有的审计和权限体系上，算是水到渠成的延展。工具市场解决的是重复造轮子问题，行为基线解决的是“Agent 悄悄干坏事”问题，都是企业场景下的真实痛点。

最后分享一个我在做 BizBuddy 过程中反复验证的体会：企业级 AI 平台的竞争力，不在模型层，而在 Harness 层。模型能力大家都能买到，但把模型能力安全、可控、可计量地交付给业务，这件事没有捷径，只能一个工具一个工具地注册、一条规则一条规则地配、一个坑一个坑地填。纯 Java 做这件事，慢是慢了点，但每一步都踩得实。