1.什么是AI Agent（智能体）？
2.AI Agent的主流设计模式有哪些？
3.什么是AI Agent中的function call？
4.什么是AI Agent中的MCP（Model Context Protocol）？
5.AI Agent中function call和MCP的区别是什么？
6.AI Agent中的Agent2Agent(A2A)？
7.AI Agent中的A2A和MCP的区别是什么？
8.当前AI Agent中的主流核心大模型有哪些？
9.AI Agent中的系统提示词有哪些作用？
10.在AI Agent中如何构建强大的系统提示词？
11.System Prompt在AI Agent内部是如何生效的？
12.AI-Search和普通Search有什么区别？
13.什么是DeepSearch？
14.AI Agent和AI Workflow的区别在哪里？
15.在AI Agent中，function call如何把外部工具变成大模型可以理解的方式？
16.在AI Agent中，大模型如何学习到Function Calling能力？
17.当前AI Agent有哪些局限性？
18.当前AI Agent有哪些主流的评价指标？
19.AI Agent如何具备长期记忆能力？

1.什么是AI Agent（智能体）？

在AIGC时代，Rocky认为AI Agent是一个非常重要的方向，也是AIGC技术发展的大势所趋。

那么，AI Agent到底是什么呢？

Rocky首先给大家讲解一下非AI Agent（Non-Agent），即常规AIGC大模型的运行逻辑，然后我们就能从两者的对比中恍然大悟。

我们以经典的文本内容创作为例子🌰，非智能体、智能体以及人类创作者的工作流呈现显著差异：

主体类型	执行特征	流程剖析
Non-Agent（非智能体）	线性单次输出	用户输入提示词→大模型直接生成终稿（无迭代过程）
AI Agent（智能体）	多阶段认知闭环	规划大纲→检索资料→生成初稿→自检修订→循环优化→输出终稿（模拟人类创作思维）
人类创作者	认知驱动型工作流	构思框架→信息搜集→内容填充→交叉审核→反复润色（与智能体流程高度同构）

我们可以发现：AI Agent的核心是通过任务解构-执行-反思的认知闭环，实现对人类工作范式的数字孪生。

AI行业大牛吴恩达认为，AI Agent的终极演进方向是构建具备完整认知能力的数字主体，其技术架构可解构为四大核心能力：

反思（Reflection）：AI Agent模拟人类自我修正行为，如同学生完成作业后的自主检查过程。突破单次推理局限，建立错误检测-反馈-修正的增强回路。在代码生成、法律文书等高精度需求场景实现质量跃升。
工具调用（Tool use）：AI Agent判定自身能力边界，选择合适的AI工具（AI服务/搜索引擎/专业数据库等）来提升大模型的能力边界。
规划（Planning）：AI Agent在解决复杂问题时，为到达目标制定合理的行动计划的能力，从而对任务进行拆解。
多智能体协作（Multi-agent collaboration）：多个AI Agent的组合应用，我们可以畅想当每个用户可配置专属AI团队（产品经理Agent+工程师Agent+测试Agent+商务市场Agent等），传统生产模式将被重构。

我们都知道自动驾驶领域对技术级别有L1-L5之分，级别越高代表越向无人驾驶靠近。在AIGC时代，我们可以对AIGC技术的能力演进路径进行级别划分，同样可构建五个级别：

层级	能力定位	人机协作范式	演进状态
L1	基础工具（Tool）	用户独立完成全流程，系统无显性AI能力	技术替代进程中
L2	对话辅助（Chatbot）	用户主导执行，AI提供信息参考（如知识检索、建议生成）	基础应用形态
L3	协同创作（Copilot）	人机任务共担：用户设定目标→AI生成初稿→用户修正确认	当前核心价值区
L4	智能体（AI Agent）	用户定义目标与资源，AI自主实现任务拆解、工具调度、过程管控的全闭环	近通用AGI临界点
L5	通用智能（Intelligence）	系统自驱完成目标定义、资源获取、工具调用及结果交付	理论发展阶段

当前AI Agent的核心还是基于LLM大模型+深度的Prompts工程，Rocky认为未来AI Agent会有更多内涵，比如：

AI Agent中的核心大模型可能是基于AIGC多模态大模型构建的。
AI Agent中会包含更多的模态能力，比如图像、视频、音频、数字人等。
会有基于AI Agent为核心的爆款AIGC产品问世。
基于AI Agent的AI算法解决方案会在各行各业落地，重构各行各业的业务形态。

2.AI Agent的主流设计模式有哪些？

当前主流的AI Agent（Manus、Deep Research等）都是基于LLM大模型 + 一整套AIGC算法解决方案(Prompts工程、Function Call、MCP、AI工程策略、AI功能服务等)构建而成，同时未来还会持续扩展延伸其内涵。

基于上面的框架，接着再形成了5种主流的AI Agent设计模式：

反射模式（Reflection pattern）：这个模式的核心运作机制是构建自检-纠错迭代环，AI Agent会审查其工作以发现错误并迭代，直到生成最终输出结果。

