选型筛选器 交互

任务类型
全部 长任务 / 复杂流程 短任务 / 快速响应 批量并行 人机协同 HITL
团队背景
全部 Python 工程团队 企业级 / 严格审计 无代码 / 业务团队 快速原型 / 小团队

点击框架卡片展开 PM 选型注记 · 推荐框架高亮显示

LangGraph
有状态 DAG，复杂工作流首选
有状态 生产稳定 HITL 原生
PM 选型注记
可视化调试工具较弱，设计阶段必须把 Workflow 图画清楚，否则节点边界模糊会让调试成本极高。适合有专职 AI 工程师且流程需要循环/条件回退的场景。学习曲线陡，不适合快速原型。
AutoGen
多 Agent 对话框架，微软出品
对话式 Beta 阶段 HumanProxy
PM 选型注记
对话式协作的 token 消耗高，生产环境 cost 需要单独评估。v0.4 架构重写后接口变化较大，要注意版本锁定。适合需要多 Agent 互相辩论/迭代细化的创作型任务，不适合延迟敏感场景。
CrewAI
角色驱动协作，最接近开箱即用
低学习曲线 生产稳定 角色驱动
PM 选型注记
角色定义质量直接决定结果质量，Prompt Engineering 投入高。优点是概念直觉（角色/目标/任务），非工程背景的 PM 能快速理解。内容生产流水线（调研→写作→审核）是最典型的适用场景。
OpenAI Swarm
极简 handoff，轻量场景适用
实验性 极低门槛 无状态
PM 选型注记
OpenAI 明确标注 experimental，没有公开的长期路线图支撑，生产环境依赖风险需评估。适合简单意图路由+专门化处理（如客服意图分发），超出这个范围建议换框架。
Dify
可视化画布，非技术团队入门
无代码 企业版稳定 审批节点
PM 选型注记
定制化能力受限，复杂逻辑需要"逃逸"到代码节点。关键问题：要评估业务是否会超出平台边界。如果未来 70% 的节点都是代码节点，还不如直接用 LangGraph。适合非技术团队的知识问答、审批流、内容生成管线。
自研编排层
企业级定制化的终极选择
极高成本 完全可控 架构自由
PM 选型注记
前提是已有成熟的技术中台和专职 AI 工程团队。盲目自研是最常见的过度工程陷阱——绝大多数团队在实现到 50% 时才发现维护成本超出预期。适合对数据主权/审计/可观测性有严格要求的大型企业。

消费级 Agent 代表 产品层 · 非选型框架

以下不是构建 Agent 的开发框架，而是直接交付给终端用户运行的 Agent 产品。列出它是为了说明 Agent 生态有「框架层」与「产品层」两个不同的演化方向——理解这个分层，是 PM 做 Agent 相关产品决策的前提。

OpenClaw
247k Stars · 个人自主 Agent 守护进程（原名 Clawdbot / Moltbot）
消费级 本地运行 非构建框架
交互层 UI
WhatsApp · Telegram
Discord · Slack · Signal
能力层 Action
Shell 执行 · 浏览器自动化
邮件 / 日历 · 定时任务
PM 视角：与 LangGraph/CrewAI 的本质差异在于——后者是给工程师构建 Agent 用的工具，OpenClaw 是交付给终端用户直接运行的产品。选择消息平台而非独立 App 作为界面，是刻意降低信任建立成本的设计决策：用户已经信任 WhatsApp，比接受一个新 App 的心理门槛低得多。它代表的不是框架选型问题，而是「Agent 如何从 B 端工具演化为 C 端个人助手」这个产品层命题。

对比矩阵 8 维度

