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

agent-or-">一、选型背景：为什么 Agent 开发绕不开“框架 or 自研”

近两年，AI Agent 成了大模型应用中最受关注的方向。翻看主流教程，几乎清一色基于开源 Agent 框架或编排框架展开：图状态机、多角色协作、开箱即用的工具链，确实是入门的最短路径。

但如果把视线转向真正跑在生产环境的头部 Agent 产品——尤其是智能编程助手这一类——会看到一个反常识的现象：它们的核心架构几乎都是团队自研的定制方案，而不是“框架套壳”。

原因并不复杂。生产级 Agent 要的三样东西——高效率、个性化、鲁棒性——恰好是通用框架天然偏弱的部分。框架为了通用性必须做厚抽象，抽象越厚，对执行细节的掌控越弱，出了问题越难排查。一句话概括：别人的轮子，跑不了你的路。

反过来，自研也不是银弹。在原型验证、通用 RAG 流水线、自动化工作流这类成熟场景里，框架能实打实省下大量时间。所以选型问题从来不是“哪个更好”，而是“你的需求、团队能力与长期规划，更适合哪条路线”。本文的目标，就是帮你把这个判断变成一个可执行的过程。

二、需求拆解：先想清楚你要做的是哪一种 Agent

评估路线之前，先把 Agent 本身想清楚。Agent 的本质可以浓缩成八个字：感知—推理—行动—学习。

早期的对话式大模型产品是“你问它答”，本质是个聊天机器人；Agent 的差别在于它有工具：能检索知识库、能调用外部 API、能执行真实操作，复杂度完全取决于你要它干什么。

看两个极端例子：

• 最简形态：客服 Agent。RAG 检索工具 + 自动发邮件工具 + 搞不定的问题转人工。几百行代码，但它已经是合格的 Agent。
• 复杂形态：任务型 Agent。多步规划、多工具组合、上下文管理、失败重试、人工接管，每一步都是工程挑战。

主流实现模式是 ReAct（Reasoning + Acting），精髓是“显式思考、显式行动”：每一步推理和工具调用都留有记录，出了问题可以回放定位。这是可控性的基础，也是后面评估框架与自研的重要标尺。“学习”部分涉及向量数据库与长期记忆，属于进阶能力，本文先聚焦感知、推理、行动三件套。

落到选型，建议先把下面六个问题问清楚：

1. 业务目标：学习练手、内部工具，还是面向真实用户的生产系统？
2. Agent 复杂度：单轮工具调用，还是多步推理与任务编排？
3. 系统规模：预计调用量、并发量、工具数量、未来增长预期？
4. 团队能力：有没有人能驾驭核心循环、上下文管理、异常兜底？
5. 交付窗口：两周出原型，还是半年打磨产品？
6. 资产属性：Agent 是过渡方案，还是产品的核心竞争力？

这六个问题的答案，基本就决定了路线倾向。

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

路线 A：基于成熟框架开发。 复用开源 Agent 框架提供的现成抽象：工作流编排、工具调用协议、状态管理、多模型接入适配。优点是起步快，代价是受框架约束。

路线 B：纯 Python 从零自研。 自己实现 Agent 主循环、工具抽象、上下文管理与模型调用层。核心架构完全可控，代价是前期基础设施投入更大。

路线 C：混合路线。 核心循环自研，通用能力（RAG 组件、向量检索、日志监控等）复用框架或云上托管服务。这也是不少成熟团队的务实选择——“核心自己搞，通用借现成”。

四、核心评估维度

1. 开发效率

框架在原型期优势明显：模型接入、工具协议、状态管理都是现成的。自研需要先搭基础设施，冷启动成本高。评估方法很直接：同样一个“检索 + 调用工具”的 Demo，两条路线各需要多少人日，一测便知。

2. 可控性与可调试性

这是生产系统的分水岭。框架的多层封装会让“模型到底收到了什么提示词、状态在哪一步漂移了”变成黑盒；自研的 ReAct 循环里，每一步思考和行动都是显式的，可以打日志、可以回放。Agent 出错时，能不能在十分钟内定位是提示词问题、工具问题还是上下文超长问题，直接决定上线后的运维体验。

3. 扩展性

