一、背景

随着大语言模型（LLM）能力的提升，如何将其稳定、可控地接入企业内部大量 RESTful API，成为 AI Agent 在真实业务中落地的关键问题。

RestGPT（RestfulGPT）论文提出了一种较为系统的解决方案：
通过 规划（Planner）—API 选择（API Selector）—执行（Executor） 的结构化流程，使 LLM 能够在有限上下文窗口内逐步完成复杂 API 调用任务。

本文基于一个参考 RestGPT 论文并完成工程验证的 Agent 项目，对系统设计进行复盘，并在此基础上讨论一些尚未实现、但具有明确理论依据的演进方向。

二、系统整体设计

该项目以 RestGPT 论文为核心理论基础，结合 RAG 机制与Langraph任务状态管理思想，构建了一个面向企业 API 调用场景的 AI Agent 原型系统。

核心设计包括：

• 基于 RAG 的工具（API）存储、检索与重排序

• 基于 LangGraph 思想的 Task 任务状态机制，并利用nodes,edges来进行知识图谱更新，用于前端页面展示。

• 基于 LangGraph的人机交互-进行人类反馈驱动的执行确认流程

• 对大模型输出噪声与幻觉的工程化约束

• 针对提示词注入的基础安全防护设计

三、工具管理与 RAG 机制

3.1 工具存储与检索

系统采用 Milvus + MongoDB 管理企业侧工具：

• Milvus

  • 存储 API 描述向量

  • 使用 HNSW 算法进行高效相似度检索

• MongoDB

  • 存储 API 元信息

  • 包括 API 描述、参数定义与响应结构（OAS）

该设计符合 RAG 的基本思想：
通过检索缩小候选空间，再由 LLM 进行推理决策。

3.2 工具筛选流程（由粗到细）

工具筛选流程严格参考 RestGPT 的 coarse-to-fine 思想：

1. 召回

   • 基于向量相似度获取候选工具集合

2. 重排

   • 结合任务语义进一步过滤候选工具

3. 精选

   • 由大模型给出最终工具

   • 对输出不合法的情况进行严格解析处理

四、任务状态机制与人类反馈

4.1 Task 任务状态设计

借鉴 LangGraph 的状态驱动思想，系统引入 Task 任务状态表，用于记录 Agent 每一步的关键信息：

• task_id

• 原始用户请求

• 当前子任务

• 工具信息（含 curr_tool_id,curr_param）

• 参数提取与补全结果

• 任务状态

该机制将 Agent 的隐式推理过程转化为可追溯、可回放的工程状态。

---

4.2 人类反馈驱动的执行流程

系统在工具筛选与参数补全完成后，并不直接执行 API，而是：

1. 将结果写入 task 表

2. 等待用户反馈

3. 用户确认后，从 task 表读取 curr_tool_id 并执行调用

该设计有效降低了大模型在复杂业务场景下的决策风险。

五、人类意图识别机制

系统采用双层意图识别：

1.关键词识别-通过关键词识别用户是否需要执行工具或者是放弃

2.大模型进行意图识别

但大模型能力有限:所以兜底策略-如果无法识别或识别结果并非是confirm或者是absort那么就判定为unclear，需要用户继续进行反馈。

大模型调用策略：

• 携带历史上下文

  • 多轮对话

  • 支持重试与退避机制

• 不携带历史上下文

  • 单轮调用直接输出

六、单任务与多任务处理

系统区分 单任务 与 多任务：

• 多任务场景下，仅生成第一个子任务

• 后续通过迭代推进，而非一次性展开完整规划链条

该设计与 RestGPT 论文中“逐步生成子任务”的思想保持一致。

七、参数提取与补全

7.1 参数提取

• 通过大模型生成 JSON 格式参数

• 对输出进行严格解析：

  • 清理 ```json、''' 等噪声

  • 建立参数名与描述的双向映射

  • 删除多余字符

7.2 缺失参数处理

• 判断是否存在缺失参数

• 由大模型生成查询 API 指令进行补全

• 更新 task 状态，等待用户确认

八、RestGPT 论文思想的工程映射

RestGPT 提出三大模块：

• Planner：拆解复杂任务并迭代推进

• API Selector：为当前子任务选择合适 API

• Executor：调用 API 并解析 JSON 响应

论文指出 RESTful API 返回结果通常冗余且结构复杂，因此利用 OAS 定义的响应模式，由 LLM 生成解析代码，再由程序执行解析。本项目在设计上遵循了这一思想。

九、模型限制与异常处理

在实践中，大模型可能出现：

• 工具误选

• 参数幻觉

• 输出格式不规范

系统采用的工程策略包括：

1. 多模型切换

2. 严格输出解析

3. 重试机制

4. 退避机制

5. 多 API 循环检测

十、上下文与摘要策略

• 上下文超限

  • 仅保留最近 N 条历史消息

• 多任务结果

  • 分块摘要

  • 最终统一摘要

• 同质化结果

  • 前端展示数量限制

  • 冗余结果直接截断

十一、安全性设计：提示词注入防护

在我的项目中，由于我的业务是供企业内部使用，所以主要进行业务逻辑漏洞判断，但是延申可以借鉴以下论文。

参考论文 Formalizing and Benchmarking Prompt Injection Attacks and Defenses，系统采用三层防护：

1. 输入层：检测恶意或覆盖指令

2. 逻辑层：API 描述与请求参数是否矛盾

3. 参数层：非法参数值校验

十二、理论延申（未实现）

以下内容为工程实践后的理论思考，并非当前项目已实现功能：

• GraphRAG

  • 通过知识图谱显式建模 API 调用关系，降低规划复杂度

• 多 Agent 架构

  • 按业务领域拆分 Agent（订单、库存、物流等）

  • 借鉴微服务思想降低系统耦合度

同时，多 Agent 也会带来上下文管理与状态一致性的挑战，需要更严谨的设计。

十三、总结

AI Agent 项目必须紧密结合具体业务场景。
大模型并不真正理解业务逻辑，而是通过模式拟合进行推理。

在这一过程中，程序员的核心价值体现在：

• 业务逻辑拆解与建模

• 系统架构与状态设计

• 安全、稳定、可维护的工程实现

LLM 更像是能力放大器，而非业务替代者。