不要用AI框架

关键洞见：新兴技术栈（如LLM）过早抽象化是框架问题的根源。当底层技术快速演进时，轻量级、显式控制的设计比框架更能适应变化。

一、主流Agent框架的核心缺陷

1. 黑盒执行与不可观测性
   • 框架封装了执行过程（如agents.start()），开发者无法监控中间步骤。
   • 导致问题：调试困难、性能瓶颈难定位、错误根因不透明。
   • 对比方案：显式分步控制（step1() → step2() → step3()），每一步可追踪。
2. 过度抽象带来的认知负担
   • 框架强制开发者适应其抽象概念（Agents/Crews/Conversations），而非聚焦业务问题。
   • 后果：增加不必要的复杂度，限制解决方案灵活性（如Dify在复杂场景下连线混乱、迭代困难）。
3. 性能与稳定性风险
   • CrewAI:
   • 容易卡在 “THINKING” 状态，导致生产系统冻结，需要人工干预。
   • Agent 状态持久化存在问题，导致数据丢失和行为不一致。
   • 日志记录困难，调试困难。
   • Agent 失败时没有错误消息，无法进行生产监控。
     • LangGraph:
   • 严重的内存泄漏，长时间运行后性能下降甚至崩溃。
   • LLM 运行速度变慢，原因不明。
   • 调试困难，需要分析难以理解的状态转换。
   • 信息过时或缺失关键细节。
     • AutoGen:
   • 容易进入意外循环，消耗大量 Token，导致成本超支。
   • 缺乏安全措施，Agent 容易访问生产数据库。
   • 扩展性差，需要设计复杂的架构。

   • 缺乏专门的支持。

二、Agent框架的本质与局限

graph LR
A[Agent框架核心组件] --> B[LLM“大脑”]
A --> C[工具 API/数据]
A --> D[提示词逻辑]

• 问题根源：框架试图将动态技术（如快速迭代的LLM）封装进静态抽象层，导致：
  • 技术栈升级时框架迅速过时。
  • 业务逻辑被框架设计绑架。

三、替代方案：直接API编排架构

核心模式

输入 → 预处理 → LLM调用1 → 验证 → LLM调用2 → 后处理 → 输出

关键实践原则

1. 显式状态管理
   • 使用Python字典或DataClass存储状态。
   • 每一步输入/输出明确可见，杜绝黑盒。
2. 直接API调用
   • 原生调用OpenAI/Anthropic等API。
   • 手动实现重试、超时、限流处理（例见代码片段）。
3. 管道式函数编排
   • 每个步骤拆解为独立函数，通过数据流串联。
   • 添加全链路日志（关键优势：按业务需求定制指标）。

# 示例：带监控的LLM调用
def process_request(input_data):
    logger.info(f"Processing: {input_data}")
    try:
        result = call_llm(input_data)  # 原生API调用
        logger.info(f"LLM响应耗时: {response_time}ms")
        return result
    except RateLimitError as e:
        logger.error(f"限流异常: {e}")
        return handle_rate_limit()  # 显式降级处理

四、从零构建的核心优势

1. 可维护性
   • 组件隔离：单步骤可独立测试/扩展（如替换LLM版本无需重构全流程）。
2. 可控性
   • 自定义失败处理（如验证失败时重试特定步骤）。
3. 技术理解深化
   • 避免框架“魔法”，迫使开发者掌握LLM交互底层逻辑。
4. 性能优化
   • 精准定位瓶颈（如日志标记某LLM调用延迟过高）。

五、何时需谨慎使用框架

| 场景 | 框架风险 | 推荐方案 | |————————-|—————————|———————| | 高频迭代业务需求 | 抽象层阻碍快速适配 | 直接API编排 | | 复杂状态流转 | 黑盒调试困难（如Dify变量失控）| 显式状态机+日志 | | 企业级成本控制 | 隐藏开销（如AutoGen成本失控）| 原生API+用量监控 |

灵感原文: https://medium.com/aiguys/leave-agentic-ai-frameworks-and-build-agents-from-scratch-0a45d1656513