从问数工具到运营搭档：慧博科技基于Qoder Cloud Agents打造“小慧Claw”

品牌运营的一天，往往是从一堆重复动作开始的：导出昨天的经营数据、截图、写一段经营小结发进群，大促期间这件事每天要吃掉二十分钟。慧博科技把这类活儿交给了小慧Claw，一个跑在 Qoder Cloud Agents（简称 QCA）上的 AI 运营助手，它承担重复的数据整理、信息同步和定时汇报等执行环节，让运营团队把时间留给真正需要判断和决策的工作。

这篇文章讲清楚它是怎么接进 QCA 的，中间踩了哪些坑，以及跑出了什么样的数据。

慧博科技与小慧Claw

北京慧博科技有限公司是一家 AI 驱动的全域消费者数字化运营服务商，13年深耕电商零售一线，服务 2000 多家行业头部品牌。

小慧Claw 的定位是北京慧博科技有限公司的"电商零售品牌专属 AI 金牌运营团队"，不是又一个数据查询工具，而是一个能看数据、做分析、排任务、推消息的运营搭档。核心场景有四个：自然语言问数、智能报表、经营预警、运营诊断，再加一条执行闭环，结合诊断自动生成画布流程，经用户确认后自动执行。它还具备多 Agent 集群能力，围绕周期复购、小样转正、入会首购、流失召回、购后入会等场景识别运营机会，先给出分析、建议和营销画布草稿，再进入人工确认和业务系统执行。

Qoder Cloud Agents与小慧Claw的架构探索及选型

2.1 架构演进历程：从Prompt、Workflow，再到Harness

小慧Claw 不是一上来就是现在这个样子，慧博走过了三段路。

最早是 Prompt 工程，把业务规则、指标口径、输出格式全写进提示词，让通用大模型当"全能顾问"。问题是模型接不了企业数据，上下文越塞越满、注意力被稀释，断线即忘。

第二段是 Workflow 编排。为了可控可审计，把执行固化成节点与连线，自建了集成平台、营销画布、报表中心，2025 年之后上了一整套 workflow：意图识别、槽位抽取、分支路由、接口编排、话术模板拼装。运行大半年后，两处瓶颈暴露出来。一是维护成本不按加法增长，二是更根本的问题：系统能回答什么，在设计流程图的那天就已经固定，用户的问题只要落在预设分支之外，就只能回一句"暂不支持"。

于是有了第三段，也就是现在的：以 QCA 为执行底座，给智能体装上"操作系统"。Workflow 的控制流在开发者画的图里，模型只是图中某几个节点的填充物；Harness 反过来，控制流在模型手里，工程提供的是运行时、工具、约束和反馈。用慧博内部的说法，agent 是决策单元、是工人，harness 是围绕它的整套运行时和机制层、是工厂和规章制度。

2.2 五个痛点，同一个根因

换范式之前，运营侧的痛点集中在五个地方。

• 取数靠排期，"8 月 26 日会员 GMV 按日汇总"这类临时意图不在任何预定义节点里，只能等分析师排期，从数小时到数天。
• 口径反复对，同一指标的商智口径与店铺口径存在差异，流程不理解语义、无法自证。
• 报表手工填，流程之间不连通，人成了系统之间的胶水，固定监控模板和周报月报全靠手工搬数。
• 多平台割裂，跨淘宝、天猫、京东、抖音的统一视图需要人逐个登录拼接。
• 分析门槛高，会员分层、人群圈选本质是自由推理，画布表达不了，中小商家也养不起数据团队。

五个痛点指向同一个结论：不是流程不够多，而是流程这种形态天生装不下"意图"。要系统性解决，需要的不是再加几百张流程图，而是换一种执行架构。

2.3 基于Qoder Cloud Agents的分工边界

小慧Claw 的执行底座是 QCA。QCA 承载智能体运行、会话、事件流、文件处理和自动任务调度；慧博负责产品交互、AI 网关、Skill、MCP 数据工具层、云千载全域数据中台、租户与权限治理，以及人在环路机制。两边能力组合起来，小慧Claw 才能调用业务工具、持续执行复杂任务、返回文件或结构化结果，同时把关键决策留给业务人员。

2.4 基于Qoder Cloud Agents的架构示意

