从洞察到行动：Agentic Engine 的闭环架构与工程实践

假设某电商 App 最近一周 ROI 下降了 10%。业务团队要回答三个问题：为什么下降，确定原因后多久能够行动，以及下次遇到类似情况能否沿用这次的处理方法。10% 是用于说明问题的场景设定，并非已经发生的客户案例，也没有预设异常原因或改善结果。

这些工作分散在分析、运营和研发岗位，交接时仍要解释指标、寻找历史记录。Agentic Engine 将分析与运营工具交给 Agent 调用，并在企业工作环境中保存处理过程。

把分散的数据接起来，让分析结果进入运营

ROI 排查首先面临的是数据来源分散。广告成本在投放平台，用户行为在 App，订单在业务数据库，站外评价又分布在社区。为一次分析迁移全部数据，成本高，也不适合企业现有数仓。Agentic Engine 采用开放融合的数据底座：接入与加工、开放引擎和多仓融合支撑行为分析、BI 看板、用户运营与 A/B 实验，已有业务系统及计算存储设施仍可以继续使用。权限审计、资产治理、观测评测和用量成本管理贯穿各层。

图1｜开放融合的数据底座：复用企业现有数仓与基础设施，支撑分析、运营和 Agent 应用

数据接入分为客户端、服务端、数据库、广告与归因、社区五类。客户端支持 50 多个 SDK，覆盖 App、游戏、PC 和小程序，并通过自动采集减少逐项埋点工作；采集范围既包括常见事件，也延伸到页面展示、控件点击。服务端通过 Java、Go 等语言的 SDK 接入。数据库则有三条路径：直接查询现有数据，通过跨源映射保留原有数仓，或者选取高价值数据加工后再导入。接入方式由现有设施和成本决定。广告与归因通过 Pull / Push API 对接，抖音、小红书等社区信息通过官方 API 接入，让应用外部的投放变化和用户讨论也能成为排查线索。

图2｜全域数据采集：客户端、服务端、数据库、广告与归因、社区五类接入方式

数据能查到，还需要在不同引擎与存储之间高效执行。统一查询入口根据任务场景进行路由：在这套架构中，Trino 侧重跨源联合查询，StarRocks 侧重分析查询加速，这只是应用分工，并非两种引擎的能力边界。企业集中看数时，计算资源支持高峰扩容、低峰回收和项目隔离；较常访问的数据保存在 HDFS，历史冷数据可以转向对象存储，业务侧仍通过统一入口查询。兼顾高峰计算与长期存储成本。

图3｜数据计算与存储：开放引擎、弹性计算与分层存储

分析环节把 ROI 变化继续拆到渠道、行为和转化路径。平台提供事件、留存、漏斗、会话、归因等 12 个分析模型，并将用户行为和 Agent 行为结合起来观察。因为推荐、客服等环节可能已经由 Agent 参与，用户最终没有购买，原因也可能与此前的一次商品推荐或客服回复有关。性能分析同样需要关联行为轨迹：崩溃、卡顿和内存异常可以说明出了什么故障，用户在故障前执行了哪些操作，才有助于进一步定位。广告归因与社区讨论补充背景，但异常之间有相关性，不等于已经查清因果。

图4｜全域数据洞察：应用内行为分析与广告投放归因

当事件列表只记录了“退出页面”，会话回放可以补全退出前的浏览、滚动、表单操作、视频播放及跳转，帮助还原具体使用情境。会话回放也要控制采集边界：手机号、证件号等敏感内容不应完整采集，表单内容按需遮盖，相关数据进行加密或脱敏。

图5｜会话回放：以用户视角还原操作过程

排查形成待验证的判断后，需要运营工具执行。团队可以按属性、行为、标签和分群选择对象，再配置定时或事件触发任务；部分触发条件在客户端判断，减少等待服务端处理的时间。较复杂的运营过程通过流程画布组织，A/B 实验比较不同干预方案，配置中心支持 Webhook 下发或 SDK 拉取参数。执行结果继续回到分析侧，下一步究竟应扩大、调整还是停止策略，要由反馈数据决定。

图6｜运营能力：人群圈选、触发式运营任务与流程画布