正经的 Agent 都遵循工具抽象原则：新工具注册即用，核心代码零改动。评估框架时，看它的工具接入协议是否够薄；评估自研时，看自己的注册机制设计是否到位。预期工具数量越多，这一维度权重越高。

4. 模型无关性

LLM 是“大脑”，Agent 是“指挥官”，两者必须分离。今天用 A 家模型，明天换 B 家，如果换一次 Provider 就要重写一遍 Agent 逻辑，等于给自己埋雷。分离之后还能获得一个关键能力：故障回退——主模型服务异常时，自动切到备用服务，业务不中断。自研路线天然由你控制这个边界；框架路线则要考察其模型适配层的成熟度与更新频率。

5. 鲁棒性

生产 Agent 必须能回答：工具超时怎么办？模型返回格式异常怎么办？循环空转怎么办？这些兜底逻辑，自研时必须自己写，但写出来的就是你的资产；框架提供了一部分，可一旦需求超出自带能力，往往要“绕着框架写”，反而更别扭。

6. 团队能力匹配

框架显著降低了上手门槛，经验有限的团队也能快速出活；自研要求团队对大模型调用、上下文工程、异常处理有实打实的经验。如果团队人力紧张或经验不足却强行自研，很可能得到一个既不如框架稳定、也没省下人力的四不像。

7. 长期维护成本

框架路线有版本升级、依赖治理、破坏性变更的跟随成本；自研路线有基础设施的持续投入成本。前者是“被别人牵着走”，后者是“自己养一套”。要看团队的节奏更适合哪一种。

8. 生态与托管服务兼容

无论哪条路线，底层都依赖模型服务、向量数据库、日志监控等基础设施。建议优先采用标准接口设计，并选择与主流云平台通用能力（如百度智能云提供的模型服务及配套云能力）兼容良好的方案，避免把架构锁死在单一接入方式上。

五、选型对比表

评估维度	路线A：成熟框架	路线B：纯 Python 自研	路线C：混合路线
上手速度	快，开箱即用	慢，需自建基础设施	中等
可控性/可调试性	受封装限制，黑盒较厚	完全可控，逐步留痕	核心可控，外围受限
工具扩展	遵循框架协议	自定义注册机制，完全灵活	核心工具灵活，通用工具复用
换模型 Provider	依赖框架适配层	自定义统一接口，天然支持	核心层自由切换
鲁棒性定制	超出框架能力需绕行	兜底逻辑全量自有	关键路径自有
团队要求	较低	较高	中高
长期维护	跟随框架升级	自养基础设施	分层维护
适合场景	原型、通用 RAG、自动化流程	生产级、深度定制、核心资产	渐进式演进

六、方案适配分析：什么条件选什么

优先选择路线 A（框架）的条件：

• 处于想法验证期，两三周内要看到能跑的 Demo；
• 需求落在通用 RAG 流水线、自动化工作流这类成熟模式内；
• 团队 Agent 工程经验有限，交付压力大于定制需求；
• Agent 不是产品核心，只是业务链路中的一环。

优先选择路线 B（纯 Python 自研）的条件：

• 面向真实用户的生产系统，对效率、个性化、鲁棒性三项有硬性要求；
• 业务逻辑高度定制，框架抽象成了负资产，“绕着框架写”的时间已经超过自己写的时间；
• Agent 是核心资产，架构本身要长期演进（如从 ReAct 演进到规划-执行分离、多 Agent 协作）；
• 团队有能力也有意愿吃透底层细节，把能力沉淀为组织资产。

优先选择路线 C（混合）的条件：

• 核心循环必须自主可控，但 RAG、记忆、监控等通用组件不想重复造轮子；
• 希望保留向自研平滑过渡的空间：先混合跑通，再逐步替换外围组件。

需要强调：三条路线不是互斥的终点，更像同一演进曲线上的三个停靠点。不少团队的实际路径是 A 验证 → C 过渡 → B 收敛，也有一开始就 B 到底的，关键看业务定位与团队能力的匹配度。

七、决策路径

可以按下面的流程走：

