朱清林 • Blog
今年7月份，我写了一篇《龙虾热度过去，我还在用它搭建基金会AI智能助手》，分享了自己基于OpenClaw，为基金会中心网搭建行业AI智能助手的过程。
当时的想法其实很简单。基金会中心网积累了大量行业数据，包括基金会基本信息、财务数据、公益项目、FTI透明指数等，但这些数据分散在不同的平台和业务系统中。对于普通用户来说，想要找到需要的信息，往往需要了解不同平台的查询方式。
我希望通过AI，把这些数据连接起来，让用户不需要熟悉复杂的查询界面，只需要像聊天一样提出问题，就能获得相关信息。
经过一段时间的开发，第一版智能助手终于上线了。虽然功能还比较基础，但已经能够查询基金会基本信息、部分行业统计数据，也能回答一些FTI相关问题。
对于我来说，这是一次很有意义的尝试。至少证明了一件事：利用现有的业务系统和数据接口，即使没有专门的AI研发团队，也有机会搭建一个真正面向用户的AI应用。
但系统上线，并不代表它已经足够好用。
一、AI能回答问题，但用户真的愿意等吗？
第一版上线后，我陆续观察和整理了一些用户的实际提问，也尝试用真实问题测试系统的表现。
很快，我就发现了一个比较明显的问题：慢。
有些简单的问题，用户需要等待十几秒；遇到复杂一些的查询，可能需要几十秒，甚至出现长时间等待后仍然没有得到有效结果的情况。
作为开发者，我知道这段时间里，Agent可能正在分析问题、选择工具、调用接口，再把返回的数据整理成回答。
但站在用户的角度，他并不关心后台发生了多少次调用，只会觉得自己提出了一个问题，却迟迟没有得到回复。
后来，我整理了第一版的139条历史有效问答记录，发现平均响应时间为28.7秒，中位数为21.4秒，其中有50条问答的耗时达到30秒，占比约36%。
有的问题回答甚至超过120秒。
这还只是能够匹配到最终回复的有效记录，并不能完整反映那些没有成功得到结果的请求。
除了速度，我还发现另一个问题。
用户并不会按照我们设计好的方式提问。
比如，有人会问：“各个项目开展地，科学技术议题的项目都有多少？”
这句话看起来并不复杂，但实际上缺少一个重要条件：查询哪个年度？
如果AI没有识别出这个问题，而是直接开始调用工具，就可能不断尝试不同的查询方式，最后花费很长时间，却仍然无法得到符合用户预期的结果。
类似的情况还有很多。有些问题需要关联多个数据维度，有些问题超出了现有接口的能力，还有些问题虽然能够回答，但Agent为了找到合适的工具，反复进行了不必要的尝试。
这些问题让我开始重新思考：是不是不能只关注AI能够连接多少工具，还需要重新设计它理解问题和执行任务的方式？
于是，我开始着手升级智能助手2.0。
二、同样的问题，从40多秒缩短到7秒
经过这次架构调整和业务接口升级，智能助手2.0的响应速度有了比较明显的改善。
10月20日，我选取了第一版中8个具有代表性的历史问题，使用2.0重新测试，覆盖基金会地区分布、机构信息、人员任职、财务和公益项目等场景。
其中7个问题返回了业务数据。对照这些问题的历史记录，1.0平均耗时43.9秒，而2.0本次测试平均耗时7.4秒，等待时间减少约83%。
几个具体案例更加直观。
例如，用户询问“江苏省的基金会名录”，第一版历史记录耗时81.2秒，2.0仅用了6.72秒，就返回了首批机构名单及总数等信息。
再比如，“介绍乐平公益基金会”，原来需要52.4秒，这次只用了9.65秒，就获取了基金会基本资料、治理信息和近三年的财务数据，并整理成回答。
“中国有多少家教育类基金会？”这个问题，也从39.7秒缩短到了5.06秒。
当然，这并不意味着2.0所有问题都快了五六倍。测试中也有个别问题比历史记录更慢，而且本次对照只是少量代表性问题，并非严格控制所有变量的性能实验。
但至少从这些实际查询来看，升级后的变化已经比较明显。
对用户来说，最直观的感受就是：不需要等待那么久了。
而我更关心的是，这些变化究竟是怎么发生的。
三、让Agent少走弯路，而不是一味依赖模型自己探索
回顾第一版的实现方式，我发现不少时间其实消耗在工具调用和问题理解的过程中。
当时，我通过OpenClaw连接各个业务平台的接口。Agent需要根据用户的问题选择合适的工具，有些调用还需要先生成Sandbox执行代码，再通过exec运行。
这种方式有一定灵活性，但也增加了执行步骤。
特别是遇到需要组合多个数据维度的问题时，Agent可能需要反复调用接口、检查结果，再决定下一步怎么做。
为了改善这些问题，我在2.0中重点调整了几个方面。
先理解用户的问题，必要时主动追问
以前，我总希望AI能够尽可能自主地完成任务，用户提出问题后，最好直接给出答案。
但实际使用让我意识到，有些问题本身就不够清晰。
如果缺少关键条件，AI越积极地执行，反而可能越容易走偏。
因此，2.0增加了更明确的用户意图识别和问题追问机制。
系统会尝试识别用户想查询的对象、地区、年度、指标等信息。如果缺少完成查询所必需的条件，就先向用户确认，而不是立即调用工具。
前面提到的科学技术议题项目统计，就是一个实际例子。
第一版历史记录中，这个问题耗时69.6秒。而2.0在测试时，没有直接进行统计，而是在5.37秒内向用户追问需要查询哪个年度。
虽然它还没有完成最终的数据查询，但至少没有在条件不明确的情况下盲目执行。
我认为这是一种更合理的处理方式。
有时候，AI少做一步无效操作，比多调用几个工具更有价值。
当然，追问也需要把握分寸。如果用户已经明确了查询条件，就没有必要反复确认，否则又会产生新的交互成本。
让工具调用更直接，也更可控
这次升级的另一个重点，是重新封装Agent使用的业务工具。
第一版主要依赖模型生成调用代码，再通过执行环境完成请求。2.0则调整为原生结构化业务工具，提前定义好工具用途、请求参数和返回结构。
这样，Agent不需要每次临时编写调用代码，而是可以根据识别出的用户需求，选择相应的业务工具。
我还对接口进行了整理和扩展，尽量让一个工具能够完成一类明确的业务查询。
例如，查询基金会综合信息时，可以根据需要一次获取基本资料、治理情况和相关财务信息，而不是让Agent分别寻找多个接口，再反复拼接结果。
对于一些统计问题，也可以直接调用汇总接口，而不必先取回大量机构名单，再让模型自行计算。
除此之外，我还增加了重复调用拦截、超时控制和错误处理，避免Agent在接口失败或结果不符合预期时不断重复尝试。
目前，2.0配置了23个业务工具，并接入了8类新增上游分析接口。这些工具并不是越多越好，关键在于每个工具的职责是否清楚，能否与用户的真实查询需求对应起来。
让AI能够理解连续的问题
用户与AI的交流通常不是一次性完成的。
例如，用户先问“上海有多少家基金会”，接着又问“其中哪些机构的捐赠收入比较高”。
第二个问题没有再次说明地区，但显然与前一个问题有关。
如果Agent每次都把问题当成全新的任务，就可能丢失已经确认的查询条件。
因此，2.0也强化了对上下文条件的继承，以及相关问题的关联处理，让后续查询尽量建立在前面已经明确的信息之上。
同时，系统推荐的后续问题也需要受到实际工具能力的约束，避免引导用户提出目前还无法支持的查询。
这些调整看起来并不是什么特别新颖的技术，但在实际应用中，却直接影响着AI能否稳定地完成任务。
这次我也调整了模型配置，从原来的豆包2.1 Pro切换到了豆包2.0 Mini。模型、工具调用方式、业务接口和提示规则的变化，都可能对响应速度产生影响。因此，我不能简单地把这次提速全部归功于某一个技术调整。
但整体思路是明确的：减少不必要的推理和工具试错，把更多确定性的业务规则交给程序和接口处理。
基金会中心网近几年一直在参与火山引擎公益平台，所有的云服务由火山引擎赞助，所以我们使用的都是豆包系列的大模型。
四、不只是回答更快，还能查询更丰富的公益行业数据
如果说架构调整主要解决的是AI如何更有效地执行任务，那么业务能力的扩展，则决定了它能够为用户提供多少实际价值。
基金会中心网长期积累了大量基金会行业数据，但过去这些数据主要通过不同的平台和页面向用户提供查询。
例如，用户想了解一家基金会的基本信息，可以进入基金会百科；想进一步分析财务情况、公益项目或者行业分布，则可能需要使用不同的数据查询功能。
2.0在保留原有基金会基础信息、人员和部分行业查询能力的基础上，进一步扩展了财务分析、项目分析以及多维度统计能力。
以财务数据为例，现在可以围绕年度、地区、收入指标等条件，查询基金会财务排名、汇总数据及多机构之间的比较情况。
比如，用户可以直接询问：
“2024年捐赠收入最高的五家基金会有哪些？”
系统会根据相应的财务指标调用分析接口，并整理返回结果。
在公益项目方面，也增加了项目议题、年度支出、开展地区等维度的查询能力。
例如，用户可以了解某一年度教育类项目的支出情况，或者查询特定地区与议题相关的公益项目。
对于研究者、公益从业者以及关注行业发展的公众来说，这些查询方式可以降低获取和理解行业数据的门槛。
不过，行业数据查询还有一个非常重要的问题，就是统计口径。
例如，基金会的“教育发展”业务领域，不等于所有开展教育项目的机构；捐赠收入也不能直接等同于总收入。不同年度、不同来源的数据，也不能未经说明就放在一起比较。
这些问题并不会因为使用了AI就自动消失。
相反，当AI能够更加灵活地组合查询条件时，我们更需要在接口和业务规则中明确数据的含义，避免模型给出看似合理、实际口径却不一致的答案。
这也是我在这次升级中越来越重视的一件事：AI可以降低查询门槛，但数据的准确性和业务口径仍然需要由底层系统来保障。
五、当AI开始知道“你是谁”，服务也开始变得不同
除了面向公众的行业数据查询，这次2.0还有一个我比较看重的变化：加入了用户身份识别，并尝试将智能助手与具体业务系统进一步结合。
过去，用户访问智能助手时，系统主要根据他提出的问题提供公开数据和知识问答服务。
但对于基金会工作人员来说，他们可能更关心自己所在机构的具体情况。
例如，基金会中心网每年开展的FTI透明指数观测工作，需要基金会工作人员关注本机构的观测进展、指标结果，以及尚需完善的信息披露材料。
以前，工作人员需要进入相应的业务平台，查看各项指标的情况。
而现在，我们尝试让这件事情通过自然语言完成。
例如，一位基金会工作人员可以直接询问：
“我们基金会今年有哪些FTI指标没有通过？”
智能助手首先需要确认当前用户的身份，以及账号是否已经与相应的基金会完成绑定。
在确认权限后，系统才能查询该机构的FTI2026相关数据，并根据接口返回的结果，说明哪些指标尚未通过、未通过的原因，以及对应的观测要求。
为了实现这一点，我将官网用户账号与机构身份验证机制进行了关联。工作人员需要通过慈善中国公示邮箱验证码等方式完成身份核验，服务端再根据已验证的绑定关系确定查询对象。
这意味着，用户不能仅仅告诉AI“我是某某基金会的工作人员”，就获得该机构的非公开业务数据。
目前，这部分已经完成了相关接口、身份校验和权限控制能力的开发与部分测试，真实已绑定账号从官网进入并成功获取私有结果的完整流程，还需要进一步验收。
虽然仍有工作需要完善，但这个方向让我看到了更多可能性。
过去，我们主要思考如何让AI回答公众提出的问题。现在，开始尝试让AI根据用户的身份，调用与他有关的业务数据，提供更加具体的服务。
对于公益机构而言，这可能比单纯增加一个聊天机器人更有实际意义。
未来，如果能够继续与业务流程结合，AI或许不仅可以帮助用户查询信息，还能协助他们理解任务、发现需要补充的材料，甚至完成部分经过授权的业务操作。
当然，这些仍然需要一步步探索。
六、从做出一个AI应用，到努力把它做好
回过头来看，从7月份第一版上线，到现在的2.0升级，我对AI应用落地也有了一些新的认识。
最开始，我更关注如何把OpenClaw部署起来，如何连接知识库和业务接口，以及怎样让AI能够回答更多问题。
这些工作当然重要，因为没有底层能力，应用就无法真正运行。
但当系统开始面向真实用户时，我逐渐发现，模型是否足够聪明，只是影响体验的其中一个因素。
一个问题能否得到准确回答，还取决于用户意图是否被正确理解、工具是否容易调用、接口数据是否完整，以及系统能否在遇到异常时及时停止无效尝试。
有时候，增加一个追问机制，比让模型反复尝试更有效；重新设计一个业务接口，也可能比不断修改Prompt更直接。
这让我更加确信，AI应用落地不能只关注模型和Agent框架，还需要真正理解业务。
对于公益机构来说，我认为这也是一条值得尝试的路径。
很多机构可能没有充足的技术预算，也不具备专门训练模型的能力，但已经积累了不少业务数据和信息系统。
如果能够把现有数据整理好，逐步完善接口，再结合大模型的自然语言理解能力，就有机会让这些已有资源发挥新的价值。
当然，2.0也远没有达到我理想中的状态。
目前的速度测试只是小样本对照，不能代表所有用户场景；一些查询结果的统计口径还需要继续完善，部分工具调用异常仍待排查，个性化业务服务也需要进一步完成完整链路的验证。
接下来，我希望继续通过真实用户的提问和反馈，观察它究竟解决了多少问题，而不只是统计回答速度有多快。
从第一版的“能用”，到第二版努力让它“更好用”，这几个月的过程让我感受到，AI应用并不是部署完成就结束了。很多真正有价值的改进，往往是在系统投入实际使用后，才逐渐发现和完成的。
我会继续记录这些实践，也希望能够给同样在探索AI应用的公益机构和开发者提供一些参考。
如果你也在尝试将Agent与现有业务系统结合，或者在工具调用、业务数据查询、用户体验方面遇到过类似的问题，欢迎一起交流。
毕竟，技术最终还是要回到真实的问题和使用它的人身上。
评论(0)
暂无