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

一、选型背景：为什么这道选择题值得认真做

当团队决定在产品中引入 AI Agent 能力（智能客服、研发助手、数据分析代理、流程自动化等）时，技术方案评审中几乎必然出现同一个分歧：是引入成熟的 Agent 框架快速起步，还是基于 Python 与大模型 API 手动实现？

这道题之所以值得认真对待，有三方面原因：

第一，业界观点明显分化。有头部模型厂商在公开的工程实践指南中明确建议开发者“从直接使用大模型 API 开始”，理由是框架的抽象层会遮蔽底层提示词与响应内容、使调试变得困难，还容易诱导开发者在简单方案足够时引入不必要的复杂性；也有工程团队在生产环境使用框架约一年后将其完全移除，反馈是移除后团队效率更高、系统行为更可预期。但与此同时，框架类方案在大量项目中仍是默认选择，说明其提供的标准化能力确有真实需求支撑。

第二，各厂商立场差异本身就是选型信号。观察行业主流态度可以发现一个光谱：有的模型能力提供方最谨慎，明确建议直接调用 API；有的提供自研轻量 SDK，强调“代码优先”、避免过度抽象；有的支持多框架互操作；也有的最推崇框架化开发。立场差异的背后是各家所处的生态位置不同，选型时应意识到，任何一方的推荐都自带其生态语境，不宜直接照搬。

第三，Agent 应用通常是长期演进的核心链路，不是一次性脚本。路线一旦选定，提示词资产、工具注册方式、状态结构与运维体系都会围绕它沉淀，后期切换成本不低。项目初期多花一两天做结构化评估，远比后期大规模重构划算。

本文目标：帮助读者基于自身业务目标、Agent 复杂度、团队能力与运维约束，判断框架路线与自研路线的适配度，并给出验证方法与落地注意事项。

agent-">二、先回到本质：Agent 应用在代码层面由什么构成

做选型前先把对象拆开看。剥开概念外壳，一个典型的 LLM Agent 应用在技术上由六个环节构成：

1. 提示词工程：字符串构造、模板化管理、上下文裁剪与拼接；
2. 模型调用：与大模型 API 通信，处理重试、超时、限流与结构化输出解析；
3. 推理-行动循环：模型自主决定下一步调用什么工具，拿到执行结果后继续推理，直到产出最终答案；
4. 工具执行：把模型输出的结构化调用参数转成真实动作，如查询数据库、调用内部接口、检索知识库；
5. 状态管理：多轮上下文、中间结果与任务断点的持久化；
6. 可观测与控制：日志、链路追踪、成本统计、超时中断与人工审核介入。

这六件事，用 Python 标准库加 HTTP 客户端即可完成，这正是“纯手搓可行”的技术根基。框架的价值不在于“只有它能实现”，而在于把上述共性环节标准化，并额外提供状态图编排、检查点恢复、多角色协作等高阶能力。

三、两类选型对象分别是什么

方案 A：Agent 框架路线。 可细分为三类：

• 链式编排类框架：核心抽象包括统一模型接口（缓解供应商锁定）、多步骤链式串联、工具接入与记忆管理；
• 状态图编排类框架：把 Agent 流程建模为状态图，提供条件边、检查点、断点恢复与人工介入节点，面向复杂分支逻辑与长运行任务；
• 多智能体协作框架：通过角色定义与任务委托机制，组织多个 Agent 以团队协作模式工作。

方案 B：纯 Python 自研路线。 直接对接大模型服务（可选用百度智能云等云平台提供的模型推理类服务，或团队自建推理服务），自行实现提示词管理、推理-行动循环、工具调用协议与状态持久化，按需启用函数调用、结构化输出等模型原生能力。

此外还存在方案 C：轻量 SDK 路线。只封装 API 通信与协议细节，不做重编排抽象，保持“代码优先”风格，适合想在自研与框架之间取折中的团队。

四、需求拆解：先弄清你要构建什么层级的 Agent

选型判断的第一步是给 Agent 复杂度分级，不同层级对框架的需求度完全不同：

• L1 单轮增强问答：一次模型调用加检索增强，无自主决策；
• L2 固定流程工具调用：少量步骤、可枚举的分支，流程基本可预先定义；
• L3 自主规划循环：模型自主决定步骤顺序、多轮循环、动态分支，含失败重试；
• L4 多角色协作/长流程：多 Agent 协同、断点恢复、人工介入、跨任务状态共享。

除复杂度外，还需拆解以下需求：