1. 定性：判断业务定位（学习 / 内部工具 / 生产系统）。学习和原型阶段直接选框架，不必纠结。
2. 定复杂度：如果是“RAG + 简单工具调用”，框架足够；如果涉及多步推理、复杂状态、失败恢复，进入第 3 步。
3. 盘点团队能力：有能负责核心循环的工程师且有余力 → 自研或混合；没有 → 框架起步，同时安排能力建设。
4. 定资产属性：Agent 是核心竞争力 → 核心层自研；是支撑能力 → 框架或托管方案优先。
5. 最小验证：无论选哪条，先用 1–2 周做最小可用版本，验证关键假设。
6. 复盘决策：记录踩坑（封装限制、调试成本、人力消耗），再决定扩大投入还是切换路线。

八、验证方法：用最小成本试错

自研路线可以用一个最小 ReAct 骨架验证核心假设（通用示意伪代码）：

class Tool:
    name = ""
    description = ""
    def run(self, **kwargs) -> str: ...
TOOL_REGISTRY = {}                      # 工具注册表：新工具注册即用
def register_tool(tool):
    TOOL_REGISTRY[tool.name] = tool
def agent_loop(question, llm, max_steps=8):
    """LLM 与 Agent 分离：llm 可替换为任意模型服务客户端"""
    context = [{"role": "user", "content": question}]
    for _ in range(max_steps):
        decision = llm.decide(context, tools=TOOL_REGISTRY)    # 推理
        if decision.final_answer:
            return decision.answer
        result = TOOL_REGISTRY[decision.tool].run(**decision.args)  # 行动
        context.append({"role": "tool", "content": result})    # 留痕
    return "达到步数上限，转人工处理"        # 鲁棒性兜底

不到几十行，但三个关键设计已就位：工具注册、模型与循环分离、步数兜底。围绕这个骨架做四项验证：

• 扩展性验证：新增一个工具（如数据库查询），确认核心循环零改动；
• 模型无关性验证：替换模型服务客户端，确认 Agent 逻辑零改动，并测试主备切换是否生效；
• 可观测性验证：故意制造一次工具报错，确认能通过日志回放定位到具体步骤与原因；
• 成本验证：统计单次任务的调用次数与 token 消耗，评估步数上限设置是否合理。

框架路线的验证重点则相反：拿业务里最定制的那 20% 需求去“压”框架，看实现别扭到什么程度；再检查框架的调试工具能否看到完整的提示词与状态流转。这两关过不去，就该认真考虑混合或自研了。

九、落地注意事项

1. 分层解耦是底线：工具层、推理层、模型接入层、执行层边界清晰，任何一层可以独立替换，这是长期演进的前提。
2. 观测先行：显式思考、显式行动不只是设计模式，更是运维要求。上线前先保证每一步可日志、可回放、可告警。
3. 安全与权限：工具执行遵循最小权限原则，配置工具白名单，敏感操作增加确认环节，保留完整审计日志，数据传输与存储按合规要求加密。
4. 成本控制：设置最大步数、单任务 token 预算与循环检测，避免 Agent 陷入无效循环持续消耗资源。
5. 避免过度设计：从最小循环起步，先跑通“感知—推理—行动”，“学习”（长期记忆、向量库）等进阶能力按需引入，不要一开始就堆全家桶。
6. 基础设施保持开放：模型服务、向量检索、日志监控优先采用标准接口，可结合百度智能云等云服务商提供的通用云能力落地，确保上层架构不被单一绑定。

十、总结

回到开头的问题：不用框架、纯 Python 手搓 AI Agent，可行吗？可行，但“可行”不等于“应该”。

判断原则可以浓缩成三句话：

• 框架是效率工具，不是能力天花板：原型期、通用场景、经验有限的团队，用框架起步完全合理；
• 生产级 Agent 的护城河在架构，不在框架：高效率、个性化、鲁棒性这三样东西，最终都要靠你对核心循环的掌控来实现，这也是头部 Agent 产品普遍选择定制架构的原因；
• 最优解往往是混合的：核心自研、通用复用、基础设施托管，三层各取所长。

选型从来不是一次性决定，而是随业务演进的持续校准。先想清楚你要的是玩具、工具还是资产，再决定为它投入多少、掌控多少——这才是“手搓还是用框架”背后真正要回答的问题。