当 Agent 从“尝鲜工具”走向真实业务场景，企业真正需要的，已经不只是一个会执行任务的助手，而是一套能够持续积累上下文、沉淀业务知识、复用分析经验的智能能力。
如今，越来越多企业开始尝试让 Agent 做分析、写报告、查数据、跑流程。但真正落地之后，很多团队会发现：
Agent 会执行任务，却很难持续进化。
它可以完成一次分析，却留不住经验；
它可以调用一次工具，却不一定理解业务；
它可以回答一个问题，却难以承接下一次追问。
在 DataFun 与 OceanBase 联合发起的直播活动中，观远数据技术研发总监王贺锋围绕个人 Agent 与企业 Agent 两条路径，分享了观远数据在 Agent 上下文实践中的探索：如何让企业数据资产转化为 Agent 可理解、可调用、可进化的上下文底座，推动 Agent 从数据查询走向业务洞察。
01 Agent 要自进化 先要有“上下文”
直播中，王贺锋首先提到一个重要观察：过去一年，Coding Agent 之所以发展很快，一个关键原因在于软件工程领域天然具备完整上下文，源代码、注释、文档、规范、Issue、PR、测试和 CI/CD，让 Agent 可以理解项目结构、参考历史经验、验证修改结果。
但企业业务系统不一样。企业的数据、指标、报表、流程、组织经验，往往分散在不同系统、不同文档和不同人的经验里。业务人员问一句：“这个月华东区销售额为什么下降？”这并不是一个简单的数据查询问题。它背后可能涉及客流、转化率、客单价、区域、门店、品类、库存、促销、供应商等多个维度，也需要连续追问和层层诊断。
如果 Agent 只是检索资料、拼接信息，最后往往只能给出一段“看起来合理”的总结，却无法真正定位问题根因。因此，企业 Agent 要解决的关键问题，不是让 Agent 多接几个工具，而是要为 Agent 构建一个能够理解业务、支撑推理、沉淀经验的上下文底座。
02 从个人 Agent 到企业 Agent 业务现场需要两类进化路径
当前，企业里的 Agent 正在分化出两种形态。个人 Agent正在推动 ToB 产品面向 Agent 转型；企业 Agent 则更考验上下文体系的建设能力。
第一类是个人 Agent，从连接系统，到沉淀可复用场景
它面向个人或小团队，常见场景包括数据探索、分析助手、临时报告生成等。它更像是在放大个人的分析能力，让一个人能够更快完成过去需要数据分析师、BI 工程师或业务人员共同完成的工作。
过去，解决一个业务问题通常依赖人的经验链路：先理解问题，再寻找分析路径，再进入 BI 系统找数据、做看板、整理结论。这个过程高度依赖人的分析思维和实现效率，能覆盖的分析路径有限，最终输出也常常停留在相对固定的报表或看板里。
当 Agent 开始进入业务系统后，这条链路正在发生变化。Agent 可以连接平台、调用工具、尝试多个分析角度，并将结果组织成更贴近业务视角的报告。观远数据将个人 Agent 的落地路径拆解为三层：
第一层：GuanCLI，让 Agent 能连接并操作 BI
GuanCLI 提供 Agent 连接并操作 BI 的基础能力。通过这一层，Agent 不再只是停留在对话窗口里，而是可以真正进入企业数据系统，完成看数据、做 ETL、做分析、生成报告等动作。
这相当于为 Agent 打开了企业数据产品的入口，让它知道如何调用数据资产、如何操作业务系统、如何把分析结果输出为业务可以理解的内容。
第二层：Skill / Doc，让 Agent 稳定掌握产品知识与业务知识
仅有工具还不够。Agent 还需要知道工具怎么用、指标怎么算、业务规则是什么。因此，第二层是 Skill / Doc 的沉淀。这里既包括产品功能知识，例如如何创建仪表板、查询数据、导出数据；也包括业务专业知识，例如不同行业的指标口径、ETL 宽表范式、高频分析方法，以及个人偏好和组织经验。
这一层的价值在于，让 Agent 不只是“能调用工具”，而是能够按照企业自己的业务规则稳定工作。
第三层：超级应用，把一次好的探索变成可复用场景
如果一次 Agent 探索只停留在对话里，价值是有限的。只有把它封装成业务人员可以反复使用的应用，才能实现规模化复用。
直播中提到的餐饮会员召回就是一个典型例子：Agent 可以帮助运营人员筛选特定阶段的人群，展示会员信息、召回价值和优先级；进一步，还可以生成触达话术，并把发券、触达等动作接入业务流程。
这里的重点不是让 Agent 替代人做运营决策，而是把“发现问题、生成建议、发起动作”串成一个可复用的业务场景。因此，个人 Agent 的价值，不只是提升一次分析效率，而是把个人探索沉淀为组织可以复用的能力。
第二类是企业 Agent，ChatBI让Agent在反馈中持续理解数据
企业Agent面向大团队、部门或经营场景，目标不是只回答一个问题，而是参与经营分析和决策辅助。它需要把组织长期沉淀的业务知识、指标口径、分析方法和经营经验纳入分析过程。
企业级 Agent 的第一类典型场景，是问数。观远ChatBI 主要解决的就是这个问题：让业务人员可以通过自然语言获取数据，降低理解和使用数据的成本。问数要真正准确，难点并不只在自然语言理解，而在 Agent 是否理解企业自己的业务口径。ChatBI 的上下文体系有多层，包括通用知识、业务知识、个性化记忆和样例集。一个典型问题是：当 Agent 因缺少上下文而回答错误时，系统能不能从这次错误中学习？
例如，用户提问：“华东区表现最好的商品是什么？”如果 Agent 不理解“表现最好”的具体定义，就可能默认返回销量前十。但在企业语境下，“表现最好”也许对应销量前三，也可能要结合毛利、增长率、库存周转等指标共同判断。
针对这类问题，我们的思路是把用户反馈、Trace 定位、人工修正和知识沉淀连接起来。当用户标记错误回答后，维护人员可以定位问题并修正结果；系统再结合问题、错误答案和修正答案，提取可复用的业务知识或偏好。经过确认后，这些知识会进入上下文体系，后续类似问题就能得到更稳定、更准确的回答。
这里的关键不是“模型自动变聪明”，而是把一次错误回答转化成可管理、可验证、可复用的上下文更新。同时，ChatBI 还通过测试集和验证机制，持续检查优化是否真正有效，避免一次修正带来新的问题。ChatBI 的目标可以概括为一句话：让 Agent 更稳定地理解数据。
03 DecideX：让 Agent 进一步理解业务场景
如果说 ChatBI 解决的是问数，那么 DecideX 探索的是更复杂的问题：Agent 如何参与企业经营分析和决策辅助？
还是回到那个问题：“华东区这个月销售额为什么下降？”
如果只依赖 RAG 或文本检索，Agent 可能会从经营分析报告、会议纪要、异常说明中总结出几个原因，例如促销减弱、客流下降、库存不足等。这个回答可能有用，但更像资料摘要，并不等于真正的业务诊断。
真正的业务分析人员会继续追问：销售额下降到底是客流下降、转化率下降，还是客单价下降？是所有门店都下降，还是某类门店下降？是品类结构问题，还是库存、价格、促销或会员触达出了问题？有没有具体事件导致了这次波动？
这些问题需要的不是更多文档，而是对业务世界的结构化理解。因此，DecideX 更强调通过本体论思想构建可推理的业务知识网络。它把业务对象、业务关系、状态事件、业务过程、分析诊断路径和行动建议组织起来，让 Agent 不只是“找到资料”，而是能够沿着业务关系形成诊断路径。
在销售额下降的诊断链路中，Agent 可以先查看销售额变化，再沿着指标关系判断关键因素，继续下钻到区域、门店、品类、库存和供应商事件，最终形成一条可解释、可追溯的分析路径。这时，Agent 输出的就不再只是资料摘要，而是更接近业务分析人员的思考过程：先拆指标，再定位对象，再验证事件，最后形成建议。
04 数据资产成为上下文底座 Agent 才能持续进化
个人 Agent 和企业 Agent 的构建方法不同。个人 Agent 更像是从 GuanCLI 到 Skill/Doc，再到 App，把个人探索沉淀为可复用能力。企业 Agent 更依赖业务知识网络和组织级上下文，让企业的业务知识持续沉淀、更新和复用。
但两条路径的本质是相通的：它们都在把企业已有的数据资产、业务知识、分析经验和决策逻辑，转化为 Agent 可以理解、调用和持续进化的上下文底座。
这也是观远在 Agent 实践中的核心思路：
让企业的数据资产不只服务于人，也能被 Agent 理解和利用；
让每一次问数、每一次修正、每一次分析、每一次业务判断，都有机会沉淀为新的上下文；最终放大企业数据被分析、被洞察、被转化为行动的机会， Agent 才真正从“会执行”走向“会成长”。
05 把真实业务问题 变成一次 AI 实战探索
Agent 的进化，不只发生在模型能力里，也发生在一次次真实业务问题的解决过程中。如果你也在思考：日报周报、经营复盘、异常归因、报告生成、看板解释等工作，能不能让 Agent 重新跑一遍，欢迎关注观远「决策智能 AI 创新赛」。
这不是一场单纯比技术、比代码的比赛。我们更希望大家带着一个真实业务问题，借助 GuanCLI、超级应用、官方 Skill 等观远工具包，完成一次可验证的 AI 实战探索。
6 月 11 日 14:00-15:00，观远将举办 AI 创新赛介绍与答疑，欢迎报名参与，带一个真实问题来，把它变成你的 AI 实战案例。
想进一步体验 AI+BI 在业务分析中的落地效果，可以从这里开始。