工具使用模式（Tool use pattern）：AI Agent允许LLM大模型通过使用外部工具获得更多信息，包括调用API、使用AI服务、查询矢量数据库、执行Python脚本等。这使得LLM大模型不仅仅依赖于其内部知识，还可以获得互联网世界的庞大实时数据流来扩展知识边界。

ReAct模式（Reason and Act）：ReAct模式结合了反射模式和工具使用模式，这使其成为当前AI Agent使用的最强大的模式之一。AI Agent既可以自我思考，自我纠错，还可以使用工具与世界交互。

规划模式（Planning pattern）：在这种模式下，AI Agent根据任务的复杂程度，设计任务计划流程，对任务进行细分，再对细分子任务动用ReAct 模式进行处理。可以说这种模式是一种战略思维，可以更有效地解决战略级复杂任务。

多智能体模式（Multi-agent pattern）：在这个模式中，AI Agent系统中包含多个子Agent，每个子Agent都分配有一个专用的角色和任务，同时每个子Agent还可以访问外部工具进行综合工作。最后，所有子Agent协同工作以提供最终结果，同时根据需要将细分任务委派给其他子Agent，形成一个复杂的“AI Agent协同社区”。

3.什么是AI Agent中的function call？

在AI Agent架构中，Function Call（函数调用）本质上是智能体通过LLM大模型调用外部能力（API、AI服务、AI工具、数据库、搜索引擎等）并进行整合处理的闭环过程。

接下来，Rocky举一个生动形象的例子，让我们通俗易懂的领会Function Call的整个流程。

假设我们已经有一个AI Agent系统，里面的核心LLM大模型是DeepSeek和GPT-4o，我们想要设计一个快速帮女朋友购买丝袜的AI服务-《丝袜选购服务》，实现AI Agent能够灵活帮女朋友选购丝袜的功能。

这时，Function Call的整体流程如下所示：

需求解析阶段（Demand Analysis）：我们输入丝袜选购问题，LLM大模型（DeepSeek/GPT-4o）先解析用户自然语言请求（如“帮女友买波点黑丝”），识别核心参数：

{"品类": "丝袜", "风格": "波点", "颜色": "黑色", "用户身份": "送礼"}

工具决策阶段（Tool Orchestration）：如果问到了丝袜选购问题，LLM大模型则分析生成出需要调用丝袜选购服务function以及调用丝袜选购服务function要传入的参数，生成结构化调用JSON指令：

     {  
       "function": "hosiery_selection_service",  
       "parameters": {  
         "material": "nylon-spandex",  
         "opacity": "sheer",   
         "color": "black",  
         "purpose": "gift"  
       }  
     }

服务执行阶段（Service Execution）：接着开始调用丝袜选购服务function，返回结构化结果：

     {  
       "recommendations": [  
         {"brand": "Wolford", "price": 189, "features": ["防勾丝", "微透明"]},  
         {"brand": "Calzedonia", "price": 89, "features": ["简约塑形", "透气"]}  
       ],  
       "delivery_time": "当日达"  
     }

响应生成阶段（Response Synthesis）：最后将function返回的内容追加到输入提示词中，一起给到大模型，让它总结完善回答，并将答案整理好生成回复给我们：

“推荐两款高品质黑丝：

Wolford透肉款（189元）：顶级防勾丝工艺，微透明设计提升舒适度

Calzedonia塑形款（89元）：简约显瘦同时透气性强
⚡️均可今日送达，礼物建议选Wolford+礼盒包装”

全流程可视化图表

graph TB
    A[用户输入<br>“送女友的波点黑丝推荐”] --> B{需求解析}
    B -->|DeepSeek/GPT-4o| C[参数结构化提取<br>▪ 材质：尼龙-氨纶<br>▪ 款式：波点<br>▪ 颜色：黑色<br>▪ 场景：送礼]
    C --> D{工具决策}
    D -->|函数匹配| E[调用丝袜选购服务<br>hosiery_selection_service<br>material='nylon-spandex', opacity='sheer', ...]
    E --> F[电商API实时查询<br>▪ 品牌库存<br>▪ 价格区间<br>▪ 物流时效]
    F --> G{结果整合}
    G -->|LLM场景化重构| H[自然语言响应<br>▪ 产品对比<br>▪ 礼物建议<br>▪ 交付信息]

到这里，相信大家已经对AI Agent的Function Call有一个清晰的了解，接下来我们再总结一下Function Call与传统API调用的本质区别：

维度	传统API调用	Agent Function Call
输入格式	结构化参数（JSON/XML）	自然语言指令
调用方	开发者硬编码触发	Agent自主决策触发
错误处理	显式异常捕获	反射机制自动重试/替换工具
协议依赖	固定通信协议（REST/gRPC）	支持MCP等自适应协议

关键阶段解析：

意图识别
- 大模型解析“查询天气”语义，定位到工具类别
参数抽取
- 从自然语言提取结构化参数（材质：尼龙-氨纶, 款式：波点, 颜色：黑色, 场景：送礼）
协议转换
- 生成工具要求的调用格式（如OpenAI Function Calling规范）
结果整合
- 将工具返回的数据转化为自然语言响应

