Agent 框架那么多,产品经理到底该学哪个?
最近有个问题困扰了我挺久:LangChain、LangGraph、AutoGen、CrewAI、Dify、Coze……光是听到这些名字就头大。是专注深学一个,还是每个都了解一点?
如果专注学一个,万一选错了呢?如果广泛学,又怕学得很杂、没有逻辑,到最后每个都是皮毛,用不上。
这个问题困扰了我挺久,后来想通了一个关键点:这些框架不是竞争关系,是分层关系。
最近有个问题困扰了我挺久:LangChain、LangGraph、AutoGen、CrewAI、Dify、Coze……光是听到这些名字就头大。是专注深学一个,还是每个都了解一点?
如果专注学一个,万一选错了呢?如果广泛学,又怕学得很杂、没有逻辑,到最后每个都是皮毛,用不上。
这个问题困扰了我挺久,后来想通了一个关键点:这些框架不是竞争关系,是分层关系。
很多 PM 有一个误解:觉得自己技术学得越深,在工程师面前就越有底气。
这个逻辑不完全对。工程师对 PM 的尊重,很大程度上来自”这个 PM 能把需求说清楚、能定义清楚验收标准、能做合理的取舍”——不是来自”这个 PM 也会写代码”。
AI 这么能干,产品经理还有没有必要存在?
这个焦虑不是没有来由。你现在打开任何一个 AI 工具,让它帮你写 PRD、拆需求、做竞品分析,它确实能给你一份像模像样的文档。Gartner 也说过,到 2026 年大概有 30% 的传统产品岗位会被工具替代。
写一份清晰的规格说明,涵盖恰到好处的细节(可包括结构、风格、测试、边界),既能指导 AI,又不会让它不堪重负。把大任务拆成小任务,而不是全部塞进一条超长提示里。先用只读模式做规划,再持续执行与迭代。
Provider-specific中间件通常是针对特定供应商的API特性开发的,比如内容审核、缓存机制、特定格式支持等。这些中间件虽然不能跨供应商使用,但在特定供应商的场景下,能提供更强大的功能和更好的性能。
File search中间件为AI智能体提供Glob和Grep两种文件搜索工具,支持按文件名模式查找文件和按内容正则表达式搜索,适用于代码探索、文件发现、内容分析等场景。
Shell tool中间件为AI智能体提供持久化的Shell会话,允许AI智能体执行系统命令、进行文件系统操作、运行脚本等。但同时,这也带来了安全风险,必须根据部署环境选择适当的安全策略。
Context editing中间件可以在达到token限制时,自动清理较旧的工具调用输出,保留最近的关键工具结果,确保长对话和多工具调用场景下上下文窗口可控,同时降低token消耗。