【跳出框架思维，搭建灵活Agent架构】

快速阅读：大多数 Agent 团队在开发时并非在“构建”架构，而是在“套用”框架。这种将编排、记忆、工具调用等功能打包成黑盒的模式，导致团队在需要定制化时只能通过痛苦的 Fork 或绕路来解决。真正的架构应该是可插拔的组件集合，通过统一的协议实现功能的自由组合。

大多数 Agent 团队其实并没有在构建自己的架构，他们只是在“搬运”现成的框架。

当你选择 LangChain 或 AutoGen 时，你其实是在做一个单选题：你把模型编排、记忆管理、工具调用和凭证管理全部打包成了一个无法拆解的单体。这就像买了一台封装好的一体机，如果其中一个接口不符合你的需求，你不是在修改它，而是在跟它搏斗。

这种设计逻辑本身就有问题。一个生产级的 Agent 架构其实包含十几个独立的职责，比如权限检查、预算追踪、会话持久化、甚至是 OpenTelemetry 的链路追踪。在目前的生态里，这些职责被强行捆绑在一起，因为缺乏一种能够让它们互相协作的底层机制。

有意思的是，当团队规模扩大、需求变复杂时，几乎所有人都得经历一次痛苦的过程：从零开始重写整个架构。

如果把架构看作是一组运行在共享引擎上的 Worker，情况就完全不同了。

在这种模式下，架构不再是一个沉重的黑盒，而是一堆可以独立版本化、独立替换的插件。你需要不同的权限引擎？换掉它，只要它注册了相同的函数 ID。你想把审批流程从控制台挪到 Slack？写一个新的 Worker 接入即可。

这让“构建自己的架构”不再意味着“Fork 一个框架”，而是意味着“组合几个 Worker”。

架构的厚度不再是一个非黑即白的抉择，而是一个可以调节的滑块。你可以只安装最基础的组件跑实验，也可以通过叠加预算管理、策略引擎等 Worker 来构建应对复杂业务的重型架构。

这种组合性带来的好处是，即便你对某个组件进行了大规模重构，只要它对外的协议没变，整个系统的其他部分依然稳如泰山。

这种架构设计的本质，其实是把“构建”这个动作从“修改代码”降级到了“配置组件”。

目前的困境在于，我们还在试图通过增加框架的功能来解决问题，而真正的解法可能是拆解这些功能。

x.com/mfpiccolo/status/2060069083878408689