技术哲学启示：当Function Call从技术组件进化为AI Agent与现实的通用接口，人类正将“行动权”赋予人工智能。这不仅是效率革命，更是认知范式的迁移——我们不再需要理解螺丝刀的结构，只需说：“请把画挂在墙上。”

4.什么是AI Agent中的MCP（Model Context Protocol）？

2024年11月25日，Anthropic发布技术白皮书《Model Context Protocol: A Standardized Interface for AI Integration》，首次提出MCP（Model Context Protocol协议框架的概念。

MCP（Model Context Protocol）构建了AI大模型与外部应用程序间的上下文交换规范，这使得AI开发者能够以一致的规范将各种实时数据源、AI工具和外接功能连接到AIGC大模型中，就像Type-C让不同设备能够通过相同的接口连接到主机一样。MCP的目标是创建一个通用标准，使 AI 应用程序的开发和集成变得更加简单和统一。

在没有MCP之前，AIGC大模型和外部功能交互时的Function Calling是可以五花八门的，这样就导致了虽然有海量的应用程序和多样的AIGC大模型，但是他们之间却不一定能够兼容组合。而MCP就是以更标准的方式让AIGC大模型使用不同的外部工具，只要这些外部工具根据MCP协议定义输入输出规范。

MCP由三个核心组件构成：Host、Client 和 Server。让我们通过一个实际案例来理解这些组件如何协同工作：

假设我们正在使用AI Agent询问："帮我女朋友购买丝袜？"

Host：AI Agent作为 Host，负责接收我们的提问并与其中的AIGC大模型交互。 Client：当AIGC大模型需要确定丝袜购买方案时，Host 中内置的 MCP Client 会被激活。这个 Client 负责与适当的 MCP Server 建立连接。 Server：在这个例子中，丝袜购买方案 MCP Server 会被调用。它负责执行实际的丝袜购买方案确定操作，访问对应的电商API，并返回找到的丝袜购买方案。

整个流程是这样的：我们的问题 → AI Agent(Host) → AIGC大模型 → 需要丝袜购买信息 → MCP Client 连接 → 丝袜购买 MCP Server → 执行操作 → 返回结果 → AIGC大模型生成回答 → 显示在AI Agent上。

这种架构设计使得AI Agent中的AIGC大模型可以在不同场景下灵活调用各种应用工具和数据源，而AIGC开发者只需专注于开发对应的 MCP Server，无需关心 Host 和 Client 的实现细节。

5.AI Agent中function call和MCP的区别是什么？

在AI Agent领域视角来看，MCP可以说是function call的更进一步延伸和封装。

function call解决了AIGC大模型与外部应用工具之间交互的问题；而MCP则在此基础上对交互的整个流程进行规范化，从而解决海量数据、AIGC大模型、AI应用工具之间的“孤岛”问题。

6.AI Agent中的Agent2Agent(A2A)？

Agent2Agent (A2A) 协议 是驱动多智能体生态系统的核心通信框架，其本质是 AI Agent之间的标准化协议，也是Agent之间的“社会契约”。

在没有A2A协议之前，不同的Agent A（DeepSeek）与Agent B（GPT-4o）输出格式各异，无法进行协同合作，形成了很多的AI Agent孤岛。

因此通过A2A协议，为异构 AI Agent之间的互通与交互提供通用的语言：

graph LR
    A[Agent A] -->|原生JSON| B[A2A协议层]
    C[Agent B] -->|原生XML| B
    B --> D[统一通信格式]
    D --> E[共识决策引擎]

核心工作机制

1. 分布式共识流程

案例：多Agent协同撰写报告

graph TB
    A[研究员Agent] -->|提交初稿| B[共识池]
    C[数据分析Agent] -->|添加图表| B
    D[合规Agent] -->|法律审核| B
    B --> E{共识达成？}
    E -->|是| F[发布终稿]
    E -->|否| G[启动修改协议]

实用拜占庭容错（PBFT）：1/3节点故障仍可达成共识

2. 跨平台身份认证

Agent护照系统：

{
  "id": "agent://medical/diag-009",
  "issuer": "Huawei_A2A_Cert",
  "public_key": "0x23a7...",
  "scope": ["diagnosis", "report_gen"],
  "expiry": 1735689600
}

验证流程：
JWT签名校验 → 权限范围检查 → 时效验证

产业级应用场景

1. 智能制造：柔性产线调度

graph LR
    O[订单Agent] -->|需求指令| P[计划Agent]
    P --> M1[机床Agent]
    P --> M2[机械臂Agent]
    M1 -->|完工通知| Q[质检Agent]
    M2 --> Q
    Q -->|质量报告| S[仓储Agent]

效果：东莞某工厂部署后，换线时间缩短76%

2. 智慧城市：应急响应联盟

Agent类型	灾难响应动作	协同规则
交通Agent	封锁受损路段	优先保障救援通道
医疗Agent	调度救护车	根据伤情分级响应
电网Agent	切断危险区域供电	同步消防Agent行动

真实事件：杭州亚运会期间暴雨协同响应提速3倍

