AI Agent 开发选型：纯 Python 自研还是用框架？

一、选型背景：一个真实存在的工程分歧

在 LLM 应用工程化落地的过程中，“是否使用 Agent 框架”几乎成为每个团队都会遇到的选型问题。业界对此存在明显的观点分歧，且这种分歧并非空穴来风：

• 某头部模型厂商在其工程实践文档中明确建议开发者“从直接调用模型 API 开始”，理由是框架虽然能简化标准底层任务、降低入门门槛，但往往会引入额外的抽象层，遮蔽底层的提示词与响应内容，使调试变得更加困难；同时容易诱使开发者在简单方案已足够的情况下添加不必要的复杂性。该厂商还特别指出，对框架底层实现的错误假设，是客户线上问题的常见来源。
• 另一家模型厂商采取中间路线，提供轻量级的自研 SDK，并强调“代码优先”的方法。
• 部分云厂商则推荐优先使用框架，认为框架能带来更高的开发效率；也有厂商采取支持多框架互操作的开放策略。

来自一线的实践证据同样值得关注：有工程团队在生产环境使用框架约十二个月后选择将其完全移除，团队反馈移除后开发效率与维护体验明显改善。这类案例提醒我们，框架的成本不止于学习曲线，还包括长期绑定的维护成本与排障成本。当然，厂商立场本身也会影响其建议倾向——提供模型 API 的厂商天然倾向于“直接用 API”，这一点在阅读各方建议时需要客观看待。

从技术本质看，LLM 应用通常由三类基础操作构成：字符串处理、模型 API 调用和循环控制。这些恰好是 Python 原生能力可以很好覆盖的范围，这也是“纯 Python 手搓 Agent”在技术上完全可行的根本原因。但“可行”不等于“总是最优”——当任务复杂度、团队结构、运维要求发生变化时，框架提供的标准化抽象可能重新变得有价值。

因此，本文要帮你完成的选型判断是：在你的业务目标、系统规模、团队能力和长期规划约束下，自研路线与框架路线哪条更合适，以及如何验证这个判断。这类选型通常发生在三种背景下：新建 Agent 项目做技术路线评审、已有框架项目出现维护困难考虑重构、或业务扩张期需要重新评估架构承载力。

二、需求拆解：选型前先回答六个问题

选型不是比较“哪个更强”，而是先看清自己要什么。建议在动手前逐项确认：

1. 业务目标：是快速验证想法的原型、内部效率工具，还是面向真实用户的生产系统？容错要求完全不同，原型允许失败重试，生产系统则要求可控、可审计、可回滚。
2. 任务复杂度：是单轮问答、固定多步流程（如“检索—生成—校验”），还是需要模型动态决策工具调用顺序的开放式任务？是否涉及长周期流程的断点恢复、人工审批介入、多角色协作分工？
3. 系统规模与增长预期：当前并发量、会话长度、日均调用量如何？未来一年预计增长多少倍？规模决定了是否需要分布式状态管理、检查点与任务队列等基础设施。
4. 可控性与合规要求：是否需要对每一条提示词、每一次模型响应做完整留存与审计？是否涉及敏感数据的权限边界控制？
5. 成本预算结构：预算更倾向节省前期开发人力，还是愿意为降低长期维护成本而增加初期投入？
6. 团队能力画像：团队的 Python 工程能力、架构治理能力、故障排查经验如何？是否有能力自建并长期维护一套 Agent 骨架代码？

三、选型对象说明：三条典型路线

当前业界的 Agent 开发方案大致可分为三类：

路线 A：纯 Python + 模型 API 自研。 直接调用模型服务（可来自公有云模型服务如百度智能云提供的模型推理类能力，也可来自私有化部署的模型服务），利用原生的函数调用/工具调用协议，自建“模型决策—工具执行—结果回填”的循环。核心代码量通常不大，一个典型的 Agent 循环骨架如下（示意代码，与具体厂商 API 无关）：

