最近整个上半年Agent（或者说Agentic）模式的出现，导致我们整个大团队的工作方向发生了调整。领导层和中心部门的管理层，对AI这块的发展方向有了一些新的想法。去年9月份开始做到现在的AI应用，目前也有了一点转向的味道。
过去大半年投入了很多人力做这块内容，所以我在想，可能需要做一个阶段性的项目总结，算是给过去这段时间的投入做一个了结。我想梳理一下这个项目是如何从无到有、从0到1做到现在这个样子的，以及它是如何获得所谓的"成功"的。
有时候成功并不是因为你做得多好，而可能只是因为你做得比别人更好。好与不好很多时候是对比出来的，至于你本身是否真的完美，其实并不是最必要的。
两种模式：从工作流到Agent
回顾过去大半年我们所做的AI应用，之所以能获得老板的高度认可，而其他项目效果平平，核心在于我们及时完成了从"工作流模式"向"Agent模式"的范式转变。
整个AI应用的迭代始于去年3月。当时我们基于Dify这种集中式AI工作流平台，在内部开发了一个本地化平台AI Flow。从3月到9月，大多数应用都是基于AI Flow构建的。
第一阶段：AI工作流模式（3月-9月）
核心逻辑： AI在其中仅扮演工作流中的某个环节。开发模式本质上还是传统的，只是在原有流程的某个节点嵌入了AI能力。
落地成果： 我们开发了许多基于工作流的应用，比如DataMenus取数工具，以及各类查询游戏配置、通识信息和游戏数据的内部助手。
局限性： 这类应用停留在固定工作流中循环迭代，需要我们手动构建记忆逻辑（处理历史会话、提炼记忆、调整Prompt）。虽然解决了当时的问题，但随着模型发展，缺陷日益明显：灵活性极小，无法发挥模型的主观能动性。即使模型升级了数代，由于工作流中其他代码节点一成不变，整体能力也无法实现跨越式升级。
第二阶段：Agent模式（Agentic应用）
核心逻辑： 将任务整体交给模型，由模型自主决定执行路径。
我们的角色： 不再定义死流程，而是为模型配置工具、背景上下文、数据口径及指标定义。把已知信息全部交给模型，由它进行判断和决策。
竞争优势： 这相对于传统的AI Flow是一种降维打击。随着模型本身的迭代，Agent处理复杂任务的能力会自发增强。
总结来说，AI工作流模式目前正逐渐被大模型的发展所抛弃，仅适用于那些完全固定、无需灵活调度的极垂类场景。而Agent模式几乎可以覆盖我们所有的工作场景，这正是我们能够脱颖而出的关键。
从去年9月中旬到现在，我们基本上全身心投入到了这个Agent式的大盘数据分析问答应用中。目前绝大部分核心数据源已经接入，后续还会根据场景需求不断扩充。整体的开发模式和迭代方向已经确定，包括未来7、8月份的规划也都定好了。
我们为什么能做成这件事
作为试点业务，我们结合周边兄弟团队的紧密合作，最终达成目标，我觉得核心原因有以下几点：
1. 摸清了实现边界
我基本摸清了完成这件事可能涉及的各种边界情况。我知道模型能做到什么，不能做什么。
2. 痛定思痛的架构转型
之前基于AI Flow我也做过一个类似的应用，但后来发现它的局限性非常大，根本无法自主迭代更新，维护过程非常痛苦，完全吃不到模型升级带来的技术红利。看到市面上有很多类似的Agent模式应用，我意识到我们缺的正是这种Agent式的数据服务能力。
3. 紧跟行业趋势，抓住试点机会
后来老板发起了这个项目，其实也参考了谷歌NotebookLM的模式。当时NotebookLM横空出世，行业内对这种"通过模型集中式消费、再通过AI分析输出内容"的模式非常认可，国内也有很多人在学习。我们内部发起项目后，选择大盘作为试点业务，抓住了这个机会，做出的效果也符合老板预期。
具体做对了什么
1. 摸清模型边界，扬长避短
我们摸清了模型的边界和能力范围，给模型设定了很多限制，尽量让它在规定范围内思考。
2. 简化模型的理解负担
相关的数据、资产、指标、定义等，我们尽量让模型不需要深度理解。提前设置好所有内容，对每个存在不同语义、容易混淆的点都做了清楚描述，不让模型有猜测空间。因为猜测会增加模型的思考循环，耗时更久，出错概率也更大。我们统一了所有指标定义——无论是命名、描述还是计算逻辑，都在库表定义层就做好了严格的资产定义限制。这就是我们当时提出的"面向AI Ready的数据资产"。
3. 借鉴Skills模式
当时Skills这套逻辑还没有大规模兴起，平台也未能完全支持标准化的Skills方案。所以我们借鉴了Skills模式，我作为发起者和创建者，在大盘中按照Skills模式创建了九类场景。每个场景我都参考Skills模式，指定了场景下的解决方案。模型进入应用时，会读取场景并进行匹配，如果匹配就按照该场景的步骤去解决用户问题。通过这种方式，基本上能达到90%以上的Skills功能效果。这也是大盘很多问题回答得相对较好、并得到老板认可的原因。
4. 快速迭代优化
我们面向的对象主要是公司或BG的中高层。他们使用频率不高，所以只要有一两次使用，我们就会非常关注，了解他们关心什么数据、如何提问，并针对他们的问题进行定向优化：
- 对于简单问题，设置默认值来适配极简情况下的问答。
- 如果问到暂时不支持的数据，一方面增加兜底方案并给出提示，另一方面高效迭代，在下一个版本引入新的数据源。
这样就能保证用户第一次使用时，即使发现没有数据可能有些失望，但第二次再来时，同样的问题就能得到解答。因为无法对高层进行调研来了解他们的使用习惯和需求场景，所以我们只能被动等待他们第一次触发，然后基于他们的问答情况进行二次快速迭代优化。
5. 个人投入与团队协作
我个人投入了非常多的精力，几乎是全身心投入。包括整个流程的打通，以及与Agent团队的协调。我主要负责应用服务层，Agent的实现由模型团队负责。我们之间合作非常紧密，有问题就立即拉他们解决。如果涉及到提示词调整，我们会及时判断应该在应用层调整，还是在系统层面进行整体调整，并做定向优化。
测试与评估体系
在这个过程中，还包括测试集的构建。我们基于专题人工构建了大约四五十个命题，随后由开发团队针对我提的问题，进行定时、例行化的问答刷新。
模型开发团队每天通过滚动测试来检测模型的回答效果，并针对性地构建了一套模型评估体系，对每个问答输出的内容进行打分。打分的维度涵盖了：
- 回答的样式与组织形式
- 回答的丰富度
- 语义理解的偏差情况
- 数据准确率的协助判断
- 回答内容是否存在前后矛盾或数据异常
目前，我们基本上是通过旁路第三方模型来对问答效果进行评测，并且每天都会跟进监控。
整个项目靠着一个十多人的团队紧密配合、高效运转，才保证了服务的稳定与准确。
踩过的坑：幻觉与数值问题
其实在整个建设过程中，我们持续遇到了非常多问题。当时困扰我们最大的一个问题就是模型的"幻觉"，或者说模型对于数据加减、累计等处理的能力。
当时出现较多的问题主要有两类：
1. 数字单位问题： 很多时候会出现单位偏差，比如把1万搞成10万或100万，单位莫名其妙地缩放；或者最后累加结果本应是70亿，却变成了7亿。
2. 数值大小比较问题： 比如模型会觉得7.3比7.9大。这种数值大小比较的错误出现了很多，困扰了我们很久。
针对这些问题，我们也尝试了很多办法。加了很多提示词层，也做了很多设置，但效果并不理想。我们甚至想过额外做一个算子工具，专门针对数值大小做额外的逻辑判断，但整体尝试下来效果也不太好。
最后是怎么解决的呢？其实前面的版本一直都没有彻底解决，最终是靠模型本身的升级解决的。
最难的不是搭框架，而是填那30分的差距
模型最初建设完以后，在实际运行过程中，它往往不会完全按照你设想的步骤来执行。这时候就需要一步步排查，看它为什么在某个环节没有按预期走，哪里描述得不对。通过反问模型为什么没有按照既定路径执行，再根据它的反馈去调整Prompt。
基本上，很多问题都是通过调整Prompt来解决的。无论是Agent后台的系统级Prompt，还是应用层的Prompt，都需要不断磨合，摸清楚它容易出问题的点和边界在哪里，然后再把这些逻辑固化下来。
所以我觉得建设这个系统本身可能不是最难的。最难的是在搭完框架以后，如何不断地让它运作得更好、更稳定、更准确。
- 搭建起一个系统，可能只是完成了一个60分的产品。
- 但如果你要把它交给业务方，特别是公司BG的中高层去使用，并且保证不出大问题，那就必须达到90分的水平。
- 这中间30分的差距，需要通过大量循环的迭代、测试和调优来弥补。核心的时间精力其实都花费在这里。
前段时间隔壁团队想做一个类似的业务产品，还提出想让我来负责。我当时就表示，如果只是搭个框架，我随时都可以配合。因为只要花个三两天，把数据、专题、提示词、工具、背景、业务知识和数据源全部整合在一起，基本就能达到60分的水平。
但真正要达到交付给业务方的90分标准，中间这30分的提升可能要占据你80%甚至90%的精力。
开发这样一个东西从来不是难点，难的是如何把它做好，真正做到能面向业务使用并达到交付级别。
模型的迭代才是终极答案
从项目启动开始，我们的模型开发团队对比了市面上几个主流的开源模型，最后选定的是智谱的GLM。最开始用的是GLM-4.5，后来4.5和4.6版本都出现过一些问题。直到后来的4.7、5.0版本，随着模型的迭代，这些数值问题和幻觉问题就大幅降低了。在现在的版本下，我们已经基本碰不到太多的数值比较或数字幻觉问题了。
这也回到了我前面提到的：模型的迭代发展应该作用于你的业务迭代，并产生正向循环。这才是我们构建Agent服务的一个核心优化点——你必须能从模型的升级迭代中获取正向收益，这样你开发的服务才有自动进化的价值。否则，如果只是一个死板的Workflow，它的升级潜力就会非常有限。