你现在主力用哪个 MCP server?
最近在搭自己的 Agent 工作流,挑 MCP server 挑花了眼。官方的 filesystem、fetch、git 我都装了,社区里还有一堆数据库、浏览器、搜索的。 实测下来用得最频繁的是 filesystem 和 git,基本每天都在用;浏览器那个偶尔爬数据开一下;搜索类
Posts
Start discussions like a forum — great for questions, opinions, tool recommendations, and experience sharing.
最近在搭自己的 Agent 工作流,挑 MCP server 挑花了眼。官方的 filesystem、fetch、git 我都装了,社区里还有一堆数据库、浏览器、搜索的。 实测下来用得最频繁的是 filesystem 和 git,基本每天都在用;浏览器那个偶尔爬数据开一下;搜索类
MCP 热度很高,但我有点犹豫要不要投入精力。历史上这种"统一协议"翻车的不少,万一过两年又冒出个新标准,学了不就白学了。 不过看现在 Claude、Cursor、各家 IDE 都在拥抱 MCP,势头确实猛。我倾向于:作为用户先用起来(装几个现成 server 不需要学协议),作
想给公司内部系统包一个 MCP server,让 Agent 能查我们的工单系统。看了下官方 SDK,TS 和 Python 都有,但入门的 best practice 不多。 最困惑的是工具粒度怎么切:是给一个大而全的"查工单",还是拆成"按状态查""按人查""按时间查"一堆小
搭了个 Agent 跑自动化,最让我崩溃的不是它做错事,而是它陷入死循环:调用工具失败 → 重试 → 又失败 → 再重试……token 嗷嗷烧,任务一点进展没有。 加了最大迭代次数和"连续失败 N 次就停"的护栏,情况好点,但偶尔还是会原地打转。 感觉循环检测是 Agent 工程
第一次用 Function calling,以为模型会乖乖返回结构化 JSON,结果在边界情况上栽了跟头:偶尔参数少字段、偶尔类型不对(数字返回成字符串)、偶尔还会塞一段多余的解释文本。 最后是用 schema 校验 + 失败重试兜底的。核心代码大概这样: zod 真是救命稻草。
设计 Agent 的时候有个分歧:一种观点是 Agent 应该完全听话,工具调用有明确规则它执行就行;另一种是 Agent 应该有"判断力",遇到可疑操作主动拒绝。 我倾向后者,特别是涉及数据修改、对外发送的场景,宁可它多问一句。但实现起来很难——怎么定义"可疑",模型自己判断又
让大模型稳定输出 JSON 是 Agent 工程的老大难。我试下来最稳的组合是:用原生 function calling(别让模型自由生成 JSON 字符串)+ 严格 schema + 温度设 0。 如果只能走自由生成(比如某些场景),用"JSON 模式"加固定的前后缀提示,能把
最近"多 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 都要等