关于Agent智能体开发

AI Agent智能体开发

Agent和普通对话Chatbot本质区别

Agent能自主规划，记忆存储，工具调用，迭代执行，自我纠错能力的智能体执行体，能够自助拆解负责任务，调用外部工具，闭环完成目标，无需人工分布指令

Agent四大核心组件：规划，记忆，工具，感知

AGent四大核心各司其职：

1. 规划：拆解任务，排执行步骤
2. 记忆：存聊天记录和历史经验，反短期会话内存，长期向量记忆
3. 工具：调用业务接口，查询功能
4. 感知：接收所有输入信息，过滤垃圾数据交给大脑处理。

ReAct框架原理，思考+行动循环流程

React 就是三步循环：

1. 先让模型想清楚缺什么数据，该调用哪个工具；
2. 接着自动调用接口查数据；
3. 拿到结果后，再重新判断够不够。回答不够就继续循环，直到能给出完整答案，或者达到最大步骤停止。

简单业务 Agent 基本都用这个框架。

Plan and Execute 规划执行范式和 ReAct 适用场景差异

React 是走一步想一步，适合简单小事；Plan and Execute 先一次性把完整流程全部规划出来，再按步骤执行。这适合复杂长流程任务，比如自动处理完整工单、批量数据分析。它的可控性更强，不容易无限循环调用工具。

Agent的memory分为短期记忆、长期记忆，分别如何实现？

1. 短期记忆

   存储当前单次对话全部交互内容。

   (a) 基础实现：内存列表存储 message 数组，包括用户提问、Agent 思考工具、返回回答。

   (b) 生产优化：

   • 滑动窗口机制：超过 token 阈值，自动裁剪早期无用对话。
   • 增强对话摘要压缩：把久远多轮对话浓缩为精简摘要，减少上下文占用。
     © 生命周期：会话结束直接清空，不持久化存储。

2. 长期记忆

   存储跨会话长期用户信息、历史任务经验、常用知识库片段。

   (a) 实现流程：

   • 存储：每轮会话结束后，用 embedding 将重要交互经验文本转为向量，存入 Milvus 向量库，绑定用户 ID 标签。
   • 检索：新会话启动时，根据当前 query 做向量检索，召回相关历史经验，注入上下文。

对话历史持续累积，如何优化记忆，防止上下文窗口打满？

多种方案组合使用：

1. 滑动窗口截断。
2. 对话摘要压缩：定期调用轻量模型，把前序多轮对话压缩成几十字，用摘要替换原始长文本。
3. 长短对话分层，记忆分层。
4. 阶段性清理无关信息：过滤闲聊、失败的工具调用、重复的报错日志，只保留有效业务交互。
5. 动态阈值控制：实时统计当前上下文 token 总量，接近窗口上限时自动触发压缩。
6. 复杂任务分段执行：超长任务拆分为多轮会话，分段保存中间状态，避免单次上下文爆炸。

Agent如何自主选择工具？Function calling在工具调用中的作用？

1. 系统提示词：内置全部工具元数据（工具名称、功能描述、入参 schema、适用场景）。
2. 用户输入后，模型结合当前已有信息判断是否缺失数据，并对所有工具能力进行评估。
3. 匹配到对应工具后，严格按照定义的 JSON 格式输出入参；无匹配工具则直接生成回答。
4. 程序拦截模型输出，解析工具并执行指令，将操作结果回传给模型。

Function calling 强制模型输出标准 JSON 参数，程序能直接解析调用接口，不会出现文字描述参数无法解析的问题。

工具调用失败，接口报错，Agent层如何设计容错逻辑

接口超时就重试几次；

1. 参数填错：让模型重新生成参数。
2. 服务崩了：就切备用接口。
3. 连续报错：就暂停使用这个工具。
4. 实在查不到：就告知用户无法获取，不能一直循环调用。

Agent出现死循环无限调用工具是什么原因，如何解决？

死循环大多数是因为没有限制最大调用次数，导致模型反复查询同一内容。

解决方法：

1. 硬性规定最多循环次数。
2. 记录已经调用过的工具，避免重复。
3. 在提示词中写清楚，查到信息就停止查询。

LangChain 核心组件有哪些？Chain、Loader、Memory、Tools 的作用是什么？

LangChain 把大模型、文档、向量、工具、记忆全部封装为统一接口：

1. Chain：用来把多步操作串联起来。
2. Loader：负责读取各类文件。
3. Memory：自动管理聊天上下文。
4. Tools：统一包装接口，方便模型调用。

Long graph与long chain最大区别？

1. 执行架构

   (a) LangChain：是线性链式（chain），只能 A 到 B 到 C 单向串联，不支持循环、分支、并行。

   (b) LangGraph：基于有向图状态（StateGraph），通过节点加条件边，支持循环、判断、分支、人工介入、并行任务。

2. 状态管理

   (a) LangChain：无统一全局状态，多轮执行时上下文容易丢失。

   (b) LangGraph：内置全局 state 对象，所有节点共享，会话状态天然支持断点续跑。

3. 流程可控

   (a) LangChain：流程固定，无法动态跳转。

   (b) LangGraph：可自定义条件路由。

4. 持久化

   (a) LangChain：无内置断点能力。

   (b) LangGraph：原生支持 checkpoint 持久化会话。

低代码平台 Dify Codes 的优缺点

