后框架时代：用 API 客户端和 While 循环构建智能体

当今生产环境中最有效的 AI 智能体看起来与框架演示完全不同。它们不是拥有十七种节点类型的有向无环图，也不是通过消息总线协调的多智能体集群。它们是一个提示词、一个工具列表和一个 while 循环——它们比框架重型的对手交付更快、故障更少、维护成本更低。

这不是为了标新立异。这是一个又一个团队在花费数周时间进行框架迁移、抽象调试和 DSL 考古之后得出的结论。这种模式如此一致，值得给它一个名字：后框架时代。

框架陷阱

每个智能体框架都讲述同样的故事："你可以自己写，但何必呢？"这个推销很有说服力。框架处理工具解析、重试逻辑、状态管理和提供商抽象。它们承诺你可以在不触及核心逻辑的情况下切换模型、添加记忆并扩展到多智能体系统。

现实却不同。当你需要稍微偏离框架的愉快路径时——自定义重试策略、非标准的工具响应格式、特定提供商的参数——你会发现自己在五层抽象中摸索，只为更改一个细节。Hacker News 上有一位开发者完美地捕捉到了这一点：他们用 80 行 Python 代码替换了整个 LangChain 流水线，并在此过程中获得了可调试性、可监控性和控制力。

这不是 LangChain 特有的问题，而是结构性的。智能体框架出现在 LLM 能力较弱、需要更多脚手架的时期——显式的思维链提示、手动输出解析、JSON 模式强制执行。具有原生工具调用、扩展上下文窗口和改进指令遵循能力的现代模型已经使许多这些抽象变得不必要。2023 年必不可少的脚手架在 2026 年已成为累赘。

最小智能体架构

将智能体剥离到其基本组件，你会得到三样东西：

• 系统提示词，定义目标、约束和行为
• 一组工具，模型可以调用它们与外部系统交互
• 一个循环，向模型发送消息，执行工具调用，将结果反馈回去，并重复直到模型发出完成信号

这就是整个架构。在 Python 中，大致是这样的：实例化一个 API 客户端，设置一个带有系统消息的对话，然后进入一个 while 循环。每次迭代将对话发送给模型，检查响应是否包含工具调用，执行它们，追加结果，然后继续。当模型用文本而不是工具调用来响应时，你就完成了。

这种模式处理了令人惊讶的大量生产用例：查询订单状态和处理退款的客户支持机器人、读取差异并发表评论的代码审查智能体、查询指标并触发警报的数据流水线监控器。这些不是玩具示例。它们是在先尝试了框架然后切换回简单循环的公司中运行在生产环境的智能体。

框架真正解决什么（以及何时需要它们）

承认简单性的力量并不意味着框架毫无价值。它们解决真实的问题——但只有三个问题真正值得付出抽象税：

跨会话的持久状态。 如果你的智能体需要在几天后恢复对话并保持完整上下文，你需要持久状态管理。将对话历史序列化到数据库很简单，但检查点中间执行状态（调用了哪些工具、完成了哪些子任务、智能体计划下一步做什么）确实很难。LangGraph 的状态图模型很好地解决了这个问题。

人机协作工作流。 当智能体在执行高风险操作之前需要人工批准时——转账、删除数据、发送外部通信——你需要中断点、审批队列和超时处理。这是工作流编排，像 Temporal 甚至 LangGraph 这样的框架比手写解决方案处理得更好。

多智能体协调。 当多个专业化智能体需要相互发现、协商任务所有权、共享中间结果并处理部分故障时，你正在构建一个分布式系统。消息传递、状态检查点、交接协议和故障恢复是真正的工程挑战，受益于共享基础设施。

对于其他一切——大约覆盖 80% 的生产智能体部署——while 循环胜出。大多数智能体不需要持久的多会话状态。大多数不需要人工审批门。大多数是具有明确任务和固定工具集的单一智能体。给这些智能体添加框架就像用 Kubernetes 来运行一个 cron 任务。

抽象税

你和 LLM API 之间的每一层抽象都会在项目的生命周期中产生累积成本：

调试不透明性。 当你的智能体产生错误输出时，你需要了解发生了什么。通过直接 API 调用，你可以记录发送和接收的确切消息，检查工具调用参数，并用 curl 命令重现问题。通过框架，你需要在链执行器、回调处理器和状态转换器中追踪，以重建模型实际看到的内容。

升级脆弱性。 框架发布破坏性更改是因为底层模型在变化。当提供商添加新参数、更改工具调用格式或弃用端点时，框架必须适应——而你的代码必须适应框架的适应。通过直接 API 调用，你阅读变更日志并更新一行代码。

认知开销。 每个框架都引入自己的词汇：链、可运行项、图、节点、边、智能体、团队、流。新团队成员必须先学习框架才能理解智能体。while 循环模式是自文档化的。初级工程师可以在几分钟内阅读并理解正在发生什么。

性能拖累。 框架通过序列化、反序列化、中间件执行和回调调用增加延迟。对于单个工具调用，这可以忽略不计。对于在循环中进行 20 次工具调用的智能体，开销会累积——在延迟和令牌成本方面都是如此，当框架注入自己的系统提示或格式时。

使简单智能体达到生产就绪的模式

while 循环是基础，但生产智能体需要在其上层叠加一些模式：

结构化错误处理。 当工具调用失败时，将错误作为工具结果追加，让模型决定该怎么做。模型在从错误中恢复方面出奇地好——用不同的参数重试、尝试替代工具或要求用户澄清。不要构建重试框架；让模型成为重试逻辑。

令牌预算管理。 长时间运行的智能体可能耗尽上下文窗口。跟踪每次迭代的令牌使用量并实施简单策略：当接近限制时，总结到目前为止的对话并继续使用压缩的上下文。这只需几行代码，而不是一个记忆子系统。

明确的工具文档。 工具描述的质量比任何框架功能都重要。将工具描述视为面向外部开发者的 API 文档。包括参数类型、预期格式、示例输入和失败模式。具有良好文档的工具加简单循环的性能优于文档不佳的工具加复杂编排器。

执行追踪。 记录每个模型调用、工具调用和结果。不是以框架特定格式——而是以纯粹的结构化 JSON，你可以用标准工具进行 grep、过滤和分析。这个追踪就是你的调试器、分析器和审计日志。

成本守卫。 设置每次智能体运行的最大迭代次数和最大令牌消耗。当达到任一限制时，返回智能体拥有的任何部分结果并标记该运行以供审查。这可以防止困扰自主智能体的无限循环故障模式。

最好的智能体代码看起来像无聊的应用程序代码

最成功的智能体部署不会让会议演讲激动人心，这是有原因的。它们看起来像普通的后端服务：请求进来，一些 API 调用在循环中发生，结果被返回。业务逻辑在提示词和工具中，而不在编排层中。

这是关键洞察。智能在模型中，而不在框架中。作为开发者，你的工作是给模型清晰的指令、有用的工具和简单的执行循环。其他一切都是仪式。

后框架时代并不意味着框架消失。它意味着它们退回到它们真正解决的狭窄问题集——持久状态、人机协作、多智能体协调——并停止假装是通用智能体基础设施。对于绝大多数智能体，正确的架构是你能装在脑子里的那个：一个提示词、一些工具和一个 while 循环。

从这里开始。只有当你有一个简单性无法解决的具体问题时才增加复杂性。你会惊讶于这种情况发生得多么少。