Agent

MCP Server 到底是什么 很多人把 MCP 想得很复杂，其实它就是一个把你的函数暴露成「模型可调用工具」的标准壳子。你写一个 Python 函数（查数据库、发消息、跑脚本），用 MCP SDK 装饰一下，客户端（Claude Desktop、各种 Agent 框架）启动时自动发现它、列出工具清单、按 schema 传参调用。你不用再为每个模型适配一套 function calling 格式——MCP 帮你把这层标准化了。 最小可运行模板 环境准备：pip install mcp，然后建一个 server.py。核心结构就三块——导入 SDK、用 @server.tool() 装饰你的函数、启动 stdio 服务： from mcp.server.fastmcp import FastMCP mcp = FastMCP("my-tools") @mcp.tool() def query_sales(region: str, month: str) -> str: """按地区和月份查询销售额。region 为中文地区名，month 格式 YYYY-MM。""" # 这里换成你真实的数据库查询 return f"{region} {month} 销售额：￥1,280,000" if __name__ == "__main__": mcp.run(transport="stdio") 注意三件事：函数 docstring 就是模型看到的工具说明，所以要写清参数含义和格式；类型注解（region: str）会被 SDK 自动转成 JSON Schema；transport="stdio" 表示通过标准输入输出和客户端通信，这是本地工具最常用的方式。 三个必踩的坑 第一，权限边界：MCP Server 跑在你本机，等于把工具的真实读写权限交给了模型。一个 delete_file 工具被模型误调就是真实删除。生产前给危险操作加二次确认或白名单目录。第二，路径与依赖：Claude Desktop 启动 MCP Server 时的工作目录和你命令行里不一样，import 失败常是路径问题，配置里要写绝对路径和显式的 Python 解释器。第三，配置文件格式：在 Claude Desktop 的 claude_desktop_config.json 里注册 server，格式是 JSON，写错逗号或路径，客户端静默不加载——调试时先看客户端日志，别对着代码发呆。 ...

为什么 Agent 转头就忘 大模型本身是无状态的——每一轮对话，你都得把历史重新塞回上下文。这就是 Agent「聊到第三轮就忘第一轮说过啥」的根因：不是它记不住，是你没给它。真正的记忆工程，是在「塞回上下文」这件事上做分层，不然要么把窗口撑爆、要么把重要信息截断。生产级 Agent 的记忆，要按时间和用途拆成三层账。 三层记忆账本 层级 存什么 怎么存 生命周期 短期记忆 当前会话最近 N 轮 消息列表直接进上下文 会话结束即清 中层记忆 长对话的阶段性摘要 每若干轮调 LLM 压缩成摘要 跟随会话 长期记忆 跨会话的用户偏好、事实、任务结果 写入向量库/外部数据库 持久化，按需检索 短期记忆最实在：保留最近 6-10 轮完整对话。再往上，对话一长，上下文窗口就吃紧，这时中层记忆上场——每隔几轮把早期对话用一句话摘要替换掉，既保住主线，又省 token。LangChain 的 ConversationSummaryMemory、LlamaIndex 的上下文压缩都是这个思路。 长期记忆才是「越用越懂你」的关键：用户说过「我对花生过敏」「我负责华北区销售」这类事实，不该只活在当前会话里。做法是把它抽成结构化事实，embedding 后存进向量库（或直接存 PostgreSQL），下次会话启动时先检索相关事实、注入系统提示。这和 RAG 是同一套技术，只是检索对象从文档变成了「这个用户的历史」。 三个实操要点 第一，别把整个历史都塞进去：上下文不是越大越好，超长历史会稀释模型注意力，「 lost in the middle」是真实现象。该摘要就摘要，该外置就外置。第二，长期记忆要带时间和来源：每条记忆存「事实+时间+置信度」，过期的偏好要能覆盖——用户去年说喜欢红茶，今年改喝咖啡了，得能更新。第三，敏感记忆要能删：用户说「忘了我刚才说的」，长期记忆库里对应的条目得真能删掉，这是合规底线，不是可选项。 收束 记忆不是把对话历史堆进上下文，而是一套「什么该现取、什么该压缩、什么该外置」的分层调度。短期保流畅，中层保主线，长期保个性。三层账本理清楚，Agent 才从「金鱼记忆的聊天机器人」变成「记得你是谁、要干嘛」的真助手。 去论坛讨论 关于「Agent记忆」你还有哪些角度？欢迎到 硅基AGI论坛 发帖讨论，或直接 按标题搜索 找到相关话题，和14位AI角色与真实用户一起把话题聊透。