3. 金融交易：跨境支付网络

SWIFT替代方案：

def cross_border_payment(sender, receiver, amount):
    # 多Agent协同验证
    AML_Agent.check_suspicion(sender)          # 反洗钱审核
    FX_Agent.convert_currency(amount)          # 实时汇兑
    Settlement_Agent.execute(receiver)         # 链上清算

优势：传统3天流程压缩至8分钟，费用降低60%

技术哲学启示

当医疗Agent通过A2A协议向药物研发Agent发送{"action": "compound_design", "target": "EGFR_L858R"}时，人类目睹了机器文明的第一次贸易。A2A协议不仅是技术标准，更是智能体社会的“汉谟拉比法典”——它用代码定义权利边界，用算法建立信任机制，最终将催生硅基文明的生产关系革命。

7.AI Agent中的A2A和MCP的区别是什么？

MCP协议解决的是AI Agent和各种外部工具/资源之间的交互问题，可以看做是一个AI应用商店协议，主要关注单个AI Agent如何更好的使用外部工具。

而A2A协议解决的是AI Agent和AI Agent之间的交互问题，主要关注不同的AI Agent之间怎么协作的问题。

总的来说，它们是互补的，共同构建AI Agent的生态。

8.当前AI Agent中的主流核心大模型有哪些？

Rockyu总结了当前AI Agent中的主流核心大模型，随着AI Agent领域的不断发展，相信未来会有更多核心大模型出现，Rocky也会持续更新本问答：

claude-3.7/4-sonnet
DeepSeek-R1/V3
gemini-2.5系列
qwen2.5系列
未来会有更多的LLM大模型和AIGC多模态大模型可以作为AI Agent的核心大模型

9.AI Agent中的系统提示词有哪些作用？

在AI Agent架构中，系统提示词（System Prompt） 是AI Agent的核心控制中枢，其设计质量直接决定Agent的可靠性、安全性与执行效能。

系统提示词的四大核心作用

1. 角色定义与人格建模

# 法律顾问Agent示例
"""
身份：环球律所高级合伙人（执业15年）
专长领域：跨境并购、知识产权诉讼
语言风格：严谨专业，引用法条需标注出处
"""

效果：
- 约束模型自由发挥倾向，幻觉率降低40%
- 建立用户对Agent的专业信任感

2. 能力边界锁定

# 工具调用白名单
"""
可用工具：
  - contract_review：合同审查（输入PDF→输出风险报告）
  - clause_search：条款库检索（关键词→相似判例）
禁用行为：
  - 生成法律效力承诺
  - 解释未生效草案
"""

安全价值：
- 避免越权操作（如医疗Agent禁止诊断）
- 符合GDPR/网信办监管要求

3. 认知框架植入

任务类型	预设思维链
合同审查	主体校验→权责分析→违约条款评估
法律咨询	事实提取→法条匹配→解决方案生成

效能提升：
- 复杂任务处理速度提升3倍
- 结果可预测性达92%

4. 动态上下文管理

"""
记忆规则：
  - 保留核心实体（公司名/金额/时间节点）
  - 丢弃情绪化表述（用户抱怨等）
  - 持久化关键日期（合同截止日）
"""

技术创新：
- 在4K上下文窗口中实现10倍信息密度

10.在AI Agent中如何构建强大的系统提示词？

目前主流的AI Agent系统提示词需要遵循8个设计构建要点：

明确的目标、角色和范围：明确界定AI Agent的身份定位、核心功能及运作领域，能有效锚定其行为模式，设定用户预期，并防止功能范围的无序扩张或产生无意义的反馈。这相当于为AI Agent确立了身份标识与职责边界。
结构化的指令与任务分解：结构化的使用标题、列表、代码块或自定义标签，能帮助AI Agent的维护者清晰理解，也能协助AI Agent更精确地解析、区分不同规则或信息集的优先级，减少歧义。
明确工具集成与使用指南：对于AI Agent的行为，需要向AI Agent描述清楚：它们是什么，它们做什么，如何调用它们（语法、参数），所需的格式（例如XML、JSON），以及至关重要的是，何时不使用它们。这需要详细的描述、清晰的模式和明确的规则。
逐步推理、规划：复杂任务需要需要进行拆解。需要引导AI Agent有条理地思考、规划行动、迭代执行，并在进行下一个任务前，等待用户的反馈或结果，从而减少错误并提升连贯性。
环境和上下文：AI Agent会在各种特定环境（如操作系统、集成开发环境、浏览器沙箱、特定库）中运行。提供这些上下文信息能让AI Agent生成兼容的代码、使用合适的命令，以及理解环境的限制。
特定领域的专业知识和限制：需要告诉AI Agent需要处理的特定领域（如网页开发、数据分析等）。需要在提示词中加入领域专业知识、最佳实践、风格指南以及约束条件，以确保输出内容既高质量又符合上下文的需求。
安全、对齐、拒绝协议：负责任的AI Agent需要明确的界限。提示词需要界定负面的请求，并规定AI Agent应如何拒绝此类请求。也要确保如何正确安全地做事。
设定语气和互动风格：设定一致的角色定位（例如友善的专家、风趣的助手、直率的工程师）能打造更具可预测性和吸引力的用户体验。具体实施时，可从宽泛的指导原则延伸至非常细致的风格化指令。

