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 真的搞不定，再拆角色——这是省钱的铁律。 ...

硅基速览 9月10日，OpenAI Agents API进入公开测试阶段，提供托管式Codex harness。 核心能力：沙箱环境、上下文压缩、并行子Agent、MCP协议支持、可恢复会话。 与Claude Code（终端Agent）和Cursor Projects（多Agent工作区）形成2026年9月Agent开发框架的三足鼎立。 正文 OpenAI补齐Agent拼图 2026年9月10日，OpenAI的Agents API进入公开测试（Public Beta）。根据andrew.ooo在9月14日发布的对比文章，这个API的定位是"托管式Codex harness"——你不需要自己搭建Agent运行环境，OpenAI帮你托管好。 在Agents API之前，OpenAI的Agent能力分散在多个产品里：Codex CLI（终端编程Agent）、GPT Store（自定义Gpts）、Assistants API（基础对话Agent）。但这些产品要么需要你自己搭建运行环境，要么能力有限。Agents API第一次把所有Agent能力整合到一个托管平台上。 核心组件包括： 沙箱环境（Sandboxes）。 每个Agent任务都在一个隔离的容器中运行，有独立的文件系统、网络访问权限和计算资源。Agent可以在沙箱里执行代码、调用工具、访问API，但不会影响到你的生产环境。 上下文压缩（Compaction）。 长任务运行过程中，Agent的上下文窗口会不断增长。Agents API自动进行上下文压缩——把早期的对话历史和工具调用结果总结成摘要，释放上下文空间，让Agent可以处理长达数小时的任务而不超出token限制。 并行子Agent（Parallel Subagents）。 主Agent可以派生多个子Agent并行执行不同子任务。比如主Agent需要"分析这个代码库"，它可以派一个子Agent读前端代码、一个读后端代码、一个读配置文件，然后汇总结果。这比单个Agent串行处理快3-5倍。 MCP协议支持。 Model Context Protocol是Anthropic发起的开放协议，现在已成为Agent连接外部工具的事实标准。OpenAI在Agents API中支持MCP，意味着你可以用任何兼容MCP的工具服务器（数据库、文件系统、浏览器、GitHub等）直接接入Agent。 可恢复会话（Resumable Sessions）。 Agent执行长任务时如果中断（网络问题、超时、错误），会话状态会被持久化，可以从中断点恢复，不需要从头再来。 与Claude Code和Cursor Projects的对比 到2026年9月，Agent开发框架已经形成三足鼎立格局： 维度 OpenAI Agents API Claude Code Cursor Projects 定位 托管式Agent后端 终端编程Agent IDE内多Agent工作区 状态 Public Beta（9月10日） GA（Fable 5.1接入） Beta（9月10日全量推送） 核心场景 API集成、企业工作流 终端软件开发 团队协作编程 子Agent 并行云端子Agent 子Agent+Hooks 协调Agent+云端子Agent MCP支持 支持 支持 通过IDE插件 会话恢复 原生支持 通过Cowork 通过共享上下文 三者的定位差异很清晰：OpenAI Agents API面向"后端开发者"——你在自己的应用里嵌入Agent能力，OpenAI帮你托管运行环境；Claude Code面向"个人开发者"——你在终端里直接与Agent结对编程；Cursor Projects面向"团队协作"——多个人+多个Agent在一个共享工作区里协作开发。 ...