框架 编排模型 状态管理 学习曲线 生产可用 HITL 适合团队 PM 关注点
LangGraph 有状态 DAG GraphState 持久化 高 稳定 原生 Python 工程 设计阶段画清 Workflow 图
AutoGen 多 Agent 对话 对话历史，无持久化 中 Beta HumanProxy 研究/快速原型 Token 消耗高，需评估 cost
CrewAI 角色驱动 Task 间传递 低 稳定 参数控制 全栈/快速落地 Prompt 质量决定结果质量
OpenAI Swarm 函数式 handoff 无状态 极低 实验性 不内置 OpenAI 生态小团队 无长期路线图，依赖风险高
Dify 可视化画布 内置工作流状态 极低 企业版稳定 审批节点 产品/业务团队 评估业务是否超出平台边界
自研编排层 完全自定义 完全自控 极高 取决于工程投入 完全可控 大型企业 AI 团队 盲目自研是最常见的过度工程陷阱

四种多 Agent 拓扑形态

① 单 Agent + 工具链

最简路径，工具数 ≤5，单一目标任务
Agent T 工具 工具 工具 适合：目标明确的单步任务

② 主-从编排（Hub & Spoke）

有中央协调者，子任务可并行，适合统一质控
Orchestrator Agent A Agent B Agent C 适合：需要统一质控的复杂任务

③ 对等协作（Peer-to-Peer）

Agent 互相审查/辩论，创作/决策类任务
写作 Agent 审查 Agent 决策 Agent 适合：创作/高风险决策任务

④ 流水线（Pipeline）

线性流程，每步产出是下步输入，内容生产管线
采集 处理 生成 审核 适合：内容生产、数据处理管线

案例：企业年度报告自动生成系统 序列图

用户
→
触发年报生成任务
Orchestrator
→
并行分发：Research Agent + Data Agent（同时启动，减少延迟）
⚡ 并行执行，两个 Agent 同时工作
Research Agent
→
搜索财报/行业新闻/竞品动态
Data Agent
→
结构化数据提取（财务指标/KPI）
Orchestrator
→
聚合两路结果 → 发给 Writing Agent
Writing Agent
→
分章节起草报告初稿
QA Agent
→
事实核查 + 引用验证（最多 2 次修订循环）
🔄 如核查未通过：Writing Agent 修订 → QA Agent 再审，最多循环 2 次
HITL
→
⚠️ 人工审核节点（必经，不可绕过）
🔒 关键设计决策：高风险输出必须有人签字，AI 不可自主发布
Formatter Agent
→
排版格式化 → 最终输出

PM 设计注记

1
先画泳道图，再选框架
多 Agent 架构设计是 Workflow 设计，不是技术选型。绝大多数团队踩的坑是先选了框架再想场景，导致为了迁就框架而扭曲 Workflow。正确顺序：先把人工流程文档化 → 识别可 Agent 化的节点 → 画泳道图 → 最后选框架。
2
Agent 边界即 Prompt 边界
一个 Agent 做的事越多，Prompt 越难写，结果越难稳定。单一职责原则在 Agent 设计里比在代码设计里更重要——因为 Agent 的失败是乘法效应，边界不清晰的 Agent 会让整个链路的可靠性骤降。
3
异步优先，同步兜底
能并行的子任务设计为异步，在结果聚合层做同步。避免串行等待造成的延迟叠加。以上面的年报系统为例，Research + Data 并行节省了约 40% 总执行时间，这是在不改变任何模型能力的前提下纯靠架构获得的收益。

六大企业场景 痛点 → 方案 → ROI