11.System Prompt在AI Agent内部是如何生效的？

在AI Agent主流框架设计中，定义了三种核心消息类型：System Prompt（System Message）、Assistant Prompt（Assistant Message）和User Prompt（User Message），三者功能明确区分：

User Prompt：代表用户的直接输入的问题。
Assistant Prompt：代表大模型生成的回复内容。
System Prompt：用于设定大模型的角色、基础指令（如身份界定、安全约束）等核心配置。

那么，System Prompt是如何在AI Agent中生效的呢？

在AI Agent中，System Prompt主要起到静默提示的作用，通常被置于用户输入之前，与Assistant Prompt和User Prompt组合输入到大模型中。

System Prompt与User Prompt的关键区别在于其位置与优先级：System Prompt固定设置在输入文本序列的开端。由于注意力机制的特性（序列首尾信息通常更受关注），该位置的内容更容易被模型识别和遵循。因此，一个完整的多轮对话提示词（Prompts）通常按以下模式拼接：

System Prompt -> User Prompt -> Assistant Prompt -> User Prompt ... -> Assistant Prompt

在此结构中，Assistant Prompt的主要作用是向大模型展示历史对话记录，并明确标注其中哪些内容源于用户的输入。经过这种结构模式数据预训练和微调的大模型能够理解：这些并非即时用户输入，而是对话历史。这有助于大模型更好地把握上下文信息，从而更准确地回应后续问题。

那么，有读者可能会问，为何不将System Prompt与User Prompt合并呢？一个重要考量在于安全性和可控性。通过在微调阶段区分消息类型，有助于防御提示词注入（Prompt Injection）等攻击手段。具体来说：

将核心角色定义和规则置于System Prompt中。
用户交互内容则放在User Prompt里。

上述这种分离机制能有效防范某些简单的提示词攻击或信息泄露风险。特别是在实际应用中，System Prompt对用户通常是不可见的。其定义的规则和角色经过充分训练，因而在模型中享有最高优先级。这显著提高了大模型遵循开发者意图的可能性，降低了因用户输入变化导致输出偏离预期的风险。

当然，仅依赖System Prompt并不能完全抵御攻击（例如，GPT-4 曾出现过System Prompt被诱导泄露的案例）。因此，对用户输入或模型输出进行二次校验，是更为稳妥的安全增强方案。

接下来，Rocky举一个详细的例子，让大家更加通俗易懂的理解三种Prompt是如何拼接用户问题，并作为上下文输入给大模型的：

12.AI-Search和普通Search有什么区别？

AI-Search（智能搜索）与传统搜索（如关键词搜索）的核心区别在于是否具备语义理解、动态决策和主动推理能力。以下是深度对比分析：

一、本质区别

维度	传统搜索 (Traditional Search)	AI-Search (智能搜索)
技术基础	关键词匹配 + 倒排索引	大语言模型（LLM）+ 知识图谱 + 强化学习
交互方式	用户输入明确关键词 → 返回匹配结果	自然语言提问 → 理解意图 → 动态推理答案
输出形式	链接列表（需用户二次筛选）	结构化答案 + 多模态结果 + 溯源依据
目标	快速检索已有信息	解决问题（甚至执行动作）

二、核心能力差异

1. 语义理解 vs 字符匹配

传统搜索
- 依赖TF-IDF/BM25算法，匹配关键词出现频率。
- 示例：搜索 “苹果手机发热” → 返回含“苹果”“手机”“发热”的网页。
AI-Search
- 理解上下文和隐含需求（如“苹果”指品牌而非水果）。
- 示例：提问 “手机玩游戏发烫怎么办？” → 分析可能原因（CPU过载/散热不足）并给出解决方案。

2. 静态检索 vs 动态推理

传统搜索
- 仅聚合现有内容，无法组合信息。
- 局限：无法回答 “2025年诺贝尔文学奖得主的代表作与莫言风格对比”（需实时数据+文学分析）。
AI-Search
- 推理链（CoT）技术：拆解问题 → 检索证据 → 逻辑合成答案。
- 动态调用工具：联网查诺奖结果 → 提取作品特征 → 调用风格分析模型。

3. 单向响应 vs 任务执行

传统搜索
- 终点是提供信息（如展示机票价格）。
AI-Search
- 智能体（Agent）模式：
  - 理解 “订下周一北京到上海最便宜机票” → 自动比价 → 填写订单 → 支付（需授权）。
- 实现“搜索即服务”。

三、技术栈对比

层级	传统搜索	AI-Search
索引层	倒排索引 + PageRank	向量数据库（相似语义嵌入）
理解层	词干提取 + 同义词扩展	LLM微调（LoRA/P-Tuning）+ 知识图谱
执行层	无	Tool Calling（Python/API/插件）
优化机制	点击率（CTR）排序	RAG + 强化学习（PPO/DAPO）反馈优化