一旦分析与运营共用数据，权限控制就不能只停留在登录入口。平台支持内网私有部署、按需采集、全链路加密和身份匿名，并把角色权限细化到渠道等数据范围。相同岗位的员工不一定能查看同一批业务数据；敏感字段按授权脱敏，用户与 Agent 的查询、执行和敏感操作都保留审计记录。

图7｜安全合规：私有部署、企业内网与数据保护

Agent 调用现有工具，关键是读懂业务口径

数据分析与运营工具已经连通，实际工作仍可能卡在跨角色交接上：研发负责埋点，分析师查指标，运营人员配置任务，各方使用不同工具，也习惯用自己的业务术语。要让 Agent 承担其中的衔接工作，就得提供稳定的工具入口和能够核对的业务定义。

图8｜章节过渡页：Agent 友好

在工具侧，CLI / MCP 负责开放能力，Skill 保存已积累的操作方法，Workflow 固定有明确步骤的流程，语义层说明指标、事件和业务对象的含义。比如 ROI 计算、A/B 实验创建等确定性操作，更适合通过编排好的程序化流程执行；Agent 负责理解需求、选择能力、组织步骤，减少每次临时生成操作方式带来的波动。重复操作由此有了一致的执行路径。

图9｜Agent 友好：Agent 客户端、能力服务与 AE 产品能力三层结构

AE-CLI 进一步把数据接入、治理、洞察与运营能力组织到统一入口。以前不同角色需要在 SDK、数据开发工具和运营后台之间切换，现在 Agent 可以按任务调用相应能力。统一入口也不能简单堆积命令，否则工具太多反而增加选择负担；因此常用能力通过分层命令访问，低频能力按需发现，再进行组合编排。埋点设计、接入验收、指标分析、人群圈选、策略执行和效果评估由此可以在一个任务里衔接，实际操作仍由原有系统完成。

图10｜AE-CLI：面向 Agent 的统一能力入口

但工具调用成功，不代表分析口径正确。一个企业可能有多种 DAU 定义，不同团队的看板也可能长期缺乏维护。语义层整合权威资产、个人语义和业务知识，依据资产热度与关联影响推荐指标、事件及看板，识别定义冲突；人与 Agent 协作形成的约定，可以结合文档、代码整理到项目语义中。如此一来，Agent 查询“活跃用户”时不必只凭名称猜测该用哪套指标。

更麻烦的是，业务定义会变化。事件与指标更新可能使旧知识失效。因此项目语义需要持续发现和更新，存疑的定义进入人工审核，确认后再写入共享知识与项目 Wiki。语义层的质量取决于这些维护环节，而非一次性录入了多少资料。

图11｜语义层：整合权威资产、个人语义与业务知识

企业级 Agent 平台，解决运行、协作和治理问题

Agent 可以理解任务、调用工具之后，企业还要决定它在哪里运行、不同项目怎样隔离，以及谁能看到或接手它留下的工作。ThinkingAI AgentOS 把运行环境、模型与能力、知识与记忆放在基础层，在上面支持系统 Agent、自定义 Agent、Agent Team 和共享空间，并连接企业现有办公入口。运行观测、安全审计、用量成本和价值评估则覆盖整个过程。

图12｜ThinkingAI AgentOS：让企业用好 Agent

运行环境采用一人一沙箱、沙箱内多工作空间的结构，既便于管理个人使用环境，也能隔离不同项目的配置与上下文。沙箱预置 Claude Code、OpenClaw、Hermes、AE-CLI、Lark-CLI、Python、Node 等工具，资源随任务需求调整；闲置时回收，需要时恢复，并利用预热减少启动等待。沙箱管理同时关系到成本和任务连续性。

图13｜运行环境：一人一沙箱、沙箱内多工作空间

模型由用户或 Agent 按需配置，平台也可以依据问题复杂度路由模型，避免所有任务都使用高成本配置。Skill 复用业务方法，MCP 连接工具，个人整理的 Skill 可以依照企业管理流程申请共享。知识库接入文件、飞书文档和代码仓库，借助 RAG 与 LLMWiki 按需检索，同时考虑检索效果、模型消耗和增量编译速度。对于 DAU 等涉及数值和口径的回答，还需要工程规则校验。空间记忆则整理会话中的背景、偏好与工作约定，经确认后保留在对应空间，供有权限的 Agent 在后续任务中继续使用。