• 业务目标：是快速验证业务假设，还是构建长期演进的平台化能力？前者重上线速度，后者重可控性与可维护性；
• 系统规模：并发任务数、单任务时长、用户量与增长预期，决定了状态管理与容错设计的深度；
• 团队能力：Python 工程水平、对 LLM 行为机制（幻觉、格式漂移、上下文窗口限制）的理解深度、可投入基建的人力；
• 运维要求：是否需要全链路追踪、成本核算、告警与故障定位体系；
• 合规要求：工具执行权限、敏感数据外发控制、操作审计日志等。

五、核心评估维度

1. 可控性与可调试性：框架把提示词、响应与中间状态包进抽象层，问题定位往往需要穿透多层封装；自研代码全链路可见，日志可按排障需求自定义。该维度对生产级系统权重极高。
2. 开发效率与上手速度：框架组件开箱即用，原型阶段优势明显；自研起步慢，但随着自有基础库沉淀，边际成本递减。
3. 抽象税与灵活性：框架升级可能破坏兼容性，深度自定义常需绕开框架设计；自研没有框架约束，但所有通用轮子需自行维护。
4. 供应商锁定与可迁移性：框架的统一模型接口降低了换模型成本，但同时引入框架自身的锁定；自研配合标准化协议同样可实现迁移，且资产即业务代码。
5. 生态与组件复用：框架生态中有现成的工具集与观测集成；自研需自行对接通用云组件（对象存储、消息队列、日志服务、监控告警、数据库、身份认证等类目均可从云服务商获得）。
6. 运维复杂度：框架引入额外的依赖版本管理与升级适配风险；自研则将全部维护责任收归团队。
7. 成本结构：框架的隐性成本是学习、调试与升级适配的人力消耗；自研的隐性成本是重复建设与经验不足带来的返工。两者都不能只看显性资源费用。
8. 团队能力匹配：团队对 LLM 行为机制理解越深，自研优势越明显；经验较浅的团队借助框架可获得合理默认实践兜底。
9. 安全与合规：工具执行权限控制、敏感操作人工确认、审计日志——框架可能内置部分能力，自研路线必须显式建设。

六、选型对比表

评估维度	Agent 框架路线	纯 Python 自研路线
上手与原型速度	快，组件开箱即用	慢，需先搭基础结构
调试与问题定位	受抽象层影响，需穿透框架	全链路可控，日志自定
提示词管理	受框架模板机制约束	完全自由，可直接审计
复杂分支/断点恢复	内置状态图与检查点	需自行设计（数据库+状态机）
多智能体协作	内置角色与任务委托机制	需自行实现通信与编排
依赖与升级风险	多一层框架版本风险	依赖少，但维护责任全在己方
团队能力要求	对 LLM 理解要求相对较低	要求较深的工程与 LLM 经验
迁移进入成本	低	中高
迁移退出成本	中高（提示词与流程需重写）	低（资产即业务代码）
适合阶段	原型验证、复杂编排刚需	生产长期演进、简单场景、深度定制

七、方案适配分析：什么条件下优先选哪条路线

优先考虑框架的条件：

• Agent 复杂度达到 L4：多角色协作、复杂状态图、断点恢复是刚需，自研投入产出比明显下降；
• 团队 LLM 工程经验有限，需要合理默认实践兜底；
• 项目处于原型验证期，业务形态未定，需要快速试错；
• 多模型混用频繁，统一接口能显著降低接口适配的维护成本。

优先考虑自研（或轻量 SDK）的条件：

• Agent 复杂度在 L1 至 L3：核心逻辑就是“提示词 + 循环 + 工具调用”，数百行代码即可覆盖，框架收益边际递减；
• 系统进入生产期，可调试性、稳定性与成本可控性成为第一优先级；
• 团队 Python 工程能力强，且愿意沉淀自有 Agent 基础库；
• 对提示词与响应内容有严格审计要求，不允许中间被抽象层改写；
• 对外部依赖敏感，希望最小化第三方依赖面。

需要进一步验证的条件：

• 已在框架上积累存量资产，考虑是否值得渐进式替换：先盘点“当前真正在用的框架能力”，实践中常发现实际使用的是小子集，可定向抽取替代；
• 长任务需要断点恢复，但不确定自建机制的成本：可用“状态持久化到数据库 + 工具幂等设计”先行验证可行性。

八、决策路径