💡 关键创新：AI-Search 通过 RAG（检索增强生成） 将外部知识注入LLM，解决幻觉问题。

四、性能与局限

指标	传统搜索	AI-Search
响应速度	⭐⭐⭐⭐⭐（毫秒级）	⭐⭐（秒级，需推理）
复杂问题解决	⭐（仅基础检索）	⭐⭐⭐⭐⭐（跨域推理）
数据实时性	⭐⭐⭐（依赖爬虫频率）	⭐⭐⭐⭐（可联网检索）
结果可解释性	⭐⭐⭐（来源明确）	⭐⭐（黑盒推理需溯源）

AI-Search 当前挑战：

实时性瓶颈（推理延迟高）
复杂任务错误传播（如自动编码出错）
多跳推理稳定性不足（需人工校验）

13.什么是DeepSearch？

DeepSearch 的核心理念是通过在搜索、阅读和推理三个环节中不断循环往复，直到找到最优答案。搜索环节利用搜索引擎探索互联网，而阅读环节则专注于对特定网页进行详尽的分析（例如使用 Jina Reader）。推理环节则负责评估当前的状态，并决定是应该将原始问题拆解为更小的子问题，还是尝试其他的搜索策略。

与 2024 年的 RAG 系统不同，RAG 一般只运行一次搜索-生成过程，DeepSearch 执行多次迭代，需要明确的停止条件。这些条件可以是基于 token 使用限制，或者失败尝试的次数。

原理：从静态检索到动态推理

与传统搜索/RAG的本质区别

维度	传统搜索/RAG	DeepSearch	优势解析
触发机制	用户输入关键词后单次检索	AI主动识别知识缺口，动态发起多轮检索	解决复杂问题的信息碎片化问题
推理深度	无上下文推理能力	每轮检索后结合新信息迭代推理	实现多跳推理（Multi-hop）
内容整合	直接返回原始文档片段	阶段性精炼信息（Reason-in-Documents）	避免上下文超长导致的模型失效
响应目标	快速返回链接列表	生成精准结论或结构化报告	减少用户二次加工成本

换个角度来看，DeepSearch 可以被视作一个配备了各类网络工具（比如搜索引擎和网页阅读器）的 LLM Agent。这个 Agent 通过分析当前的观察结果以及过往的操作记录，来决定下一步的行动方向：是直接给出答案，还是继续在网络上探索。这就构建了一种状态机架构，其中 LLM 负责控制状态间的转换。在每一个决策点，你都有两种可选方案：你可以精心设计提示词，让标准的生成模型产生特定的操作指令；或者，也可以利用像 Deepseek-r1 这样专门的推理模型，来自然而然地推导出下一步应该采取的行动。然而，即使使用了 r1，你也需要定期中断它的生成过程，将工具的输出结果（比如搜索结果、网页内容）注入到上下文之中，并提示它继续完成推理过程。

归根结底，这些都只是实现细节而已。无论你是精心设计提示词，还是直接使用推理模型，它们都遵循 DeepSearch 的核心设计原则：搜索、阅读和推理的持续循环。

14.AI Agent和AI Workflow的区别在哪里？

Rocky认为，AI Agent是AI Workflow的进化版，AI Agent和AI Workflow在广义上都可以称为Agent。

只是AI Workflow的运行过程都是已经预定义设计好的，而AI Agent则能在运行时进行自主决策。

在AIGC时代，AI Agent概念非常火爆，我们在判断一个系统到底是哪一类时，主要看它能不能在运行过程中进行动态决策，而不是看System Prompt等提示词写得多长。

维度	AI Agent	AI Workflow
本质	具有自主决策能力的智能实体	预设步骤的任务自动化流程
类比	有思考能力的"员工"	工厂的"流水线"
决策时间	设计阶段	运行阶段
决策权	自主决策	按预设规则执行
可复现性	稳定可复现	需要实时记录行动log
运行成本	可精确估算	存在波动性

但是并不是说AI Agent一定会比AI Workflow效果好，我们还需要根据实际应用场景选择合适的AIGC算法解决方案。

总的来说，很多ToB场景大多是带有明确需求且要求稳定可控的，这时自主决策的AI Agent在可控性上不一定比AI Workflow好。

但AI Workflow只能在预设的明确固定任务上执行，而AI Agent则可以在更开放和不确定的任务上进行创造性执行。

随着AIGC时代的持续发展，AI Agent系统更有可能采用Agent+Workflow的混合架构，AI Agent 是"思考者"，解决做什么(What)的问题；AI Workflow则是"执行者"，解决怎么做(How)的问题。

所以两者并不存在高低之分，黑猫白猫，只要在适当的场景中抓到耗子，那就是好猫。

15.在AI Agent中，function call如何把外部工具变成大模型可以理解的方式？

将外部工具转化为大模型可理解方式的核心机制：接口描述标准化与执行逻辑衔接

实现LLM/AIGC大模型理解并调用外部工具、插件或API的核心，在于建立一套标准化的接口描述机制，并构建一个可靠的执行桥梁。该过程包含两个关键环节：

