大型AISecOps Agent难题: 20+功能Agent, 300+API的复杂集成
原创 Li JieJie 2025-08-11 12:01 北京
让我们来讨论一个企业级Agent设计难题。如果是你，你将如何设计，组织，调度一个20+功能Agent，300+ 数据表，几百个API的复杂系统？
调用工具的常见方法
ReAct Agent中如何使用组织和调用工具？常见的方法
Prompt： 写提示词约定，让它输出某个包含function 和 参数的json。简单，自然语言，但缺点是非常不稳定，扩展性差，参数处理容易出现问题
Function Call：稳定、安全性最高，确定性最高
依赖LLM 动态生成下游代码 (SQL/DSL/Python)： 灵活性极高，支持处理复杂动态查询。但缺点明显，非常不稳定，有安全风险（如SQL注入）。 视你使用的模型能力强弱，通常，失败率不低
你看到了，Function Call肯定是最好的啊。
事实上，20个Tool以内的场景，你可以比较自由地组合上面的3个方法，怎么方便怎么来。
然而，当存在几百个工具的时候，Function Call也玩不转了。
工具过多撑爆LLM上下文
假设你有200个工具（函数），每个工具都有一定长度的功能描述、参数描述。200个工具描述，累计占用的上下文（输入Token），是无法接受的，会出现撑破模型上下文窗口。
无论LLM最终是否决定调用这200个工具里的某几个，全部定义（json schema）都需要被完整地发送出去，因为模型需要看到所有工具，才能判断到底用不用，用几个。极端情况，你发了200个工具描述，LLM响应：谢谢你，jiejie，工具都很好，但，没有我需要的那个。
还有一个大问题，工具过多之后，会极大地分散LLM注意力。甚至由于部分工具存在相似性。模型的表现会越来越不稳定。 这次选ToolA，下次说不定选出来ToolB。结果的确定性、一致性会显著下降。
工具检索 Tool RAG
200个工具直接堆一起，肯定是不能用的。LLM会陷入选择困难。常见的解法
数据和工具分层设计
把你的工具、你的数据，通过分类方法聚类。在识别用户意图之后，通过一定算法选取子集或路由
弊端：心累，耗费不少时间为工具打标、分类。而且，你的分类真的合理吗？
通过用户自然语言输入，检索适当工具
这个方法叫Tool Rag
第一种，太麻烦了，先放弃吧。如果你有现成200个提供工具、暴露API的业务帮你写，可以考虑。
第二种，让我来写几个demo测一下。
需要说明的是，我没有对用户输入进行丰富预处理。像安全Agent，运营同事的输入可能非常简单，你看到的意图就2个字："调查" "排查"。
试验条件
存在98个安全运营工具，每个工具都是一个函数，doc string都写好了
functions.append({"name": node.name, "docstring": docstring})嵌入模型使用Gemini text-embedding-004(QUESTION_ANSWERING)
存储使用ChromaDB
我们来检索几个问题看看效果
输入: lijiejie名下有哪些漏洞？命中工具:Tool: get_owner_by_domain, Similarity: -0.1327Tool: get_installed_software_list, Similarity: -0.1965Tool: get_http_headers, Similarity: -0.2008Tool: search_for_jar_package, Similarity: -0.2079Tool: check_domain_in_waf, Similarity: -0.2234Time elapsed: 2.73
耗费3秒，就查出来这些工具，巨坑。
输入: 找出所有受CVE-2025-6554 影响的资产，需要owner信息？命中工具:Tool: get_owner_by_ip, Similarity: 0.1356Tool: get_owner_by_url, Similarity: 0.1240Tool: get_owner_by_domain, Similarity: 0.0913Tool: query_url_owner, Similarity: 0.0565Tool: query_ip_owner, Similarity: 0.0450Time elapsed: 2.64
不查了，可以看到，如果不处理意图转换，这条路绝对是行不通的。至少在安全运营的场景，运营同事的输入，利用语义相似度查询，查出来的工具没有卵用。因为如果你不是安全运营，根本不可能懂得输入和要用的工具是什么依赖关系。
像上面的问题，笔者输入了owner这个关键词，就命中出来一堆owner工具。这对吗？明显不对！
我的方案: 只告诉LLM有什么数据
在前面2篇文章中，笔者已经提到过自己的方案
0 Tools：是的，这并不是最可靠的方案，我没有声明任何工具
只告诉模型数据在哪里，有什么样的数据。具体要查什么，由LLM自己决策
所以，我必须再次强调。模型理解分析场景、分解任务的能力至关重要，安全运营场景下，应该调哪个Agent去完成任务，是LLM自己决定的
如通你的模型能力太弱，绝对是玩不转几百个数据表，几十个Agent多轮来回调用的复杂场景。
Prompt + 数据分层：将数据进行简单分层聚类。由于工具众多，必须进行适当的聚合，再到功能Agent中，进行子任务的分析处理。
总结
总结，Tool RAG不行，这种语义相似度查询根本不好用。
Prompt并不稳定，但在几百个工具（Tool）的情况下，你就需要考虑这个最不稳定的prompt方案。
功能性Agent内部你可以with tools，通过Function call 去组织工具。