在《Data Agent 落地进行时》第 4 期《从一个业务场景开始，让 Data Agent 持续创造价值》中，我们介绍了怎样让一项分析进入日常工作：会前生成报告，会中回应追问，会后持续跟踪。一个经过验证的场景，开始承担业务团队反复需要完成的工作。
企业采购产品，是希望业务人员在需要分析时能够用起来。数据接入、语义建设和查询能力，最终都要落实到具体工作中：用户能够提出问题，获得有依据的结果，并继续完成后面的分析。
Data Agent 的落地，需要围绕业务问题组织应用。
01 应用的起点，是用户要完成什么工作
Data Agent 上线以后，可以支持多少张表、识别多少个指标，能够说明它具备哪些基础能力。但业务人员首先关心的是：我的这项工作，它能帮我做什么？
区域负责人需要准备经营复盘；销售主管需要找到进度落后的团队；财务人员需要查看到期未收款项。这些工作各有明确的使用者、关注对象和结果要求。
模型设计应当从这些要求出发。谁在什么情况下使用，通常从哪个问题开始，拿到结果后还会看什么，最后需要形成怎样的材料，都应该能够讲清楚。
以经营复盘为例，用户可能从销售达成情况开始，但达成率只是分析的起点。商品结构发生变化，可能需要查看相关商品的可用库存；客户销售增加，可能需要看对应回款。Data Agent 应用应该围绕这项工作的需要，提供能够继续使用的分析能力。
这会影响实施时的选择。企业可以先把复盘需要的对象、数据和常见分析准备好，让这项工作完整地运行起来。更多数据和功能，再根据实际使用逐步补充。
第3期，我们提到要从一个业务场景建立语义闭环，到了应用阶段，这条闭环的决定权就要交到具体使用者手里，帮助他完成自己的工作。
02 把业务问题转成产品能够承接的分析任务
业务人员提出的问题，通常不会直接对应一条查询。
“本月经营情况怎么样”，可能包含目标进度、变化来源和重点异常；“这次增长还需要关注什么”，则需要先看增长集中在哪里，再决定是否补充其他信息。
Data Agent 需要能够把这样的表达逐步转成明确的分析任务：确认对象和期间，选择适用指标，安排必要的比较，再根据结果继续查看明细。范围过大或者含义不清时，产品可以通过少量澄清帮助用户确定问题。
这里既需要模型理解用户表达，也需要调用企业已经确认的数据关系和计算规则。用户说“增长”，应采用哪个可比期间；用户说“负责的店铺”，应使用哪段时间的归属关系，都需要有依据。
当管理者从达成率继续问增长来源时，产品可以沿用原来的区域和销售口径，比较相关商品的变化。如果发现增量集中在新品和清仓商品，就可以进一步帮助用户查看相应的价格、供货或回款情况。
这个例子说明，应用需要承接的是一段连续的分析过程。一次提问得到结果之后，业务人员还能沿着已经明确的对象继续工作。
03 跨部门的数据，需要围绕问题联系起来
很多企业工作天然会涉及多个部门。用户的问题，也不会始终停留在某一套报表的范围内。Data Agent 要支持这类应用，需要让相关数据能够在同一个业务问题下被正确使用。
例如，销售记录里的商品与库存记录里的商品需要能够对应，客户销售与应收之间需要有明确关系。只有这些基础准备好，产品才能在用户追问时取得有关信息，并解释它与前面结果的联系。
不同数据仍有各自的含义。销售看一段期间的发生额，库存看某个时点的可用数量，回款还要结合约定到期日和核销情况。产品应当说明采用的范围与时间关系，让用户理解这些信息可以支持什么判断。
落地时，可以围绕目标工作逐步补齐这些关系。先支持从销售到商品的分析，再根据使用需要接入库存或回款。每扩展一部分，都确认相关对象、统计规则和权限，并用真实问题核对结果。
这样，新增数据会进入明确的应用路径。业务人员需要了解供货情况时，产品知道该查哪些信息；需要了解回款时，也能区分正常账期和已经逾期的款项。
对尚未接入或无法对应的信息，产品应说明具体缺少什么，方便相关人员补充。企业由此知道下一步需要完善哪部分基础，应用也能在已有条件下继续发挥作用。
04 让业务人员能够独立推进常见分析
应用是否好用，需要看它交到业务人员手里以后怎样运行。
演示时，熟悉数据的人知道怎样提问，也知道哪些条件必须补充。实际使用者往往只有一个工作问题，不会先研究表结构和字段关系。
产品需要把已经准备好的能力，组织成业务人员容易理解的使用方式。可以提供面向岗位的分析入口、经过验证的常用问题，以及能够继续调整的报告模板。用户进入应用时，知道它适合做什么，也能理解当前分析采用了什么范围。
在继续追问时，产品应保留已经确认的条件。仍在看本区域、同一批商品，用户就无需反复交代；切换了期间或计算口径，结果中应让变化可见。存在同名人员、多个客户主体时，则帮助用户选定对象。
这些要求直接影响业务人员能否独立使用。用户每次都需要实施人员解释怎样问，或者数据人员在后台修改查询，应用就还需要继续完善。
当然，独立使用也有适用范围。常见分析应当尽量由用户自行完成；新的业务定义、数据关系和特殊规则，仍由相应人员确认。产品需要把这两类工作衔接好，让已经解决的问题可以持续使用，让新增要求有明确的处理方式。
05 分析结果，要能够用于后续工作
业务人员得到结果以后，还需要知道它怎样帮助自己推进工作。
一份可用的分析，应当让用户看清主要变化、查看相关依据，并知道哪些内容还需要核查。需要交给同事讨论时，可以保存和分享；需要持续观察时，可以把已经确认的分析留到下一次使用。
例如，管理者从销售达成情况继续了解到部分新品供货不足，产品可以把相关商品、门店、库存时点和预计到货信息组织在一起，形成便于供应链核查的材料。涉及回款时，则保留对应客户、应收范围与到期情况，方便销售和财务继续讨论。
这里的价值在于用户从发现问题到获得可用依据之间，少了反复转述、取数和整理的工作。Data Agent 可以辅助比较和解释，提出需要继续确认的事项；业务人员结合实际情况，决定怎样处理。
如果后续需要接入任务或业务系统，再根据具体工作明确操作权限、确认环节与处理责任。应用可以随着系统集成逐步延伸，先把当前能够支持的工作稳定做好。
在设计亿问 Data Agent 时，我们关注的也是这个过程：让数据理解、查询、连续分析和结果交付共同服务一项业务工作，帮助用户把问题继续往下推进。
06 落地效果，要放到真实使用中检验
围绕业务问题组织应用以后，企业就有了更具体的检验方式。
可以请实际使用者从自己的问题开始，独立完成几次常见分析。看他能否找到适合的入口，理解返回的结果，继续提出追问，并把得到的信息用于会议、核查或后续跟踪。
使用中遇到的阻碍，也能够成为明确的改进项：
- 经常选错对象，就完善识别与澄清；
- 总要重述范围，就改进上下文保留；
- 结果准确却难以使用，就调整呈现和交付方式；
- 一到某类追问就中断，就检查所需数据和业务关系是否已经准备好。
这样的检验，会把产品能力与落地工作联系起来。业务人员提出使用要求，数据人员确认定义和关系，实施人员把共同确认的内容配置到应用中，再用实际工作验证。
当用户能够借助 Data Agent 完成一类分析工作，产品就有了清晰的应用位置。围绕这项工作确认的定义、关系与分析方法，也会成为后续扩展的基础。
这个过程中，企业也会留下经过验证的业务定义、数据关系和分析方法。这些积累，应该继续帮助更多团队使用数据，让下一项应用减少重复沟通和重复建设。
第6期，也是本系列的收官篇，将聚焦业务本体：怎样让这些经过验证的业务知识成为多个团队可以共同维护、供不同 AI 应用调用的基础。这关系到企业拓展下一项应用时，能在多大程度上沿用已有积累。