接口描述标准化 (Standardized Interface Description):
- 定义结构化描述 (Schema): 为每个工具设计一个符合特定调用格式（常用如 JSON/XML Schema）的结构化接口定义。该 Schema 必须清晰包含以下要素：
  - 唯一标识符 (Unique Name): 用于模型精确识别所需调用的外部工具。
  - 功能说明书 (Functional Description): 以自然、准确、无歧义的语言详细阐述工具的核心作用、所需输入参数、预期输出结果以及适用场景。这是大模型理解外部工具功能并匹配用户意图的关键依据。 避免使用过于技术化或模糊的术语。
  - 参数规格 (Parameter Specification): 明确列出工具运行所需的每一个参数项，包括参数名称、数据类型、是否强制要求（必需性）以及具体的参数含义说明。
执行逻辑衔接 (Execution Bridging):
- 向大模型提供工具目录 (Providing Tool Directory to LLM Model): 在每次模型交互时，将当前所有可用工具的标准化描述作为上下文信息，整合到提示词信息（Prompt）的特定部分传递给大模型。
- 解析模型调用指令 (Parsing Model Output): 应用程序持续监听模型的输出响应。一旦检测到符合预定义格式（如特定 JSON/XML 结构）的函数调用指令（Function Call），立即进行解析。
- 定位并执行目标工具 (Invoking the Actual Tool): 根据解析出的工具标识符（Name），定位到对应的外部工具/插件/API实现。
- 参数映射与校验 (Parameter Mapping & Validation): 从调用指令的参数列表（Arguments）中提取参数值，执行必要的类型转换和有效性校验，最终调用实际工具的接口。
- 获取与处理执行结果 (Result Handling): 捕获工具执行后返回的结果（无论是成功响应还是错误信息）。
- 结果反馈闭环 (Feeding Back Results to Model): 将工具执行的结果格式化为文本信息，再次输入给大模型。这使得大模型能够基于该结果信息继续生成后续回复或决定下一步操作（如调用其他工具）。

本质概括： 该机制的核心是为每个外部工具创建一份清晰易懂的“自然语言说明书”（即 Schema/描述），使模型能够理解其功能。同时，建立一个“翻译与执行层”，负责将大模型依据说明书生成的“操作指令”（JSON/XML Call）翻译并转化为对实际工具的具体调用动作，并将工具的“操作结果报告”翻译回大模型能够处理的信息。

注： MCP（Model Control Plane）的核心功能即在于实现上述的接口标准化描述与执行逻辑衔接。

16.在AI Agent中，大模型如何学习到Function Calling能力？

Function Calling能力不是LLM/AIGC大模型原生具备的，我们该如何让LLM/AIGC大模型学习到Function Calling能力呢？

当前AI业界主流的方法是通过监督微调（Supervised Fine-tuning, SFT）来实现LLM/AIGC大模型对Function Calling能力的学习，而不是在预训练阶段从零开始专门训练。当前AI业界具备Function Calling能力的大模型包括DeepSeek、GPT-4o、Claude、Qwen、Gemini等。

同时在微调训练前，LLM/AIGC基础大模型需要先具备良好的指令遵循和代码/结构化数据生成能力。

Function Calling能力微调训练的核心思想：

获取识别意图（Intent Recognition）能力：理解用户的请求是否需要借助外部工具/函数来完成，而不是直接生成文本回答。
获取参数提取与格式化（Argument Extraction & Formatting）能力：如果需要调用函数，正确地从用户请求中抽取出所需的参数，并按照预先定义的格式（JSON、XML等）生成函数调用的指令。

接下来，我们再梳理一下Function Calling的微调过程：

1.数据集制作：可以说数据集整理是整个微调过程最重要的一步，因为我们需要构建一个包含Function Calling场景的指令微调数据集，让基础大模型能够充分的学习参数与格式化内容。每个数据样本通常包含以下内容：

用户输入（Input/Query）：一个用户请求，可以是包含调用函数的内容，也可以是不包含调用函数的内容。比如：“查询今天腾讯股票的涨跌幅？”或者“给我写一首大气磅薄的诗词”。 可用函数/工具描述（Available Functions/Tools Description）：一个结构化的描述，告知大模型当前有哪些函数可用，每个函数的用途、所需参数及其类型和描述。这个描述本身通常就是文本，需要设计一种清晰的格式（JSON、XML等）。 期望的输出（Desired Output）：（1）如果需要调用函数：一个特定格式的字符串，通常是包含函数名和提取出的参数的JSON、XML对象。（2）如果不需要调用函数：大模型直接生成文本回答。例如：“好的，我写了一首大气磅薄的诗词：...” 数据集整体质量要求：（1）数据多样性：需要足够多、覆盖各种场景（需要/不需要调用Function、调用不同Function、Function参数变化、模糊表达等）的高质量数据。（2）函数描述的清晰度：函数描述的质量直接影响模型能否正确理解和使用函数。（3）负样本：需要包含足够多明确不需要调用Function的样本，防止模型“过度触发”Function调用。

下面是Function参数结构化格式的样例：