HR · 人才招募
简历初筛耗时 2h/天，标准不一致
1
简历解析 Agent：PDF→结构化字段
2
岗位匹配评分 Agent：JD 比对打分
3
亮点/风险提取 Agent：标注关键信息
✓
HITL：HR 确认待面试清单
2h → 20min/天
适用前提：招聘量 >50份/月；文化契合度高权重岗位建议 AI 辅助而非主导
研发 · Code Review
资深工程师 15% 时间在重复性审查
1
diff 分析 Agent：提取变更范围
2
安全检测 Agent：OWASP 规则库比对
3
规范检测 Agent：团队规范文档匹配
✓
批注汇总 → PR 自动 Comment
规范问题拦截率 >85%
节省资深工程师约 40% Review 时间；安全敏感代码仍需人工全量审查
客服 · 工单处理
70% 时间处理标准化问题，复杂工单等待久
1
意图识别 Agent：分类标准工单
2
情绪评分 Agent：识别高风险对话
3
路由：FAQ / 退换货 / 投诉 / 升级
✓
复杂/情绪高风险工单 → 人工
标准工单自主处理率 70%
P0 工单响应从 4h → 30min（更快路由到人工）；早期 3 个月保留人工抽样质检
BI · 数据报告
分析师每周 4-6h 生成同结构周报
1
数据拉取 Agent：接 BI 系统 API
2
异动检测 Agent：同比/环比阈值告警
3
解读 Agent：自然语言分析异动原因
4
格式化 Agent → 定时推送
4h → 20min/周
异动判断标准须与业务方对齐，否则产生大量噪声告警；依赖 BI 系统稳定 API
法务 · 合同审查
合同审查依赖少数法务，普通合同排队 2 天
1
合同解析 Agent：PDF→条款结构化
2
风险识别 Agent：对比标准模板库
3
差异摘要 Agent：生成偏差报告
✓
HITL：法务确认异常条款后签署
2天 → 2小时
前提：法务团队建立标准合同模板库；最终签署审批必须由法务人工完成
IT · 帮助台
50% 工单是重复的系统使用问题
1
问题理解 Agent：意图识别
2
RAG 检索 Agent：知识库语义搜索
3
回答生成 Agent（带引用溯源）
✓
未解决 → 人工，答复自动入库
标准问题自主解答 >60%
知识库质量是瓶颈，需专人维护；对新系统上线/政策变更需即时同步

6 条 PM 判断框架 有立场 · 有数据

点击「反面思考」展开我对自己观点的反驳

