CONTENT

Functional Calling坑点System promptMCPAI Agent搭建的框架ToolsAgent步骤优化

Functional Calling

1. Agent和LLM的通信方式

2. 背景：避免开源的AIAgent如AUTO Agent一样，得到的LLM输出不规范，还得反复重试，前沿AI大厂推出的规范：统一格式，规范描述

3. 如：每个工具tool都用一个json对象来定义；从“system prompt”中抽离出来，作为单独的字段

4. 自校自检验机制受益于json格式的规范化，能够内嵌在LLM提供商服务器中完成自校，降低开发端检验和反复重试的token开销和时间成本，几乎没有感知

坑点

1. Functional Calling虽然每家大厂都有，但其格式规范只是内部规范，相互之间并不统一

2. FC，System prompt和user prompt只是发给LLM输入的不同字段，本质都是Prompt，所以FC只是从sypt中抽离的，而很多开源的Agent框架还是在用基本的sypt作为整体去输入给LLM的，两种形式是并存的现在

3. 所以在写通用的，跨大模型的Agent时，要注意FC的格式，要加入在不同LLM之间转换的节点。

System prompt

MCP

1. Agent（MCP Client）和Tool（MCP Server）之间的通信协议，用于Agent扮演MCP Client的角色，调用打包好统一接口并托管在MCP Server上的Tool

2. 简单的调用方式：把Agent和Tool写到一个程序里，功能的实现就靠函数直接调用

3. MCP提供
1. Tool工具
2. resources文件读写
3. prompt模板

4. client和server可以在同一台服务器环境内本地交互通信；也可以通过http进行通信

5. 因为是agent和tool之间的通信协议，与LLM无关。可能在实际应用中要注意跟LLM的兼容性和优化空间。

AI Agent搭建的框架

Tools

1. 文件

2. 本地的功能函数，用于给agent调用，使LLM能“阅读”这些函数文件
1. 函数名和参数最好以功能直接命名，清晰，方便LLM理解
2. 返回值和参数类型，加上类型标注，方便LLM理解
3. 太长的话，写docstring，方便LLM理解

本质上是给AI提供API和API说明文档

Agent

1. 示例构建代码：
ref
ref_deepseek_fromcomment

2. 框架（库）选择：PydanticAI

3. 模型选择：Gemini

步骤

1. 模型：创建代表Gemini模型的实例，GeminiModel
1. API最好创建为环境变量，安全，方便修改
2. 可以写到.env文件中，然后在主函数中，用python-dotenv的load函数进行加载即可
3. 当然：提交git时，.env文件不能一起提交hh，得ignore掉

2. Agent：创建生成agent对象
1. 上面的model是agent的第一个函数
2. system prompt是第二个函数
3. tools（先从函数前声明处注册进来）是第三个函数
ref

3. 主程序：
1. 通过标准输入接受用户指令
2. 通过run_sync函数传给Agent
3. 打印返回结果

agent默认不记忆上下文，每一次run_sync都是独立的，问一次读一次

 
 

优化