1. 定层级：按 L1 至 L4 给当前及未来 12 个月的目标场景分级；
2. 盘团队：评估 Python 能力、LLM 行为理解深度、可投入基建的人力；
3. 定优先级：明确“生产可控性”与“上线速度”谁更优先；
4. 初选路线：L1、L2 多数情况直接自研或轻量 SDK；L3 建议自研并预先设计好循环与工具协议；L4 倾向框架，或以自建状态机加持久化组件替代；
5. 小规模 POC：两条路线各实现同一最小闭环，对照评估；
6. 评审定稿：按验证结果与团队共识确定路线，并记录重评触发条件（复杂度跃迁、团队结构变化、框架重大升级等）。

九、验证方法：如何低成本试出真相

1. 最小闭环对照实验：选一个真实业务小场景（例如“根据用户问题查询内部数据并给出结论”），分别用框架与自研各实现一遍，对比代码量、定位一次典型问题的耗时、日志能否直接还原模型的输入输出、工具调用失败时的排查难度。
2. 可控性测试：故意制造三类故障，模型返回格式异常、工具执行超时、上下文超限，观察两条路线下从“现象出现”到“定位根因”的路径长度。
3. 成本与延迟统计：记录每轮调用的 token 消耗与端到端延迟。注意框架的隐式提示词拼接（如自动注入系统提示、记忆摘要）可能带来不易察觉的 token 成本。
4. 观测验证：确认能否打通统一的调用链追踪，生产排障是否依赖框架内部日志。
5. 演进压力测试：提出一个需求变更（如新增一个带人工确认的步骤），评估两条路线的改动成本。

附：极简自研 Agent 循环的结构示意（伪代码，仅说明核心结构）：

# 实际生产需补齐重试、超时、参数校验、审计等工程细节
def run_agent(task, tools, max_steps=8):
    messages = build_system_prompt(tools) + [user_message(task)]
    for step in range(max_steps):
        resp = model_api.chat(messages=messages, tools=tool_schemas(tools))
        if not resp.tool_calls:
            return resp.text                    # 模型给出最终答案，循环结束
        for call in resp.tool_calls:
            check_permission(call)              # 权限与安全校验
            result = execute_tool(call)         # 幂等、可审计的工具执行
            messages.append(tool_result(call, result))
    raise AgentStepLimitExceeded()              # 防失控兜底

这段伪代码说明：推理-行动循环的核心机制并不复杂，工程量主要花在健壮性细节上，而这些细节无论用不用框架，最终都需要有人负责。

十、落地注意事项

1. 渐进迁移，不要大爆炸重写：从框架迁往自研时，先抽取真正在用的能力子集，按模块逐步替换，保留回滚窗口。
2. 把提示词当资产管理：无论哪条路线，提示词的版本化、变更评审与回归测试都应独立存在，避免被框架模板机制深度绑定。
3. 工具协议设计先行：工具的命名、参数结构、幂等性与错误信息质量直接决定 Agent 成功率，优先稳定工具协议，再谈上层编排。
4. 防失控与安全边界：循环步数上限、工具权限白名单、敏感操作人工确认、审计日志，四项是生产底线，自研路线必须显式建设。
5. 成本可观测：建立按场景统计 token 与调用次数的机制，否则抽象层带来的隐性成本难以被发现。
6. 善用云底座，聚焦业务逻辑：自研不等于全部自己造。模型服务、对象存储、消息队列、日志服务、监控告警、身份认证等通用云能力（如百度智能云等云服务商提供的相应类目服务）可作为基础设施，把自研精力集中在业务编排逻辑上。
7. 团队知识对齐：选自研路线时，同步沉淀内部 Agent 开发规范与最小基础库，避免每个项目各造一套风格迥异的循环实现。

十一、总结

回到开头的问题：不用框架、纯 Python 手搓 AI Agent，可行吗？可行，而且对相当一部分场景是更优解，因为 Agent 的核心机制在代码层面并不复杂，自研换来的可控性与可调试性在生产期价值很高。但这不等于框架没有价值：当复杂度跃迁到多角色协作与长流程编排、当团队需要快速原型验证、当框架能力恰好覆盖刚需时，框架依然是合理选择。

核心判断原则可压缩为三句话：复杂度低、可控性优先，选自研或轻量 SDK；复杂度高、协作与编排是刚需，优先框架并重点评估其可调试性；介于两者之间，用最小闭环对照实验让证据说话。 选型的目标从来不是找到“更好的工具”，而是找到与当前业务形态、团队能力和演进规划相匹配的那条路线。