Agent落地的第一步，不是接更多工具，而是先读懂业务

上一篇文章里，我分享了基于OpenClaw（龙虾）搭建基金会中心网AI智能客服的过程。

上线之后，我们陆续收到了一些基金会行业用户的反馈，也进一步看到了大家对这类AI应用的期待。

但真正开始有人使用之后，我也发现了一些问题。

其中一部分问题，来自用户对“AI智能客服”的理解。

很多人看到一个AI对话框，会天然把它理解成一个“什么都能问”的AI。除了查询基金会行业的数据、政策和相关分析，也会问一些完全超出我们原本业务范围的问题。

比如：

“如何购买一家基金会？”

还有一些问题虽然属于基金会行业的数据查询，但AI给出的结果并不一定完整，或者和用户期待的结果存在差距。

这里面有一个很现实的原因。

上一版智能客服调用的很多数据接口，本来是给网站页面使用的，并不是专门围绕Agent的调用方式设计的。

网站调用接口的时候，页面知道自己需要什么数据，程序员也提前写好了固定的调用逻辑。

但Agent不一样。

它面对的是自然语言。

同一个数据需求，用户可能有十几种不同的问法，而且一个问题背后还可能需要连续查询多个接口，再把结果组合起来。

如果接口本身没有针对这种场景进行整理，Agent就需要自己判断该调用哪个接口、传什么参数、下一步再查什么。

问题一复杂，它能够“猜”的空间也就越来越大。

AI回答得慢，有时候不是因为模型不够聪明

这也是我在上一版智能客服上线后看到的第二个问题。

第一版虽然已经搭建了一套Agent调用数据和知识库的架构，但真正面对用户之后才发现，用户的问题远比我们预设的更加多元。

当一个问题超出了原本设计好的调用路径，Agent就需要自己判断用户到底想问什么，再不断尝试不同的工具和数据接口。

有时候你会看到一个问题等待很久。

背后并不一定是大模型“思考了很久”，也可能是Agent在不断选择工具、修改参数、重新调用数据。

最后，它可能拿到了答案，也可能绕了一圈之后发现没有合适的数据，甚至基于不完整的信息给出了一个并不准确的回答。

所以我们现在正在优化2.0版本。

其中一个方向，是重新整理面向Agent的多维数据查询接口。

另一个方向，是把一些高频业务场景进一步结构化。

例如，当识别到用户是在查询某类基金会数据时，不再完全依赖模型临时决定“下一步做什么”，而是尽可能把问题路由到对应的Tool或Skill，并在工具内部定义相对明确的数据来源、参数要求和调用流程。

这样做并不能保证AI永远不会出错。

但至少可以减少不必要的工具尝试和数据调用，把原本完全依赖大模型临场判断的一部分工作，变成更加可控的业务流程。

我最近越来越觉得：

Agent落地的关键，并不只是给它更多工具，而是减少它需要“猜”的东西。

Agent越来越多，但我反而开始关心另外一件事

从年初OpenClaw（龙虾）的爆火，到后来不断出现新的Agent、办公智能体和AgentHarness。

Hermes、WorkBuddy、千问办公、豆包相关的智能体产品，再到最近的DeepSeekHarness……

新的工具不断出现。

有时候几天没有关注AI的消息，就会产生一种“是不是又落后了”的感觉。

但折腾了一段时间以后，我自己的关注点反而开始发生变化。

这些Agent的能力当然越来越强。

但如果它不能真正进入我们的工作流程，不能访问业务需要的数据，也不知道我们的项目究竟是怎么运转的，那么再强的模型，很多时候仍然只能给我们提供一个“参考答案”。

于是就很容易出现一种状态：

每天都在学习新的AI工具，看起来什么都知道一点，但真正回到自己的工作里，却不知道下一步应该让AI干什么。

或者做出了一个看起来很厉害的Demo，实际放进业务流程以后，却解决不了多少真实问题。

所以现在我更愿意把精力放在另外一件事情上：

怎么把自己的业务和AI连接起来。

这里的“连接”，并不只是接一个API。

而是要逐渐让Agent获得完成任务所需要的业务上下文、数据和工具。

它需要知道：

我们的业务里有哪些对象？

这些对象之间是什么关系？

数据存在哪里？