慧博把大模型看作一块高性能"裸 CPU"，QCA 的四层运行模型就是它的操作系统：Environment 是隔离的进程空间，Session 是内存，Event 是可恢复的中断，技能与工具是随装随用的程序库。执行主链路是自然语言 → 意图识别 → 报表参数编排 → 数据工具调用 → 技能加工 → 流式交付。工具层封装了 82 个 MCP 工具，一次封装、全域共享。

工程实践与经验沉淀

3.1 为什么使用Qoder Cloud Agents中的Forward Mode API？企业Agent需求：降低自建成本。

自研 Harness 慧博认真评估过。要上生产，至少得自己实现 agent loop、工具执行沙箱、长连接和断线恢复、上下文压缩、技能加载、多租户隔离、凭证托管、事件流、限流计费，每一项都是季度级工作量，而且稳定性很难一次做对：上下文压缩的时机差一点，长任务就开始遗忘；沙箱隔离漏一处，toB 客户之间就可能串数据。作为一家业务公司，这些能力做好了客户感知不到，做不好就是生产事故。结论是走云上托管，选了 QCA。

省下自建成本只是表面收益，真正决定选型的是 Forward Mode 里的几个重要能力。

Template 起初被当成 system prompt 的存放处，实际用起来才发现它封装的是一整套资源：Environment、Skills、Vaults、Models、System Prompt。小慧Claw 的技能是分领域独立打包、独立版本化的，数据查询、表格回填、画布编排、效果洞察各自是一个 skill 包。基础版客户只挂数据查询，旗舰版全挂，这个差异在 Template 层面配置即可，不涉及代码分支。QCA 的 skill 是"壳 + 不可变版本快照"两层结构，关联时省略 version 就跟随最新版，填入具体版本号则钉死该版本。内部 Template 跟随 latest，客户 Template 钉住已验证版本，灰度发布就是这么做的。

Identity 则是多租户隔离单元。慧博做的是企业服务，客户之间的数据必须绝对隔离。传统做法是自己建一套用户体系、数据域、权限层，还要谨慎维护三者的映射关系，实现难度不高，难在长期保证不出错。QCA 把这层内建了：一个企业账号，给每个客户开一个 Identity，不同 Identity 之间的记忆库、文件、凭证互相看不见。发起会话时同时传 template_id 和 identity_id，前者决定"能做什么"，后者决定"是谁、在哪个隔离域"。更关键的是 Identity 支持独立配置，同一个 Template 下可以给不同客户配不同模型、不同技能开关、不同预算，不必为每个客户复制一份 Template。凭证方面用 Vaults 把客户数据接口的 Key 托管在平台侧，业务代码里不持有任何客户密钥，这在安全评审中显著降低了合规成本。

Session 级沙箱隔离、SSE 事件流、文件上传与挂载、持久化记忆、记忆整理（Dreams）、定时任务、Webhook、IM 渠道接入，这些原本都在我们的自研清单上，现在都收敛为一次 API 调用。

IM 接入和定时调度的收益最直接。小慧Claw 的店铺日报、客户分层周报这类自动任务，走的就是 QCA 的 Schedules 加 Channels：客户扫码绑定之后，Agent 直接进他们的企微群和飞书群，到点执行、到点推送。这两块对接代码我们一行都没写。

3.2 六条工程化实战经验

一是先做概念映射，再做接口设计。完整对齐 QCA 四层运行模型（Agent / Environment / Session / Event），会话管理、消息记录、自动任务天然对齐，消息记录以远端事件 ID 作为同步指纹，避免二次改造。

二是"可回退的灰度"比"一步到位"更重要。从自建编排迁移到 QCA 时用双轨并存加服务端灰度开关，新旧通道同时在线，出问题即时切回。

三是断线恢复是一等公民，不是异常处理。深度分析任务动辄数十分钟到数小时，对话走 SSE 流式传输，刷新或切换会话后以 resume 模式接回正在执行的任务。

四是安全约束前置，是商务谈判中最有力的信任基础。商家数据强制隔离、数据最小化、效果指标必须有验证来源、三级确认门槛、写操作幂等、短信场景最小化、自动任务只生成草稿、服务端不信任前端身份、前端不直连外部 AI 服务，这九条铁律在接入之初就定死。