图14｜模型与能力：匹配任务所需模型，沉淀业务方法，连接业务工具

图15｜知识与记忆：管理企业知识，保留工作上下文

当一个任务跨越市场、研发和财务，单个 Agent 的配置已经不够。系统 Agent 承接分析、运营和 A/B 实验等现成能力，自定义 Agent 可由团队配置模型、Skill 与 MCP，多个 Agent 通过 Agent Team 串行或并行协作。共享空间同步共同目标、任务进度和获准共享的结论，同时保留岗位间的数据权限，避免协作范围扩大后失去信息边界。

图16｜Agent 配置与协作：系统 Agent、自定义 Agent 与 Agent Team

员工仍可以从飞书、钉钉、企业微信以及 Slack、Discord、WhatsApp、Lark 等办公工具进入任务。A2A 协议支持外部 Agent 与企业 Agent 相互发起或承接工作，但每一次调用仍取决于工具配置与权限授权。不同入口的请求仍需统一追踪。

图17｜开放连接：融入办公入口，通过 A2A 实现跨平台 Agent 协作

因此，观测与治理是运行体系的一部分。会话和 Trace 用来定位工具、模型与 Skill 调用中的异常；安全审计检查敏感信息泄露和高风险操作，规则既可预置，也可按企业要求配置。费用管理按用户与 Agent 汇总 Token 用量和实际支出，价值评估则结合任务进展、完成情况、知识沉淀与 Skill 复用作内部等级判断。高、中、低等级可以辅助管理，但不能直接替代财务上的 ROI 核算。

图18｜观测与治理：运行管控与 ROI 评估

回到 ROI 异常，把一次处理变成团队方法

这套架构最终需要在实际任务中连起来。面对 ROI 异常，数据接入与分析能力负责取得线索，运营工具执行后续动作，Agent 根据业务语义组织调用，企业级平台保留权限、执行记录与协作内容。

仍以一周 ROI 下降 10% 的电商场景为例，团队先核对广告成本、用户行为和订单数据，再按渠道、转化路径和用户分群缩小排查范围。确认需要检验的假设后，通过圈选人群、配置运营任务或 A/B 实验执行处理方案，再根据反馈判断调整是否有效。Agent 在这里调用已有系统，语义层约束指标口径，平台记录处理步骤与协作内容。具体原因与处理成效，都要由业务数据验证。

图19｜案例回顾：某电商 App 一周 ROI 下降 10% 的异常处理闭环

业务问题解决以后，还需要分清哪些经验值得留下：已经核对的指标定义、可以复用的排查顺序、执行策略所需的条件，以及哪些尝试没有得到数据支持。这些内容进入项目知识和 Skill，也应随着业务变化接受修订。没有准确的数据口径、可靠的执行工具和明确的权限边界，Agent 即使能完成调用，也难以形成稳定的工作流程。

更有分量的变化，是一次异常处理结束后，其他人能够查到依据、接着执行，并能根据结果纠正原来的方法。问题仍然要靠数据回答，行动仍然要经过验证；但已经付出的分析和协作成本，可以转化成下一次工作的起点。

分享嘉宾

INTRODUCTION

王浩强

ThinkingAl 

Agent首席架构师

现任ThinkingAI Agent 首席架构师，专注企业级 AI Agent 的技术架构与落地应用，推动数据分析、多 Agent 协作与业务执行融合，让数据洞察转化为可衡量的业务价值。

往期推荐

小团队如何搞本体 Ontology 和语义层？

顺丰供应链Agent落地实践：供应链AI从工具走向全域智能操作系统

Data Agent 如何让取数更简单、更智能？

Harness Engineering 的语义底座：本体驱动的 Agent 可控执行

Palantir真正的护城河，终于看清了

本体图谱不是玄学：让 Agent 理解表关系与业务规则

智能体架构与实践：构建下一代推荐与搜索系统

企查查 MCP 实践：已有 API，如何进一步支持 AI 调用？

点个在看你最好看

SPRING HAS ARRIVED