01 Agent 的 ROI 主要来自「消除等待」，而非「提升质量」
大多数企业流程的瓶颈不是单步任务的质量，而是任务在队列中等待的时间（审批队列、人工处理队列）。Agent 把等待时间从「小时/天」压缩到「秒/分钟」，这是最可量化的收益。
质量提升是更难量化的 ROI，因为基线不清晰（人工处理的原始质量也不稳定）。在立项时用「消除等待」作为核心指标，比用「质量提升」更容易获得业务侧支持。
反例：如果某个流程的瓶颈在「人做决策」而非「人在等」（如法务最终签字、高管最终审批），Agent 无法解决这个瓶颈，ROI 会远低于预期。
代码生成类场景（Cursor、GitHub Copilot），写出能运行的代码本身就是价值，不只是速度。但这类场景的「质量」定义清晰、可量化（通过率/测试覆盖率），不在我说的「模糊质量提升」范畴内。我的观点是针对「质量基线不清晰」的场景，而非否定质量本身的价值。
02 Agent 的失败率是乘法而不是加法
如果一个 3 步 Agent 链每步成功率 90%，整体成功率是 72.9%（0.9³），而不是 90%。每新增一个节点，都在乘以一个小于 1 的数。
这意味着 Agent 的链路长度不应由「功能需求」决定，而应由「可接受的整体可靠性」倒推：确定允许的失败率 → 估算每步成功率 → 推算最大链路长度。
实践结论：3-5 步以内的 Agent 链在生产环境是可控的；超过 7-8 步的链在当前模型能力下，不加检查点几乎必然产生不可接受的累积错误率。
可以通过中间检查点、错误重试、回退机制来提升整体可靠性。但这些机制本身也是新的节点，会带来延迟和 token 成本。更重要的是，检查点需要有人定义「什么叫通过」，这本身也是设计成本。没有免费的可靠性——只是在成本之间权衡。
03 企业 Agent 落地的真实阻力在「责任归属」而非技术层
当 Agent 自动执行了一个操作（发送邮件、提交审批、修改数据），出错后「谁来负责」是一个组织问题，不是技术问题。AI 没有法律人格。
业务部门在 POC 阶段很兴奋，到生产部署阶段开始回缩，根本原因是他们意识到如果 Agent 出错，他们是接受问责的那个人。
PM 设计 Agent 方案时，必须在功能设计之前解决「责任设计」：明确哪些操作 AI 可以自主执行，哪些操作必须有人工签字，以及出错时的追溯链路。
有些低风险、高频的操作（发送系统通知邮件、更新 CRM 标签）的责任归属争议很小，可以快速推进。关键是识别和隔离「高责任风险」节点，不要用它来阻塞全局。一个可行的方法：先从没有外部影响的内部操作开始（读而不写），再逐步扩展到有外部影响的写操作。
04 「何时不值得用 Agent」比「何时值得用」更重要
信号 A：任务本身定义不清楚时。 Agent 不能澄清需求，只能执行需求。如果连人工做这件事的标准答案都写不出来，Agent 的 Prompt 也写不出来。Agent 只是放大了需求的模糊性。
信号 B：反馈循环缺失时。 Agent 的可靠性来自数据飞轮（错误 → 标注 → 优化）。如果任务输出无法被快速评估好坏，没有数据飞轮，Agent 质量会停滞甚至退化。
信号 C：一次性任务。 Agent 的建设成本（Prompt 设计、工具接入、评估体系、监控）在第一次使用时无法摊销。每季度才做一次的任务，ROI 计算通常是负的。
如果单次任务的价值足够高（如重大并购的尽调文档整理），一次性投入 Agent 建设也可能合算。但这类任务通常有大量自定义需求，「通用 Agent」难以处理，更接近「一次性 AI 项目」而非「可复用 Agent」。我的信号 C 针对的是常规运营任务，不是这类特殊高价值场景。
05 Agentic 产品的 UX 核心是「可预期性」，而非「自主性」
用户对 Agent 的核心焦虑来自「不知道它接下来要做什么」。自主性越强，焦虑越大。真正好的 Agent 产品 UX 应该让用户随时知道 Agent 在做什么、下一步会做什么、在哪里可以介入。
Cursor、Perplexity 能被用户接受的原因：每步行动都是可见的，用户有清晰的「接管时机」。相比之下，纯黑盒 Agent（给指令→等结果）的用户信任度普遍低。
PM 设计优先级：透明度设计（让用户看到执行步骤）> 效率设计（减少等待感知）> 自主性设计（扩大可自主操作范围）。
Cursor 的 agent 模式在执行大量小步骤时，用户也会感到疲惫。透明度设计需要分层：关键节点展示，微操作折叠。真正的设计挑战不是「是否透明」，而是「在哪个粒度透明」。这需要通过用户研究来标定，而不是一刀切地展示所有步骤。
06 消除执行层摩擦，决策层仍由人类——这是判断 Agent 落地时机的主轴
B 端：工作流整合、权责归属、内部系统对接是三道无法靠技术跨越的坎。Agent 能做的是把「人工排队等待处理」的环节自动化，但最终审批、签字、法律责任这些节点必须有人背——这不会因为模型更强而改变。
C 端：OpenClaw 证明了 C 端 Agent 的门槛在快速降低（消息平台接入解决了「用起来」），但解决不了「用得稳」。Agent 能产生实际效果的操作往往不可逆（误删文件、代发消息、读取通讯录），一旦出错用户没有补救空间，信任壁垒不会因为入口变了就消失。
判断方法：先问「这个节点的决策错了，谁承担后果？」如果是用户/企业承担 → 必须有人工确认环节，Agent 做执行不做决策；如果后果可逆、影响范围可控 → 可以考虑让 Agent 自主执行。
随着使用习惯建立，C 端对复杂任务的需求会逐步释放，信任壁垒也会随之降低。「决策层仍由人类」是当前阶段的判断，不是永久结论——真正的问题是：什么样的技术/制度条件成熟后，这个边界会移动？可能的答案是：可靠的撤销机制 + 明确的责任归属框架 + 用户对 Agent 错误率的感知下降到可接受阈值。