什么情况适合用 sdk 或者框架去实现 agent，什么情况适合自己手搓？

拿“论文检索助手”举例：用户提问，模型搜论文、读摘要，不够就再搜，最后回答。只有几个工具、不需要跨天运行，我会先用模型 SDK，自己写 Agent 循环，没必要直接上重框架。 但如果变成“调研任务运行几小时，中途等用户审批，服务重启后还要接着跑”，我就会优先考虑提供持久化、暂停恢复能力的框架。此时难点已经不是调模型，而是管理任务状态。 关键不是“SDK 和手搓哪个高级”，而是你需要自己控制哪一层。 一、先分清三种东西 模型 SDK：主要帮你调用模型，处理请求、流式响应等。用它，然后自己写工具执行和循环，依然算手搓 Agent。 Agent SDK：进一步帮你实现“模型决定调用工具→执行工具→回传结果→继续”的循环，具体还可能提供会话、追踪等能力。 编排框架：进一步管理多个步骤之间的状态、分支、并行、暂停恢复等。不同产品覆盖范围不同，不能只看名字叫 SDK 还是 Framework。 所以完全可以“底层用 SDK，核心循环自己写，外层用工作流引擎”，不是二选一。 二、什么情况适合用现成 SDK / 框架 需求比较标准，优先 Agent SDK。 比如客服助手，需要查订单、查知识库、生成回复，默认工具循环基本符合需求。你的价值主要在业务工具和回答质量，不在重新实现循环。 任务有复杂生命周期，优先评估编排框架。 比如退款流程：核验订单→提出退款方案→等待人工审批→执行退款。需要保存审批前的状态，重启后继续执行，还得防止重复退款。选型时要验证恢复机制；框架也不能替你自动解决业务幂等。 团队需要统一开发方式，也值得用框架。 多人维护时，统一工具接口、状态结构、执行追踪，比每个人写一套更容易协作。但前提是大家能理解框架的执行模型，而不是只能照着示例拼。 三、什么情况适合自己手搓 学习原理。 建议至少自己写一次最小循环：调用模型→检查工具请求→校验并执行→回传结果→继续，直到结束或达到预算。你会真正理解消息历史、工具返回和停止条件。 流程简单、边界清楚。 比如“检索→生成→校验”，普通函数加条件判断就能表达，甚至不需要自主 Agent。套一层图编排未必比直接代码更清楚。 核心策略需要高度定制。 比如每轮动态选择模型、按剩余预算限制搜索、精细裁剪上下文、对不同工具采用不同重试规则。如果框架有合适的扩展点，就继续用；如果一直绕过默认行为、改内部实现，自己维护这层往往更合适。 已有成熟基础设施。 公司已经有任务队列、持久化、审批、日志和监控，你可能只缺一个 Agent 循环，不需要再引入一套重复的运行体系。 四、别低估“手搓上线”的成本 循环本身可以很短，但生产系统还要处理：超时、取消、参数校验、权限、预算、日志、评测，以及有副作用操作的重复执行问题。 比如“搜索失败”可以重试，“扣款请求超时”却不能直接再扣一次。这个问题无论用不用框架，都要在业务层设计。 我的默认建议是： 学习项目，先用模型 SDK 手搓一个最小版本，再用框架重做，对比它究竟替你解决了什么。 业务项目，先验证最简单方案；默认循环够用就用 Agent SDK，需要可靠的长任务编排再引入相应框架。只把真正需要差异化控制的部分留给自己。 判断标准就一句：它替你省掉的维护成本，是否大于它带来的理解、调试和适配成本。 参考：Anthropic 的这篇是 2024 年的架构原则文章，不当作最新工具选型榜，但“从简单组合开始，理解框架底层行为”的建议适用于这里。 https://www.anthropic.com/engineering/building-effective-agents