两者不用写太多代码，拖拽就能做知识库和机器人，适合内部小工具快速做 demo。

但对于大型高并发业务、涉密系统，以及需要大量对接自研业务接口的项目，不建议用低代码，定制和性能都跟不上。

什么是MCP协议？对Agent开发带来什么价值？

MCP，意为模型上下文协议。统一工具调用标准，相当于 AI 的通用接口：

1. 所有业务工具都做成 MCP 服务智能体，不用单独写适配代码。
2. 新增工具直接接入，权限和日志统一管理，开发和维护简单很多。

多智能体之间如何通信？如何避免任务冲突、重复执行？

通用方案：

1. 共享全局状态：langgraph state，所有 Agent 读写统一状态。

2. 标准化消息体：固定角色、任务类型、结果标记。

3. 消息队列解耦：Kafka，异步多 Agent 通信。

   防冲突重复执行方案：

4. 全局唯一任务 ID：每个子步骤标记完成状态，已执行步骤跳过。

5. 角色权限隔离：每个 Agent 只允许处理自己分工的任务。

6. 分布式锁：同一任务同一时间仅一个 Agent 处理。

7. 结果校验机制：重复产出自动合并去重。

8. 主控调度 Agent：统一分配任务，避免多 Agent 抢同一事务。

Function calling和MCP的区别？

Function calling 可以理解为一个流程。其核心原因在于模型无法调用工具，Function calling 这个流程就是：

1. 用户提出问题。
2. 模型做决策，确定需要调用哪个工具，并返回哪些参数。
3. 程序根据参数去调用工具，并返回结果给模型。
   一旦工具多了，应用与工具之间的接入就复杂了，所以 MCP 就出现了，它是一种标准协议。在应用和工具之间统一连接 MCP，这样大大节省了工具适配的成本

总结：

Function calling 管的是应用和大模型之间怎么指挥，模型返回标准指令，告知应用调谁、传什么参数。

MCP 管的是应用怎么接入工具。有哪些工具？怎么调，统一由 server 声明。

接着来讲 MCP 的构成（host宿主、client、server ）

host 即 AI 应用，例如 Cursor、codex。它向client发送指令。

Client负责翻译，翻译与连接server。

Server负责执行业务逻辑

Text to SQL智能SQL生成Agent提升准确率有哪些方案？

1. 元数据注入：把表名字段、字段含义、数据类型、关联关系全部写入系统提示词。
2. 增加少量 few-shot 标准 SQL 示例。
3. 增加约束：禁止删除、修改语句，仅生成查询 SQL。
4. 前置 query 改写：标准化用户口语化需求。
5. 执行前语法校验：自动修正字段名错误。
6. 增加反思步骤：生成 SQL 后让 Agent 自查逻辑是否匹配需求。
7. 分层生成：简单查询直接生成，复杂多表查询先拆解表关联再写 SQL。

代码Agent开发难点，如何保证生成代码可执行，安全？

难点：

代码容易报错，存在高危指令。

解决方式：

1. prompt限定依赖
2. 生成后进行语法校验
3. 代码放在隔离沙箱运行，禁止危险操作。
4. 运行出错让 AI 自动修改代码。

Agent会话状态如何持久化？支持断点续执行。

1. PostgreSQL、Redis 持久存储：会话唯一 ID 绑定全局 state。
2. LangGraph Checkpoint 机制：原生持久化状态，中断后传入 thread ID 恢复上下文。
3. 定时快照：长任务每一步自动落地快照，防止服务重启丢失进度。
4. 过期清理：闲置会话自动归档，释放存储资源。

Agent系统如何限流控制token消耗，降低调用成本？

1. 接口限流：基于 resilience4j 限制单用户、全系统 QPS。
2. 步数限流：限制每个 Agent 最大工具调用次数，减少多轮推理。
3. 缓存机制：高频问答固定工具返回结果，缓存重复请求不调模型。
4. 上下文压缩：减少无效 token 占用。
5. 分层模型：简单摘要检索用低成本小模型，复杂推理用大模型。

Agent工具调用的Json schema规范作用（Pydantic）

后端Pydantic自动序列化、反序列化，提前拦截参数错误

如何防止Agent调用高危工具，做好权限隔离？

1. 工具分级：普通查询工具开放，删改数据、系统操作、资金工具设置审批。
2. 角色绑定：工具不同，用户 Agent 可见工具列表不同。
3. 前置校验：识别高危操作，触发人工审核节点。
4. MCP 服务权限隔离：高危工具独立部署，单独鉴权。
5. 提示词约束。
6. 操作日志全留存，高危操作告警。

系统提示词如何设计？

角色定义

工具清单

执行规则：最大循环步数，终止条件，反思要求

输出格式

约束条款：禁止编造，禁止高危操作

Few-shot标准示例

记忆使用规则

如果从0手写简易Agent，整体架构如何设计？

分为四层：

1. 模型抽象层：封装各大模型同步、流式调用，统一返回结构。
2. 工具管理层：自定义工具类 JSON 参数解析、参数校验、接口执行、异常捕获。
3. 规划循环层：实现 ReAct 循环逻辑，配置最大步数、退出条件。
4. 会话存储层：Redis 数据库存储短期对话，向量库实现长期记忆。

完整执行流程：

接收用户输入，加载会话记忆，推理判断是否调用工具接口，执行回填结果，循环直到可回答，生成输出。