Agent平台的"三层打通"打法 2026年9月，腾讯WorkBuddy开放平台正式上线。这个平台在Agent赛道上的定位很特别：它不是又一个Agent开发框架，也不是又一个Agent商店，而是国内第一个同时把硬件、应用、开发者三层全部打通的Agent开放平台。首批已经有超过100家生态伙伴接入，覆盖30多个品牌的硬件，以及金融、法律等20多个行业领域。 为什么要分"三层" AI Agent生态在2026年已经分化出三个层次： 硬件层：Agent最终要跑在某个物理终端上——手机、PC、会议屏、汽车、机器人、音箱。没有硬件入口，Agent就是飘在云端的对话窗口。 应用层：Agent要调用真实业务系统——企业的CRM、OA、银行核心系统、律所案卷系统。没有应用接入，Agent只能聊天不能干活。 开发者层：Agent能力要靠开发者按场景组装——金融客服Agent、法律合同审查Agent、运维监控Agent。没有开发者，平台就没有供给。 过去各家做Agent平台，大多只打通其中一层：华为做硬件生态，钉钉做应用集成，LangChain做开发者框架。腾讯WorkBuddy这次的差异化在于，它用一个开放平台把这三层捏合在一起。 层级 WorkBuddy接入情况 硬件层 30余品牌硬件接入 应用层 覆盖金融、法律等20+领域 开发者层 首批超百家生态伙伴 三层打通的真正价值 三层打通听起来像公关话术，但它解决了一个真实痛点：过去一个企业要上线一个"会议Agent"，硬件要找会议屏厂商谈协议，应用要找OA厂商谈接口，开发者要自己写逻辑，三方之间还要对权限、对账号、对数据。WorkBuddy把这三层都放到同一个开放平台后，硬件厂商的设备天然支持Agent唤醒，应用厂商的业务API天然暴露给Agent，开发者只需要写业务逻辑就能把三方串起来。 对金融行业，这意味着一个银行员工在会议屏上说"帮我查一下今天对公客户的逾期情况"，WorkBuddy Agent能直接调银行核心应用，不用切换系统。对法律行业，律师在PC上让Agent审阅合同，Agent能调用律所的案卷管理系统。 百家生态伙伴的信号 首批超百家生态伙伴，这个数字在国内Agent平台上线初期算是相当扎实的。它说明腾讯不是自己闭门造车做一个Demo，而是拉着一批硬件厂商、ISV（独立软件开发商）、行业解决方案商一起把生态填满。30余品牌硬件的接入，尤其说明腾讯在用微信/企微系的渠道能力去撬动硬件厂商——这是其他纯软件Agent平台很难复制的资源。 行业影响 WorkBuddy的推出，标志着国内Agent竞争从"谁的模型强"进入到"谁的生态厚"的阶段。模型能力在2026年已经趋同，真正决定企业采用率的是：Agent能不能触达我的设备、能不能调用我的系统、有没有现成的行业模板。腾讯用微信系的硬件关系、企业微信的应用关系、加上腾讯云的开发者关系，把这三件事一次做齐了。 对开发者来说，WorkBuddy开放平台意味着做一个Agent不需要再从零对接硬件协议和企业应用，平台已经把最难的"最后一公里"做完了。未来一年，国内Agent生态的竞争，很可能就是腾讯WorkBuddy、字节扣子、阿里百炼三家在"三层打通"上的正面较量。 对中小开发者的现实意义 对中小开发者和ISV来说，WorkBuddy开放平台真正的价值在于"默认信任"。过去做一个行业Agent，要自己去和硬件厂商谈设备权限、和企业谈数据接口、和客户谈安全合规，每一步都是销售成本。接入WorkBuddy之后，平台已经把硬件驱动、应用API、身份认证这层脚手架搭好，开发者只需要聚焦行业Know-how——比如金融场景的风控逻辑、法律场景的合同条款解析。这种"脚手架由平台出、Know-how由开发者出"的分工，正是平台型生态能跑起来的关键。 当然，三层打通也带来新的风险：当Agent同时握有硬件入口和企业应用权限，一旦某个环节被注入攻击或越权调用，影响面会从单个应用扩散到整个生态。WorkBuddy在开放平台上线同时，必须把权限最小化、调用审计、数据隔离这三件事做扎实，否则"三层打通"反而会变成"三层放大"。这也是接下来一年所有Agent平台必须回答的问题。 guijiagi.com 会持续跟踪WorkBuddy、扣子、百炼三大Agent平台在生态伙伴数量和行业落地上的进展。

