大家怎么看多 Agent 协作?
最近"多 Agent 协作"的概念很火,什么规划 Agent、执行 Agent、审查 Agent 串起来。我试搭过一个小 demo,体感是:demo 很炫,真用起来协调成本很高。 最大的问题是 Agent 之间传上下文容易丢信息,一个 Agent 的输出喂给下一个,细节经常被压缩
AI Agent、MCP、工具调用、多 Agent 协作
本专题收录 Agent 工程 方向的文章和社区讨论,重点关注真实工程场景、工具选择、实践路径和风险边界。
页面会持续更新,适合作为学习路线、选型参考和技术复盘入口。
最近"多 Agent 协作"的概念很火,什么规划 Agent、执行 Agent、审查 Agent 串起来。我试搭过一个小 demo,体感是:demo 很炫,真用起来协调成本很高。 最大的问题是 Agent 之间传上下文容易丢信息,一个 Agent 的输出喂给下一个,细节经常被压缩
半年前我看 MCP 的时候,能用的 server 屈指可数,文档也少。现在回头看,官方 registry 里像样的 server 上百个,主流 IDE 全适配,社区工具也跟上了。 最直观的是接数据库、接浏览器、接 SaaS 这些都不用自己写了,现成的 server 装上就能用。A
去年折腾过一阵子完全自主的 Agent,给它个目标让它自己分解、自己执行、自己反思。结果一年用下来,发现"完全自主"在真实业务里几乎不可用:要么跑偏,要么烧钱,要么陷入循环。 现在我转向"半自主":关键决策人来拍板,Agent 负责执行和草拟方案。效率没低多少,可控性高了一大截。
看到太多新手一上来就想搭"全自动 Agent",结果连工具调用都没搞明白,做出来的东西又脆又贵。 我的建议是先把这条路走通:让模型稳定地调用一个工具(比如查天气)→ 处理好参数校验和错误 → 再扩展到多工具选择 → 最后才谈多步规划和自主循环。 工具调用是 Agent 的地基,地
把 filesystem 和 git 这俩 MCP server 接进 Cursor 试了下,体验比我预期好。Agent 模式下它能直接读项目文件、看 git log、对比 diff,不用我手动复制粘贴上下文了。 坑也有:MCP server 启动慢,每次开 Cursor 都要等
为了搞懂 Agent 原理,没用任何框架,手撸了一个最小 ReAct 循环:思考 → 行动 → 观察 → 再思考。核心逻辑其实不复杂: 手写一遍之后对框架封装的理解深了很多。建议大家入门都自己撸一个最小版本。
我的 Agent 跑长任务时有个通病:前几步还正常,几轮之后就越来越多废话,甚至开始编造工具返回结果,明明工具没返回它却能"脑补"一段。 猜是上下文越长模型越容易飘。试过定期压缩历史、只保留最近几轮观察,好一些但没根治。 这是 Agent 工程的经典痛点吧?大家的"幻觉抑制"手段
用了一堆 MCP server 之后最头疼的是鉴权——每个 server 一套玩法:有的要环境变量、有的要配置文件、有的要 OAuth、有的干脆明文传 token,文档还经常语焉不详。 接五个 server 就得研究五遍鉴权,心智成本巨高。真希望 MCP 规范能把鉴权这部分统一下
聊下我给 Agent 做的"记忆"方案,不一定最优,用着还行。 短期记忆就是对话窗口,最近 N 轮原文保留;中期记忆把完成任务后的"事实摘要"写进一个 KV 表(比如用户偏好、已确认的事实),下次启动加载;长期记忆走 RAG,把历史交互向量化,需要时检索。 关键是"摘要"那层,原
组里在讨论要不要让 Agent 直接读写生产库,理由是"自然语言查数据"对运营同学很友好。我第一反应是慌:Agent 写 SQL 出错就是生产事故。 我的底线是 Agent 只能查不能写,而且查也得走只读副本 + SQL 白名单 + 行数限制。写操作必须人确认。 可能我保守了。大
不同模型对工具调用的格式偏好不一样,有的是原生 function calling(JSON),有的擅长 XML 包裹的 tool use。选哪个我纠结过一阵。 我的结论是:能原生就原生,结构化程度高,解析稳;只有在模型对原生支持差、或者需要更复杂的嵌套指令时才考虑 XML。 而且
之前让模型读本地文件得手动复制粘贴,或者写脚本喂,特别麻烦。接了 filesystem MCP 之后,Agent 自己就能读指定目录下的文件,问"帮我看看这个项目的依赖有没有冲突"它直接翻 package.json。 权限要控制好,我只开放了工作目录的只读,写操作单独再开一个受限