Agent 工具选型最容易变成品牌名比较：Dify 好不好，n8n 强不强，LangGraph 是不是更工程化。我的理解是，这不是五选一，而是分层组合。每个工具最适合承担的复杂度不同，把它放错层，后面维护会越来越难。
按层选，不按热度选
- n8n：适合业务自动化集成层，接 Webhook、表格、邮件、API、Excel 和通知。
- Dify：适合 RAG、原型和应用壳，快速把知识库、工具和对话入口跑起来。
- Coze：适合中文协作和快速演示，但不作为长期工程能力的唯一证明。
- OpenAI Agents SDK：适合从低代码过渡到代码栈，做 tools、handoffs、guardrails、sessions 和 tracing。
- LangGraph：适合长流程、可恢复状态、审批中断和更复杂的生产编排。
作品集最好同时给业务和工程师看
如果作品集只展示 Dify 或 n8n，很容易被看成工具使用；如果只展示 LangGraph，又容易离业务价值太远。更稳的组合是：一个业务看得懂的 ROI 项目，比如广告关键词清洗或补货表生成；再配一个工程师看得懂的架构项目，比如多 Agent handoff、审批恢复、状态持久化和 trace。
低代码负责把价值跑出来，代码栈负责把能力沉淀下来。
我更愿意按失败方式选工具
选型时最有用的问题不是“谁功能最多”，而是“出错以后怎么恢复”。Webhook 失败需要补发，适合自动化平台；知识命中不稳需要看 citation，适合有检索评测的应用层；长流程中断后要从审批点恢复，才值得引入状态图；核心规则需要版本、测试和审计，就应该进入代码仓库。失败方式决定了状态该放在哪里，也决定了哪种工具负责这一步。
选型检查单
这个步骤是否需要长期状态？失败后从哪里恢复？是否有人审中断？规则是否要版本化和测试？数据是否需要权限过滤？如果只是连接系统与传递数据，优先自动化平台；如果承担核心判断，优先代码与可测试配置。
从能用到可维护，迁移边界要提前留好
核心规则不应该只写在低代码画布里。Prompt、工具 schema、RAG metadata、审批规则、数据字段字典和导出格式都应该放在仓库或独立服务里。这样第一版可以用 Dify/n8n 快速交付，后面迁到 Agents SDK 或 LangGraph 时，不需要重做业务底座。
Dify / UI shell
-> retrieves governed knowledge
n8n / automation plane
-> connects business systems
Python Agent service
-> owns rules, tools, approvals, tracing
Postgres / vector store
-> stores facts, metadata, decisions
放到亚马逊运营场景里，我会这样用
- 运营知识库和 SOP 问答先用 Dify 跑通，重点验证 citation、metadata 和拒答边界。
- 广告报表清洗、Excel 生成、审批通知和定时任务先交给 n8n 或脚本自动化。
- 关键词决策、补货建议、Listing diff 这类核心判断保留在 Python 服务或 Agent Skill 里。
- 当流程出现长时间等待、人审恢复和多工具交接，再把关键链路升级到 LangGraph。
- 如果要展示多 Agent 协作，OpenClaw 或 Agents SDK 更适合承载清晰的 handoff 叙事。
工具不是能力边界，抽象才是
最终我会用一条原则判断：这个复杂度应该被产品画布吸收，还是应该沉淀成代码、配置和测试？能让业务快速验证的东西，先用平台；会反复复盘、调参、迁移和审计的东西，尽早写成可版本化资产。