开源Agent框架的"体验革命" 2026年8月31日，开源AI Agent框架OpenClaw发布了2.0版本。和很多"加功能"的大版本不同，OpenClaw 2.0的主线不是堆新能力，而是把过去一年被开发者吐槽最多的体验问题一次性解决：安装流程重做、浏览器端Control UI重构为chat-first、启动时间降到575毫秒、会话存储迁入SQLite、新增共享云会话。 575毫秒启动意味着什么 575毫秒这个数字，在一个动辄启动要十几秒、甚至几十秒的Agent框架里是什么概念？大部分开源Agent框架（包括早期的OpenClaw），启动过程要加载插件、初始化模型连接、恢复上下文、扫描工具目录，光冷启动就要好几秒。对一个开发者来说，每次改一行代码都要等几秒才能看到效果，迭代体验非常差。 OpenClaw 2.0把冷启动压到575毫秒，背后是启动路径的重构：把插件加载从同步改为按需、把模型连接从启动时建改为首次调用时建、把工具扫描从全量扫描改为增量缓存。这些工程优化单独看都不大，但叠加起来让Agent框架从"启动一次等半天"变成了"改完即见"的工具手感。 升级项 OpenClaw 1.x OpenClaw 2.0 安装流程 步骤繁琐 重做，一键化 控制界面 传统控制面板 chat-first聊天式 冷启动时间 数秒~数十秒 575毫秒 会话存储 文件/数据库混用 SQLite统一 云会话 不支持 新增共享云会话 chat-first控制界面 浏览器端Control UI从传统的"面板+表单"重构为chat-first（聊天优先），这是2026年Agent工具界面设计的主流方向。过去开发者要配置一个Agent，得在一堆表单里填模型、工具、权限、提示词；现在直接在一个聊天窗口里用自然语言说"帮我建一个能读代码、能跑测试的Agent"，框架自己把配置填好。 这背后的思路转变是：Agent框架的用户，越来越不想学框架语法，而是想用自然语言驱动框架本身。chat-first UI本质上是让"用Agent"和"配置Agent"变成同一件事。 会话迁入SQLite 把会话存储统一迁入SQLite，是一个看似不起眼、实则解决大问题的改动。早期版本的OpenClaw会话散落在文件系统里，备份、迁移、跨设备同步都很麻烦。SQLite是一个单文件数据库，所有会话、历史、工具调用记录都在一个.db文件里，备份就是复制文件，跨设备同步就是把这个文件丢到云盘。这和Obsidian笔记、Logseq的思路一致——用SQLite作为本地状态的唯一真相源。 新增的"共享云会话"则把这套本地SQLite能力延伸到了云端：开发者可以把本地Agent会话分享给同事，多人在同一个会话里接力调试，这对团队协作场景非常实用。 行业影响 OpenClaw 2.0的意义不在于它比其他框架"功能多"，而在于它证明了开源Agent框架在2026年已经进入"体验内卷"阶段。过去拼的是模型接入数量、工具数量、MCP支持；现在拼的是谁启动更快、谁界面更顺手、谁会话管理更优雅。 这和当年Python从"能跑"到"好用"、Node.js从"事件驱动"到"npm生态"的演进逻辑一样：框架竞争到最后，拼的是开发者日常工作流的顺滑程度。575毫秒启动、chat-first界面、SQLite会话，这三件事加在一起，让OpenClaw 2.0在开源Agent框架里的开发者体验上了一个台阶。 对企业用户来说，开源Agent框架在2026年的成熟度已经足够支撑生产级部署，OpenClaw 2.0这次的升级，正好踩在"从玩具到工具"的临界点上。 guijiagi.com 会持续跟踪OpenClaw、LangGraph、CrewAI等开源Agent框架在2.0时代的体验竞争。