不同字段是什么意思？

一个业务问题应该从哪里开始查？

查到什么结果以后，下一步应该做什么？

哪些操作可以执行，哪些操作不能执行？

这些东西，过去大多存在于人的经验里。

现在，它们正在慢慢变成Agent的上下文和工具。

2024年做的一件“小事”，现在突然有了新的价值

2024年，我加入基金会中心网以后，我们发起了一项叫“数据筑基”的工作。

当时我一个很明显的感受是：

机构已经积累了很多年的业务系统和数据库，但是能够真正把这些数据关系说清楚的人并不多。

数据库里有哪些表？

每张表是干什么的？

每个字段是什么意思？

哪些表之间可以关联？

同一个指标在不同业务里采用什么统计口径？

这些信息有的存在于代码里，有的存在于历史文档里，还有相当一部分存在于开发人员的经验里。

所以很多时候，一个看起来很简单的数据需求，真正耗费时间的并不是写SQL。

而是重新理解数据库。

你得先想起来：

这个数据到底在哪张表？

这张表和另外一张表通过什么字段关联？

这个字段记录的是当前状态还是历史记录？

最后统计的时候应该按照什么口径？

于是那段时间，我开始陆续把数据库里的表、字段、业务说明和部分关联关系整理到ShowDoc中，慢慢形成了一套自己的数据模型字典。

当时做这件事情，其实没有多少人关注。

因为它看起来就是一份很典型的“程序员文档”。

除了开发和数据相关的同事，很少有人会主动打开它。

我当时想得也很简单：

以后自己查数据的时候，不用每次重新翻代码就行了。

但两年以后，我突然发现：

这份原本写给人看的文档，也可以开始给Agent看了。

与其让Agent猜，不如先把项目告诉它

这是我最近使用Agent时一个比较明显的变化。

过去我们使用AI写SQL，经常是这样的：

我告诉AI：

“帮我查一下某类基金会的数据。”

然后再把几个表结构贴给它。

AI根据表名、字段名和我提供的一点上下文，猜测这些表之间应该怎么关联，再生成SQL。

如果结果不对，我再继续告诉它：

“这个字段不是这个意思。”

“这里还需要关联另外一张表。”

“统计口径不是这样。”

本质上，我一直在做一件事情：

不断给AI补上下文。

现在，我开始把这件事情往前移。

我使用的ShowDoc里保存了已经整理好的数据模型字典，再通过MCP等方式让Agent在需要的时候读取这些文档。

这样，当我提出一个数据需求时，Agent不再只能面对几个陌生的表名和字段名。

它可以先查询数据字典，获得相关的表结构、字段说明、关联关系和业务备注，再基于这些上下文生成SQL。

这里我觉得有一个表述需要特别注意。

并不是说：

“有了数据字典，Agent就理解了整个业务。”

这显然说得太大了。

更准确地说，是：

我们开始把原本只存在于开发人员脑子里的部分业务知识，转化成Agent可以检索和使用的上下文。

这会减少它仅凭字段名称和模型常识进行推断的情况。

这也是我现在越来越认同的一种Agent使用方式：

不要一上来就让AI执行任务。

先让它知道自己正在面对一个什么样的项目。

数据字典+Skill，开始改变一些内部的数据工作

后来，我基于这套数据字典，又在WorkBuddy中整理了一个内部的数据查询Skill。

它做的事情并不复杂。

同事提出一个数据需求之后，Agent会先根据需求读取相关的数据字典和业务说明，然后生成对应的查询语句，通过受控的数据查询能力执行SQL，最后再把查询结果进行整理和分析。

大致可以理解成：

用户提出需求

↓

Agent判断需要查询的数据

↓

读取数据模型字典

↓

生成SQL

↓

通过受控的数据访问接口执行

↓

整理查询结果

↓

返回给用户

以前，这类事情大部分需要找我。

因为数据库里的表比较多，关联关系也比较复杂。

同事告诉我：

“帮我导一下这些数据。”

我首先还是得重新捋一遍表之间的关系，然后写SQL、执行、检查结果，再导出来给他。

包括我自己平时也经常需要了解：

目前基金会年报披露到什么程度了？

哪些基金会已经完成观测？

某一类数据现在有多少？