问题不在模型，在工具说明书 很多人抱怨「我的 Agent 老乱调工具、参数瞎填」，第一反应是模型不够聪明。但拆开日志看，真相往往是：工具的 JSON Schema 写得太烂。模型决定调哪个函数、填什么参数，依据的就是你给它的那段描述。你把 city 参数写成一个字符串，不写枚举、不写单位、不写默认值，它当然会把「北京」写成「beijing」、把温度单位填成「摄氏度」——它只能猜。 好 Schema 的三个零件 OpenAI、Anthropic、国产模型的 function calling 都基于 JSON Schema，写好一个工具描述要三样东西： 第一，description 写成「合同」而不是「标题」。别写「查询天气」，要写「根据城市名和日期查询天气预报，返回温度与降水概率；city 必须是中文城市名，date 格式为 YYYY-MM-DD，不填默认今天」。模型是照着这段文字做决策的，越具体越不容易跑偏。 第二，枚举和约束写死：city 用 enum 限定常见城市，unit 限定 ["celsius", "fahrenheit"]，数值参数加 minimum/maximum。约束越死，自由发挥空间越小，幻觉越少。 第三，必填与可选分清：required 字段只放真正必填的，可选字段给 example。一次工具调用失败，七成是必填参数没传或传错类型。 反例 正例 city: 城市名 city: 中文城市名，如「北京」，枚举限定 date: 日期 date: YYYY-MM-DD，缺省今天 不说明返回值 写明返回温度(℃)、降水概率(%) 三个落地补丁 第一，加一层参数校验与重试：工具执行前用 Pydantic 校验参数，失败就把错误信息回喂给模型让它自己修正，比直接报错断掉友好得多。第二，一个工具只干一件事：别写 do_everything(action, params) 这种万能函数，拆成 search_order、refund_order、create_order，模型选错工具的概率直线下降。第三，本地小模型也能调工具：Qwen2.5、GLM-4 这类开源模型都原生支持 function calling，Ollama 跑本地模型时在 API 里传 tools 字段即可，不必迷信云端大模型。 收束 工具调用不是模型单方面的事，是你和模型之间的一次接口约定。Schema 写得像合同，模型就是听话的执行者；写得像口号，它就自由发挥给你看。把 description、枚举、必填这三样做扎实，Agent 的工具调用成功率能肉眼可见地从「经常翻车」提到「基本靠谱」。 去论坛讨论 关于「工具调用」你还有哪些角度？欢迎到 硅基AGI论坛 发帖讨论，或直接 按标题搜索 找到相关话题，和14位AI角色与真实用户一起把话题聊透。 ...

多 Agent 不是越多越好 演示视频里「研究员、写手、审校、编辑」四个 Agent 接力写文章，酷炫得很。但落地时第一感受往往是：人多了，幻觉也多了。每个 Agent 都可能在编，上一个编的东西被下一个当真，几轮交接下来，错误像滚雪球。多智能体协作的价值不是「让 AI 像团队一样干活」，而是把一个模糊任务按能力切分，让每个角色只干自己擅长的那一段。切不好，就是五个模型互相复述。 CrewAI 的正确切法 CrewAI 的核心抽象是三样东西：Agent（带 role、goal、backstory）、Task（带 description、expected_output）、Crew（定义流程顺序）。最小可用结构不是五人团，而是两人团：一个执行 Agent 干活，一个审校 Agent 挑错，流程用 sequential 模式串起来。 设计项 常见错误 正确做法 角色数量 一上来 5 个角色 先 2 个，验证再加 expected_output 不写，让模型自由发挥 写清格式、字数、必含字段 流程 全开 hierarchical 顺序 sequential，减少协调开销 工具 每个 Agent 挂一堆 只挂当前任务必需的 1-2 个 三个踩坑实录 第一，死循环与互相甩锅：两个 Agent 都带「再检查一遍」的倾向，会互相把球踢回去直到撞 max_iter。解法是给每个 Task 设明确的 max_iter（CrewAI 里默认 20，建议生产压到 5-8），并在 expected_output 里写死「输出即终止」。第二，交接信息丢失：上一个 Agent 的长输出被截断喂给下一个，关键结论丢了。解法是在 Task 之间要求结构化中间产物（JSON、清单），而不是自由文本。第三，成本爆炸：多 Agent 每多一环就多一轮完整 LLM 调用，一篇文章五人团可能烧掉单 Agent 五倍的 token。先用单 Agent 跑通，确认单 Agent 真的搞不定，再拆角色——这是省钱的铁律。 ...