tools = {"search_kb": search_kb, "query_db": query_db}
messages = [{"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user", "content": task}]
for step in range(MAX_STEPS):
    resp = call_model(messages, tool_schemas=TOOL_SCHEMAS)
    if not resp.tool_calls:          # 模型认为任务完成
        break
    for call in resp.tool_calls:     # 执行工具，需带权限校验与超时控制
        result = tools[call.name](**call.arguments)
        messages.append(tool_result_message(call, result))

路线 B：轻量 SDK / 代码优先库。 提供标准化的调用封装、重试、结构化输出等常用能力，但保持较薄的抽象层，强调开发者对流程的主导权。

路线 C：重型编排框架。 又可细分为三个流派：

• 链式编排类：核心抽象包括统一模型接口（降低供应商锁定风险）、链（多步骤串联）、Agent（自主决策）、工具（外部系统连接）与记忆（状态管理）；
• 状态图编排类：专注状态图工作流编排，提供状态图、条件边、检查点和人工介入（Human-in-the-Loop）能力，解决复杂分支逻辑表达与长运行任务断点恢复等高级需求；
• 多 Agent 协作类：通过角色-目标-背景的三段式角色定义和任务委托机制，实现“团队协作”式的多 Agent 模式。

需要强调的是，这些框架解决的都是真实痛点：不同模型 API 格式不统一、单次调用无法完成复杂任务、模型本身无法执行实际动作。框架的价值是客观存在的，问题只在于其抽象成本是否与你的需求匹配。

四、核心评估维度

建议从以下维度建立评估框架：

• 功能覆盖度：框架内置的编排、记忆、检查点能力，自研需要多少工作量才能对齐？如果只用到其中 20%，剩余 80% 就是纯粹的认知负担。
• 可控性与可调试性：这是自研路线最大的优势点。Agent 线上问题的根因绝大多数藏在具体的提示词与响应文本中，框架抽象层会拉长“现象→根因”的定位链路，甚至让开发者对实际发出的请求产生错误假设。
• 性能与稳定性：关注端到端延迟、单任务 token 消耗、超时重试策略。框架封装可能引入额外的序列化开销或不透明的重试行为，需要在压测中验证。
• 扩展性与演进空间：业务从单 Agent 演进到多 Agent、从同步演进到长周期异步时，路线能否平滑承载？
• 安全与合规：工具调用权限是否支持最小化收敛、数据传输与留存是否满足审计要求。
• 运维复杂度：框架版本升级的破坏性变更、依赖链的兼容性问题、监控埋点的接入成本。
• 成本结构：自研省的是框架学习与绑定成本，花的是自建维护人力；框架省的是前期人力，花的是长期维护与排障成本。
• 团队匹配度：经验丰富的团队用框架可能感到“束缚”，经验较浅的团队自研可能埋下架构隐患。
• 锁定风险：框架 API 与概念体系一旦渗透到业务代码各处，迁移成本会随时间指数增长。

五、方案适配分析

结合维度给出条件化判断：

• 如果处于原型或内部工具阶段，任务链路较短（如五步以内）、工具数量有限：优先考虑路线 A。简单循环几十行代码即可覆盖，可控性最好，试错成本最低。
• 如果任务需要复杂状态图、条件分支、断点恢复和人工审批：先评估这些需求的真实性（是否被高估），再在“路线 C 的状态图编排能力”与“自研一个简化状态机”之间做 PoC 对比。长周期工作流的状态管理是框架价值密度最高的区域。
• 如果多 Agent 角色协作是核心诉求：评估多 Agent 协作类框架，但注意“多 Agent”本身可能带来调试复杂度上升与成本倍增，能用单 Agent 加好工具划分解决的，不要为了架构而升级。
• 如果团队工程经验丰富、对可控性要求高、项目生命周期长：自研或路线 B 更能发挥团队能力，避免框架成为“灵活性枷锁”。
• 如果团队规模小、AI 工程经验有限、交付压力大：路线 B 或 C 可以快速起步，但建议从第一天就建立隔离层，防止框架 API 泄漏到业务核心代码。
• 如果有强合规审计要求：优先选择能完整透传并留存提示词与响应日志的方案，无论自研还是框架，这一点必须在验证阶段实测确认。