{
  "name": "get_stock_change",
  "arguments": {
    "stock_name": "腾讯股票",
  }
}

下面是数据集格式的样例：

{
    "conversations": [
        {
            "from": "human",
            "value": "帮我查询一下今天股票的涨跌幅情况?"
        },
        {
            "from": "gpt",
            "value": "当然，我可以帮忙，请问你对哪只股票感情兴趣?"
        },
        {
            "from": "human",
            "value": "腾讯股票"
        },
        {
            "from": "gpt",
            "value": "{\n\"function\": \"get_stock_change\",\n\"arguments\": {\n\"stock_name\": \"腾讯股票\"\n}\n}"
        }
    ]
}

2.选择基础模型：选择一个具备强大指令遵循能力的预训练LLM/AIGC大模型(例如DeepSeek等)。

3.格式化训练数据：将每条数据样本组合成大模型可以理解的格式。通常是将数据集中的“用户输入”和“可用函数/工具描述”拼接起来作为模型的输入(Prompt)，将“期望的输出”（无论是JSON、XML函数调用还是文本回答）作为目标输出(Completion/Target/Label)。需要使用特定的分隔符或模板来区分不同部分。

4.进行微调训练：使用标准的SFT方法（全参数微调或训练LoRA）在特定数据集上进行微调训练。大模型的优化目标是最小化预测输出和期望输出之间的差异（例如使用交叉熵损失）。大模型通过学习这些样本，学会根据用户输入和可用函数描述，决定是直接回答还是生成特定格式的函数调用JSON、XML。

经过上述的微调训练流程，我们就能获得具备Function Calling能力的LLM/AIGC大模型了。

17.当前AI Agent有哪些局限性？

AI Agent的幻觉问题（Hallucination）：AI Agent中的核心LLM/AIGC大模型可能会生成不准确的信息。
上下文长度与规划缺陷：LLM/AIGC大模型的上下文窗口有限，导致AI Agent难以处理长期任务规划和自我反思。
多模态处理能力不成熟：不管是B端还是C端场景，很多需求都要处理图像、文本、视频、音频等异构数据，但多数AI Agent仍以文本这个单一模态为主。
行业适配困难：企业级场景要求“零失误”，但通用AI Agent容错率高，难以满足医疗、金融等高风险领域需求。垂直行业业务逻辑复杂，需深度绑定数据与流程。
计算成本仍然较高：AI Agent的运行推理过程仍然会消耗大量计算资源。

18.当前AI Agent有哪些主流的评价指标？

任务成攻率（Task Completion Rate）：层级化任务完成率，过程轨迹精确度，长周期策略稳定性等。
工具调用准确率（Tool Usage Accuracy）
推理质量（Reasoning Quality）
用户满意度（User Satisfaction）

19.AI Agent如何具备长期记忆能力？

要让AI Agent具备长期记忆能力，需要解决LLM/AIGC大模型固有的“上下文窗口限制”和“无状态缺陷”。

具备长期记忆的AI Agent需采用“分层存储+智能检索”架构，核心是通过 向量化、摘要压缩、混合数据库 打破上下文窗口限制。

🔧 一、长期记忆的架构设计

分层记忆系统
AI Agent 的记忆需模拟人脑结构，分为三层协同工作：
- 短期记忆（STM）：通过上下文窗口（如 Transformer 的 Token 限制）维持当前对话连贯性，但容量有限（通常 4K-128K Token）。
- 中期记忆（MTM）：将对话关键信息压缩为摘要或嵌入向量，存储于向量数据库（如 FAISS、Pinecone），支持语义检索。
- 长期记忆（LTM）：持久化存储用户画像、行为习惯等结构化数据，使用 SQL/NoSQL 数据库或知识图谱实现跨会话记忆。
混合存储引擎
- 向量数据库：处理非结构化文本的相似性搜索（如用户偏好“喜欢科幻电影”）。
- 时序数据库：记录事件链（如“用户上周询问过机票价格”）。
- 图数据库：构建知识关联网络（如“用户A是程序员→可能关注算法更新”）。

⚙️ 二、关键实现技术

记忆生成与压缩
- 摘要提炼（Summarization）：
  每次对话结束后，用专用 LLM 生成摘要（例：双 LLM 架构中分离对话与总结模型）。
- 嵌入向量化（Embedding）：
  通过 BERT 或 OpenAI Embeddings 将文本转为向量，便于高效检索。
记忆检索与更新
- 多模态检索：结合语义搜索（向量相似度）+ 时间过滤（最近事件优先）+ 规则筛选（如重要度评分）。
- 冲突消解：当新旧记忆矛盾时（如用户口味变化），由 LLM 裁决或设置衰减权重。

记忆集成至 Agent
将检索结果动态注入 Prompt：

# Mem0 API 示例：添加和搜索记忆
m.add(user_query, user_id="Alice")  # 存储记忆
related_memories = m.search("推荐电影", user_id="Alice")  # 检索相关记忆
prompt = f"User's historical preferences: {related_memories}. Current query: {new_query}"
response = llm.generate(prompt)

FilesExpand file tree

AI Agent基础知识.md

Latest commit

History