五是把提示词当产品资产来治理。模板等于系统提示词、模型、技能集、工具集的版本化组合，每次变更走配置化流程，可审计、可回滚、可灰度。

六是工具暴露面最小化。82 个 MCP 工具不等于全量开放，按场景做黑白名单最小授权，动态注入的托管工具默认只生成草稿。

3.3 三个技能相关的心得经验

三个技能面对的问题不同，踩过的坑却高度相似。主线只有一条：凡是能用程序判定的，绝不交给模型自评；不能程序判定的，就固化为可追溯的中间态，保证事后可核查。

数据查询要用单技能路由 100 多张报表。矛盾不在数量，而在语义高度重叠、参数体系各不相同、同一个词在不同维度指向完全不同的报表族。解法是把知识做成按需加载的分层文档：入口只负责"怎么找到规则"，规则命中之后才加载。于是知识体量可以做到上万行，单次查询真正进入上下文的只有两百多行，约占 2%，且不随报表数量增长。另一条原则是归属优先于结果，查得出数据不等于路由正确，口径错了但数字有，比查不到更危险，因为填错了用户会直接拿去汇报。

表格回填是长程任务，用户上传空表，Agent 自动识别表头、路由报表、查询、回填、校验、交付成品文件。它有三类典型失效：上下文压缩把关键映射压掉、数据量上来后回填整体错位、长任务末尾的"假完成"。共同点不是模型能力不够，而是把不该放在上下文里的信息放在了上下文里。对策是关键事实全部外置到工作区文件、口径先固定再动手、每个要写入的值都必须先说明来源，来源不明只能登记为例外。这里还有一条"失败翻译规则"，来自一次真实事故：某平台会员接口没有返回，Agent 直接给用户写了"该品牌无会员体系"，用户采信了。从此规定，接口失败只能说明当前路径未证实，不能翻译成业务结论。

在线营销是写操作，会真实触达消费者，此处的幻觉后果不是数据填错，而是十万条短信被真实发出。慧博把它拆成读、写两个独立技能，编排状态文件的写入权限只归写技能。这里有一次值得说的返工：连线合法性最初由一份人工整理的白名单校验，上线后大量合法连线被误拦，约三十个节点类型完全缺失，生成的流程根本无法使用。加校验器本是为了防幻觉，结果校验器自己成了故障源，根因是人工转写：凡是"一处有真相、另一处有人工摘要"的结构，摘要一定会随时间失真。修复方式是建立单一权威源：由脚本从后端原始配置直接生成校验规则，人工那份摘要被直接删掉。另一条经验是门禁脚本的错误信息要写给 Agent 看，返回状态必须区分"违规"和"环境错误"，否则一个环境问题会被 Agent 当成业务事故反复修改本来正确的计划。

3.4 善用Qoder Cloud Agents的Multi-Agent优化复杂任务执行成本

第一版把所有技能挂在同一个 Template 上，由单个 Agent 承担所有任务。结果可预期：用户先问复购率、接着上传表格回填、然后又要建召回流程，三段任务的规则、工具返回和中间态全堆在同一个上下文里，到第四十轮左右开始"跨域串规则"，模型把一个领域的字段命名用到另一个领域的参数上。本质不是模型不够强，是所有任务共用一份上下文预算。

第二版改用 QCA 的 Multi-Agent 编排：Coordinator 用 SOTA 模型，负责对话、理解意图、拆分任务、汇总结果；三个执行子 Agent 换成低成本模型（Qwen3.8-Flash 这一档）。QCA 的关键设计是，Session 内所有线程共享同一个环境和文件系统，但每个 Thread 的对话历史彼此独立。文档里把后者当成限制来写，对慧博却正是最需要的特性：上下文隔离即领域隔离，长上下文不再污染主 Agent，文件系统则成了跨线程交接的黑板。

通过使用Multi-Agent机制，让原本使用SOTA模型才能稳定执行的复杂任务可以由高性价比模型承担，显著优化了任务执行成本。

效果与阶段性成果

小慧Claw 依托Qoder Cloud Agents实现的从Prompt到Harness的范式切换带来了可量化的业务收益，运营数据任务从"小时级排期"变为"分钟级自助"，人从执行者回归决策者。