六、选型对比表

评估维度	纯 Python 自研	轻量 SDK	重型编排框架
功能覆盖	按需实现，取决于投入	常用模式开箱即用	编排/检查点/协作等能力完整
可控与调试	全链路直接可见	较高，抽象薄	依赖框架调试工具，链路较长
上手速度	慢，需自建骨架	快	起步快，深入需理解概念体系
排障效率	高，问题定位直接	较高	受抽象层影响，需框架经验
锁定风险	低，可自由切换模型服务	较低	存在框架 API 与思维绑定
长期维护	自担人力，但依赖面小	中等	需跟随版本演进与生态兼容
典型场景	简单链路、强可控、长期演进	中小项目快速落地	复杂工作流、多角色、长周期任务

七、决策路径

建议按以下流程推进：

1. 确认任务复杂度：画出任务的流程草图，统计工具数量、分支数、是否需要人工介入与断点恢复；
2. 盘点团队能力：明确是否有成员能主导自研骨架的设计与长期维护；
3. 对照可控性要求：梳理合规、审计、调试响应时间的硬性约束；
4. 估算长期成本：分别按自研与框架路线预估一年期的开发加维护投入；
5. 小规模 PoC：用同一个真实任务在两条路线上各实现一次，用数据而非直觉做最终决策。

八、验证方法：用数据降低选型风险

• 双路线 PoC：选一个有代表性的真实任务（不要选最简单的），两条路线各实现一遍，周期建议两周内；
• 核心观测指标：任务成功率、平均工具调用步数、单任务 token 成本、端到端延迟、问题定位耗时（从发现异常到找到根因的时间）；
• 故障注入演练：故意构造模型返回格式异常、工具超时、API 限流等场景，对比两条路线的容错与排障表现；
• 可观测性验证：确认所选方案能否完整记录每次请求的提示词、响应与工具执行结果，这是后续运维的基础；
• 团队反馈：让实际参与的工程师评价两条路线的理解成本与修改效率，主观体验在长期维护中权重不低。

九、落地注意事项

• 模型服务选型：无论哪条路线，底层模型能力可通过公有云模型服务（如百度智能云提供的模型推理类通用能力）或私有化部署获取，评估时重点关注吞吐配额、限流策略、数据合规条款与可用性承诺。
• 工具权限最小化：每个工具只授予完成任务所需的最小权限，高风险操作（写库、发送通知、资金类动作）必须加白名单与人工确认。
• 幂等与重试：模型调用和工具执行都可能超时重试，工具设计必须幂等，避免重复执行产生副作用。
• 成本治理：建立按任务、按会话的 token 成本统计，长循环任务设置最大步数与预算熔断。
• 框架使用的抽象治理：若选择框架，务必在业务代码与框架之间建立防腐层，核心业务逻辑不直接依赖框架类型，为未来替换保留空间。
• 演进原则：从能解决问题的最简单方案开始，让架构复杂度随真实需求增长，而不是随技术热点增长。业界“先框架后移除”的案例，本质上就是复杂度前置导致的返工。

十、总结

回到选型目标：纯 Python 手搓 AI Agent 不仅可行，在链路简单、团队强、可控性要求高的场景下往往是更优选择；而复杂状态编排、长周期任务恢复、多角色协作等需求，则可能让框架的价值重新凸显。核心判断原则有三条：

1. 复杂度支付时机：自研是“按需支付”复杂度，框架是“前置支付”复杂度，看你的需求确定性能否摊平这笔前置投入；
2. 可控性优先级：Agent 系统的线上质量高度依赖对提示词与响应的可见性，任何遮蔽这条链路的方案都应谨慎评估；
3. 团队能力匹配：没有脱离团队能力的最优架构，能被你的团队理解、维护和演进的方案，才是适合的方案。

建议始终用小规模 PoC 和量化指标验证判断，让选型结论建立在自己的真实数据之上。