过去如果每一个需求都做成后台功能，就意味着要重新经历一遍比较传统的软件开发过程：

梳理需求、设计产品、做UI、开发前后端、测试、上线，再教操作人员怎么使用。

如果需求相对固定、需要长期高频使用，这当然仍然值得做。

但现实中还有大量临时性的、低频的数据查询需求。

这些需求专门开发一个后台页面，成本太高；每次找技术人员查，又很低效。

而Agent+Skill，刚好填补了中间这块空间。

它不是要替代所有后台系统。

而是在一些规则比较清晰、数据已经存在、但需求变化比较频繁的场景中，提供了一种新的交互方式：

过去是人去学习后台怎么操作。

现在可以变成：

人说自己想要什么，Agent帮他寻找数据和工具。

但这中间有一个绕不过去的问题：安全

说到这里，很多做技术的人应该会立刻想到一个问题：

你把数据字典甚至数据库查询能力交给Agent，不危险吗？

确实，这是必须认真考虑的问题。

尤其是机构内部数据库，很可能存在不应该被外部访问的数据。

所以我的做法不是直接把数据库账号和密码配置给Agent，让模型自己连接数据库。

目前在这个Skill中，我增加了一层身份验证。

当用户第一次调用相关能力时，本地会启动一个Web验证页面，要求用户完成内部身份登录。

验证通过以后，系统返回一个有时效性的访问Token。

后续Agent调用数据查询能力时，需要携带这个Token，由数据访问层验证用户是否具有相应权限。

也就是说：

Agent拿到的不是数据库密码，而是经过授权以后可以调用的数据能力。

这两者还是有很大区别的。

当然，这并不意味着有了Token就安全了。

如果真正应用在生产环境，还应该继续考虑最小权限、数据库只读账号、SQL类型限制、敏感字段控制、查询审计以及PromptInjection等风险。

安全的核心不是“相信Agent不会做错事”，而是：

即使Agent判断错了，它能够做的事情也应该被限制在一个可控的范围内。

这一点我认为比不断优化Prompt更重要。

一个真实的使用场景：FTI指标查询

目前，这个Skill已经开始在我们内部的一些数据查询场景中使用。

最近比较典型的就是中基透明指数FTI的相关工作。

FTI观测期间，经常会有基金会来询问：

“为什么我们的这个指标没有通过？”

过去遇到这种问题，我们需要根据基金会名称，分别查询它对应的多个指标数据，再结合观测规则判断具体原因。

如果问题比较复杂，还需要技术人员一起查数据库。

现在，对于其中一些已经明确规则和数据来源的场景，同事可以直接把基金会名称和问题交给Agent。

Agent根据已经配置的数据字典、查询能力和相关规则获取对应的数据，再把结果整理出来。

最终的判断仍然需要结合业务规则进行确认，但原本大量“找数据”的工作，可以先由Agent完成。

这带来的变化其实并没有那么戏剧化。

它不是说：

“AI替我们完成了全部工作。”

而是：

以前人需要在多个系统和数据表之间寻找信息，现在Agent开始替人完成其中一部分寻找、关联和整理工作。

这反而是我现在觉得最有价值的地方。

最后

这段时间折腾Agent，让我越来越觉得：

真正阻碍AI进入业务的，很多时候不是模型能力不够。

而是我们的业务本身还没有准备好被机器理解和调用。

文档散落在各处。

业务规则存在人的脑子里。

数据之间没有明确的说明。

系统之间彼此割裂。

接口是为页面设计的。

权限体系默认只有人会操作。

这些问题，在过去可能只是“数字化做得不够好”。

到了Agent时代，它们又变成了AI落地过程中必须补的一层基础设施。

所以回头看，2024年整理的那份数据字典，我当时只是希望：

以后自己查数据方便一点。

没想到两年以后，它开始变成Agent认识这个项目的一扇门。

我现在也开始有意识地做一件事情：

让Agent在执行任务之前，先阅读项目文档。

因为与其不断提高它“猜对”的能力，

不如尽可能减少那些原本就不应该让它猜的东西。

如果你也在尝试把Agent接进自己的业务系统，或者在数据、知识库、Skill、MCP这些环节遇到了类似的问题，也欢迎和我交流。

我也还在继续实践和踩坑。