前阵子在一个技术群里有人抛出一个问题现在开源智能体框架那么多自建一个到底还有没有价值底下很快分成两派。一派直接说没有纯属重复造轮子另一派犹豫了一下说要看场景。我属于后者。今天想把这件争议拆开聊一下。我的判断是自建智能体框架的价值不在“重复实现”别人已经做好的能力而在它给了你一条让智能体从 demo 走向生产环境的可控路径。但这里有个前提我们得先把“自建”这件事说清楚。1. 先厘清争论反对的人到底在反对什么1.1 一个常见但容易混淆的靶子“自建智能体框架无价值”这句话之所以很难直接反驳是因为每个人脑子里预设的“自建”不一样。如果你说的是从零写一个通用 Agent 框架自己实现模型调用、Tool 解析、记忆存储、多智能体通信还要求生态像 LangChain、AutoGen 一样丰富那绝大多数项目确实不应该这么干。开源社区已经帮你踩了很多坑工具集成、模型适配、Prompt 模板都有现成参考重新实现一遍大概率是浪费时间也基本做不过有大量贡献者的社区。但如果你说的“自建”不是这个意思而是在业务系统内部构建一个只属于你自己团队的智能体编排层那价值就被严重低估了。它不一定需要从零实现大模型接入也不一定需要重写向量数据库它只要把你业务中反复出现的任务拆解、工具调用、上下文拼装、模型调度、权限校验、日志追踪收拢在一起就足以解决通用框架覆盖不到的问题。这两种“自建”指向的是完全不同的工作量、成本和收益。争论常常停留在“造不造轮子”的层面恰恰忽略了这一点。1.2 不同语境下的“无价值”各有各的道理我见过几个典型的反对场景它们并不是没有道理。第一种是时间驱动型反对。团队要在两周内交付一个智能客服 demo你这个时候说要自建框架当然会被质疑。开源框架能快速链一个流程产品可以先验证交互逻辑。这时候自建确实“无价值”因为它拖慢了验证速度。第二种是生态驱动型反对。LangChain 这类框架已经有大量现成的 Tool 集成、Agent 策略、模型提供商封装你自建一个工具注册表功能可能还不到它的 10%。对很多通用任务来说重复造这部分就是给自己挖坑。第三种是维护成本驱动型反对。自建框架意味着你会长期维护它。模型接口更新了你要改Tool 调用不稳定你要查团队换人新同学要先读你的内部代码。如果业务规模不够大这些成本会吃掉你通过自建省下的所有效率。这三种反对都有事实支撑。但它们都建立在一个共同的假设上你的智能体场景非常通用通用到可以直接用一套开源框架解决。可很多真实业务并不符合这个假设。1.3 价值判断的前提是定义所以我想先把讨论边界限定下来本文说的“自建智能体框架”指的是面向具体业务场景的智能体编排层。它可能包含这些模块任务输入与目标解析工具注册与调用封装模型服务接入与降级多轮上下文管理日志、追踪、审计权限控制和数据合规校验它不包含这些模块从零实现一个 LLM从零实现向量检索算法重新复刻所有第三方工具集成如果你认可这个定义那么“自建智能体框架是否无价值”就不再是一个二元问题而是一个边界问题你的业务有没有复杂到需要一个内部编排层你的团队有没有能力长期维护它你的场景能不能接受被通用框架统一兜着走2. 自建智能体框架真正解决的问题不是“造轮子”2.1 可控性从“能跑”到“知道为什么这样跑”我最早接触开源智能体框架时第一感受是“真快”。写一个 Agent调用几个工具生成一段回复半小时就能跑通。但放到真实项目里很快会遇到一个更麻烦的问题它为什么会给出这个结果通用框架为了适配所有人通常会封装掉很多内部细节。你看到的是 model 调用、agent.run()、tool.execute()但中间模型到底怎么选工具、Prompt 是怎么拼的、上下文有没有超限、某一次 Call 到底消耗了多少 token、某一步重试是什么原因往往只能靠黑盒观察。自建一个轻量级编排层的核心收益就是把不可观察的部分变成可观察、可中断、可干预的流程。我自己在实现智能体应用时会要求每次 Agent 执行都留下清晰的轨迹当前任务是什么模型看到了哪些工具描述模型决定调用哪个工具工具返回了什么结果上下文是否被截断距离最大轮数还剩多少这些信息在开源框架里不一定完全没有但要拼出完整链路通常需要你在框架外面做大量适配。与其和框架的内部约定斗争不如在最外层自己封装一层追踪机制。这个“层”的成本并不高但它决定了你是靠日志做工程还是靠猜做工程。2.2 业务集成为你的数据、权限和流程定制通用智能体框架擅长对接公开 API但企业内部的智能体往往不是这样。举个例子你做一个内部知识库问答智能体第一步不是直接调模型而是先查当前用户的权限角色确认他有没有权限读取某些文档。然后还要判断他请求的文件是否包含敏感信息如果有要先把脱敏规则嵌入结果。最后涉及对外发布的回复还要经过一个审批接口。这些步骤每个企业都不一样通用框架不可能替你完成。如果你直接把开源框架拿进来常见结果有两个要么你要在框架外面写一大堆胶水代码把业务逻辑和 Agent 逻辑纠缠在一起要么你要为框架扩展大量的自定义回调一旦框架版本升级回调接口一变你的业务代码也跟着遭殃。自建一个“只属于你的业务”的编排层可以把这些流程统一收敛起来。模型只负责理解和生成业务校验、权限检查、数据脱敏、审批动作全部沉淀在你的组件里。这个结构不是“造轮子”而是给你的业务做一个稳定的控制面。2.3 长期演进不被上游版本的节奏绑架大部分开源框架迭代非常快。今天你觉得它接口挺好三个月后它可能因为架构调整把所有 Agent 策略都改了。你原本基于它写的流程就要被迫迁移。我不是说开源框架不好而是说当你的业务已经稳定运行你就需要一段缓冲层来隔离上游变化。自建框架的一大价值就是这个缓冲层。你可以把模型供应商封装成一个统一接口内部业务只依赖接口不依赖某个具体 SDK。今天你接的是模型 A明天想切到模型 B只要改适配层业务代码不用动。今天你用的编排策略是 ReAct明天想换成 Plan-and-Execute底层框架只改一个执行器其他模块不受影响。这种“隔离变化”的能力在没有自建层时往往不具备。你只能跟着框架走让它牵着你的技术节奏。一旦你开始追求生产环境稳定性“可替换”“可迁移”“可降级”这些词就会变得比“跑通 demo”重要得多。3. 什么情况下自建才有价值一套判断标准3.1 业务复杂度足够高复用半径足够大自建框架不是一种精神信仰它应该被当作投资。既然是投资就要看回报。我建议你先回答三个问题你现在有多少个智能体场景这些场景会不会在未来 6 到 12 个月内持续迭代这些场景之间是否有共享的逻辑比如工具调用、权限校验、上下文管理如果三个答案都是否只有一个小工具、一次性的演示那确实没必要自建。直接用开源框架能跑就行。但如果你的业务线会有多个智能体落地比如智能客服、内容审核助手、代码辅助 Agent、内部报表问答它们背后的工具注册、日志追踪、权限控制、模型调用方式高度相似那你就值得搭一个公共层。判断标准可以很简单复用半径大于维护成本自建才有意义。复用的次数越多维护成本被摊得越薄。3.2 团队有明确的“所有权”意识和工程基础另一个容易被忽略的条件是团队。自建框架最怕的不是代码写得烂而是团队没有长期认领它的意愿。我见过一些内部项目框架代码写得很漂亮但团队把它当成一次性交付后面没人维护、没人加注释、没人定期更新模型接口半年后基本成了“临时遗产”。这样的自建确实无价值。要判断团队适不适合自建可以看三件事有没有人有能力负责这个框架的持续演进。有没有人愿意为其他业务方提供使用文档和支持。有没有建立基本的质量保障机制比如单元测试、集成测试、日志规范和版本发布流程。如果这三点都做不到不如直接用开源框架。至少框架出问题时社区可以帮你兜底而自建框架出问题时你只能自己扛。3.3 一个判断表开源框架、半自建、全自建这里我给你一个比较具体的参考表。它不是铁律但可以帮你快速定位自己的处境。场景建议理由快速原型验证直接用开源框架时间成本最低社区案例多单一场景但需要对接内部系统半自建保留通用框架做模型调用自建工具和权限层多个场景、长期迭代、需要统一观测全自建编排层可控性收益大于维护成本团队规模小、无运维能力优先开源框架自建会透支人力数据合规、审计要求高全自建编排层需要完全掌控数据流转和日志“半自建”在真实项目里出现的频率可能最高。很多人把“自建”和“全自建”划等号其实没必要。开源框架处理通用任务自建层处理业务共性两者可以共存。4. 用最小成本自建一个轻量级智能体框架4.1 不是从零复刻 LangChain而是沉淀自己的编排层如果你想尝试自建我建议不要从网上那些全功能框架开始。真正务实的路径是从一个最小闭环开始慢慢抽象出自己的结构。先想清楚一件事你的智能体本质上是什么在我看来它就是一个持续循环的流程接收一个任务。向模型提供“任务描述 可用工具 当前上下文”。模型决定调用哪个工具或者直接给出回答。执行工具把结果追加到上下文。重复直到达到终止条件。自建框架不用对这个流程做太多复杂设计你只需要把每一步变成明确的对象和函数然后加上日志和异常处理。4.2 核心模块怎么设计我给过一个最小设计你可以参考。这里用 Python 代码示意具体实现你可以根据团队技术栈调整。from dataclasses import dataclass, field from typing import Any, Callable dataclass class Tool: name: str description: str parameters_schema: dict func: Callable[..., Any] dataclass class AgentContext: messages: list field(default_factorylist) remaining_rounds: int 5 class ToolRegistry: def __init__(self): self._tools {} def register(self, tool: Tool): self._tools[tool.name] tool def list_tools(self): return [{name: t.name, description: t.description, parameters: t.parameters_schema} for t in self._tools.values()] def execute(self, name: str, args: dict): tool self._tools[name] return tool.func(**args) class AgentRuntime: def __init__(self, model_client, tool_registry, loggerNone): self.model_client model_client self.tool_registry tool_registry self.logger logger def run(self, task: str) - str: ctx AgentContext() ctx.messages.append({role: user, content: task}) while ctx.remaining_rounds 0: # 由模型决定调工具还是回复 response self.model_client.generate( messagesctx.messages, toolsself.tool_registry.list_tools(), ) if self.logger: self.logger.info(model response: %s, response) if response.get(tool_call): tool_name response[tool_call][name] tool_args response[tool_call][args] try: result self.tool_registry.execute(tool_name, tool_args) ctx.messages.append({role: tool, tool_call_id: response.get(id), content: result}) except Exception as e: ctx.messages.append({role: tool, content: ftool error: {e}}) else: return response[content] ctx.remaining_rounds - 1 return 达到最大轮数任务未完成。这里有几个地方需要额外注意模型的response结构会因为供应商不同而有差异你最好在外面封装一层标准化转换。Tool 执行时不要直接信任模型生成的参数要做类型校验和权限校验。上下文不要无限追加要有截断策略否则 token 消耗会快速膨胀。这些设计看起来很简单但它已经构成了一个可扩展的编排层。后面你想增加记忆、加入重试、接入消息队列都可以基于这个骨架扩展。4.3 落地路径先跑通单场景再抽象复用很多自建框架失败不是因为设计不好而是因为一开始就想做通用平台。我建议你反过来先选一个具体场景比如“智能工单分类助手”不要管抽象直接写实现。跑通之后把代码里重复出现的部分抽出来。比如工具调用、日志记录、模型客户端、上下文拼接。第二个场景来时复用第一版抽出的组件。此时你会发现哪些设计合理哪些设计过度。当第三个场景出现你才值得把它们整合成一个内部小框架。这个顺序非常重要。它会让你的自建框架长在真实业务上而不是长在想象中。5. 自建的代价和风险同样要说清楚5.1 维护成本你购买的是控制权不是免费前面说了很多自建的好处但我也要诚实提醒你自建有一个绕不开的成本叫作“长期维护”。框架上线只是开始。模型接口变更你要适配某个工具返回异常你要在代码里补错误处理团队新成员需要读文档或现有代码你的内部 API 要跟着业务调整可能还要发版本、写迁移方案。每一样都是真实的工作量。所以我不会劝所有人自建。如果你的团队只有两个人且智能体只是业务里的一个分支功能那直接使用成熟框架把省下的时间放到业务一致性上可能更合理。自建框架更接近一次“技术投资”前期多花一些时间换取中长期的可控和复用。它适合能承受投资风险的团队不适合连基础运维都顾不上来的团队。5.2 社区生态与模型迭代的挑战开源框架的另一个优势是生态更新快。新模型一发布社区很快就有人适配好新工具一出现也很快有插件。自建框架没有这个红利你需要自己跟上模型供应商的 SDK 变化。应对方法也不难就是把模型接入做成独立适配层。你可以定义统一接口让不同供应商的 SDK 都以同样的方式接入。这样模型迭代时的变化被限制在一个小模块里不至于扩散到整条业务链。另外如果你需要新工具的集成自建也不意味着每次都要从零写。你可以自己封装一个通用 HTTP Tool把请求参数通过配置传入这样大部分内部 API 对接都可以配置化不用每个都写死代码。这比想象中简单。5.3 用“半自建”策略降低风险如果看到这里你既认可自建的价值又担心维护成本我建议你走中间路线半自建。半自建有不同层次我列个表层次开源框架负责自建负责第一层模型调用、Agent 策略业务工具、权限脚本第二层模型调用编排流、上下文管理、日志、工具注册第三层只做模型客户端全流程编排、策略、工具、观测、审计刚开始做智能体应用时可以让开源框架负责模型调用和策略你自己先专注于业务工具和权限。等团队对智能体执行流程理解得更深了再慢慢把编排层收回来。这种演进方式的好处是你始终有一条可运行的系统同时又没有把“自建”变成一项大工程。6. 我的判断别争“要不要自建”争“边界在哪里”6.1 一个可复用的决策框架每次有人问我要不要自建智能体框架我都会让他按下面这套流程判断先数一数场景数量。少于 3 个场景直接用开源框架别犹豫。再看业务耦合度。如果智能体要频繁调用内部系统、校验权限、处理敏感数据至少需要一个自建工具层和权限层。接着看团队稳定性。如果团队准备长期负责这几个场景自建编排层的回报会随着时间累积如果团队可能半年后解散那就不要为未来买单。然后看统一观测需求。你如果需要在同一个后台查看所有智能体的调用轨迹、token 消耗、失败原因靠通用框架分散日志很难管理自建会更有价值。最后看迁移成本。当你的系统已经在线上稳定运行自建一个隔离层来抵御上游框架变化很可能是最稳的选择。这五个问题并不复杂但能帮你避开两个极端一个是“闭眼自建”一个是“无脑否定”。6.2 回到最底层的经验回到文章开头那个问题。我认为“自建智能体框架无价值”这个判断在今天已经不是一句可以一概而论的话。它只有在特定假设下才成立业务通用、场景单一、团队没有长期维护计划、控制权要求低。但真实业务往往不是这样的。你需要处理内部系统、数据权限、模型切换、链路追踪、成本控制这些东西堆在一起如果不在业务边界上有一层你自己的控制面那个看似高效的智能体框架迟早会在细碎的业务差异中变得很难受。我并不是想鼓励每个人都去自研一个框架。我更想说的是先别被“造轮子”这个词吓住。在开源框架的外围用最小成本沉淀一层属于自己的编排逻辑这件事不仅有意义往往是决定智能体应用能不能从“演示得很好”变成“长期用得稳”的关键分水岭。如果你现在正在纠结这个问题我的建议很简单先挑一个真实场景跑通不加任何抽象然后看它有哪些地方是通用框架满足不了的再决定要不要自建以及自建到哪一层。这个顺序比任何争论都有用。 自建智能体框架的价值：从Demo到生产的可控路径
前阵子在一个技术群里有人抛出一个问题现在开源智能体框架那么多自建一个到底还有没有价值底下很快分成两派。一派直接说没有纯属重复造轮子另一派犹豫了一下说要看场景。我属于后者。今天想把这件争议拆开聊一下。我的判断是自建智能体框架的价值不在“重复实现”别人已经做好的能力而在它给了你一条让智能体从 demo 走向生产环境的可控路径。但这里有个前提我们得先把“自建”这件事说清楚。1. 先厘清争论反对的人到底在反对什么1.1 一个常见但容易混淆的靶子“自建智能体框架无价值”这句话之所以很难直接反驳是因为每个人脑子里预设的“自建”不一样。如果你说的是从零写一个通用 Agent 框架自己实现模型调用、Tool 解析、记忆存储、多智能体通信还要求生态像 LangChain、AutoGen 一样丰富那绝大多数项目确实不应该这么干。开源社区已经帮你踩了很多坑工具集成、模型适配、Prompt 模板都有现成参考重新实现一遍大概率是浪费时间也基本做不过有大量贡献者的社区。但如果你说的“自建”不是这个意思而是在业务系统内部构建一个只属于你自己团队的智能体编排层那价值就被严重低估了。它不一定需要从零实现大模型接入也不一定需要重写向量数据库它只要把你业务中反复出现的任务拆解、工具调用、上下文拼装、模型调度、权限校验、日志追踪收拢在一起就足以解决通用框架覆盖不到的问题。这两种“自建”指向的是完全不同的工作量、成本和收益。争论常常停留在“造不造轮子”的层面恰恰忽略了这一点。1.2 不同语境下的“无价值”各有各的道理我见过几个典型的反对场景它们并不是没有道理。第一种是时间驱动型反对。团队要在两周内交付一个智能客服 demo你这个时候说要自建框架当然会被质疑。开源框架能快速链一个流程产品可以先验证交互逻辑。这时候自建确实“无价值”因为它拖慢了验证速度。第二种是生态驱动型反对。LangChain 这类框架已经有大量现成的 Tool 集成、Agent 策略、模型提供商封装你自建一个工具注册表功能可能还不到它的 10%。对很多通用任务来说重复造这部分就是给自己挖坑。第三种是维护成本驱动型反对。自建框架意味着你会长期维护它。模型接口更新了你要改Tool 调用不稳定你要查团队换人新同学要先读你的内部代码。如果业务规模不够大这些成本会吃掉你通过自建省下的所有效率。这三种反对都有事实支撑。但它们都建立在一个共同的假设上你的智能体场景非常通用通用到可以直接用一套开源框架解决。可很多真实业务并不符合这个假设。1.3 价值判断的前提是定义所以我想先把讨论边界限定下来本文说的“自建智能体框架”指的是面向具体业务场景的智能体编排层。它可能包含这些模块任务输入与目标解析工具注册与调用封装模型服务接入与降级多轮上下文管理日志、追踪、审计权限控制和数据合规校验它不包含这些模块从零实现一个 LLM从零实现向量检索算法重新复刻所有第三方工具集成如果你认可这个定义那么“自建智能体框架是否无价值”就不再是一个二元问题而是一个边界问题你的业务有没有复杂到需要一个内部编排层你的团队有没有能力长期维护它你的场景能不能接受被通用框架统一兜着走2. 自建智能体框架真正解决的问题不是“造轮子”2.1 可控性从“能跑”到“知道为什么这样跑”我最早接触开源智能体框架时第一感受是“真快”。写一个 Agent调用几个工具生成一段回复半小时就能跑通。但放到真实项目里很快会遇到一个更麻烦的问题它为什么会给出这个结果通用框架为了适配所有人通常会封装掉很多内部细节。你看到的是 model 调用、agent.run()、tool.execute()但中间模型到底怎么选工具、Prompt 是怎么拼的、上下文有没有超限、某一次 Call 到底消耗了多少 token、某一步重试是什么原因往往只能靠黑盒观察。自建一个轻量级编排层的核心收益就是把不可观察的部分变成可观察、可中断、可干预的流程。我自己在实现智能体应用时会要求每次 Agent 执行都留下清晰的轨迹当前任务是什么模型看到了哪些工具描述模型决定调用哪个工具工具返回了什么结果上下文是否被截断距离最大轮数还剩多少这些信息在开源框架里不一定完全没有但要拼出完整链路通常需要你在框架外面做大量适配。与其和框架的内部约定斗争不如在最外层自己封装一层追踪机制。这个“层”的成本并不高但它决定了你是靠日志做工程还是靠猜做工程。2.2 业务集成为你的数据、权限和流程定制通用智能体框架擅长对接公开 API但企业内部的智能体往往不是这样。举个例子你做一个内部知识库问答智能体第一步不是直接调模型而是先查当前用户的权限角色确认他有没有权限读取某些文档。然后还要判断他请求的文件是否包含敏感信息如果有要先把脱敏规则嵌入结果。最后涉及对外发布的回复还要经过一个审批接口。这些步骤每个企业都不一样通用框架不可能替你完成。如果你直接把开源框架拿进来常见结果有两个要么你要在框架外面写一大堆胶水代码把业务逻辑和 Agent 逻辑纠缠在一起要么你要为框架扩展大量的自定义回调一旦框架版本升级回调接口一变你的业务代码也跟着遭殃。自建一个“只属于你的业务”的编排层可以把这些流程统一收敛起来。模型只负责理解和生成业务校验、权限检查、数据脱敏、审批动作全部沉淀在你的组件里。这个结构不是“造轮子”而是给你的业务做一个稳定的控制面。2.3 长期演进不被上游版本的节奏绑架大部分开源框架迭代非常快。今天你觉得它接口挺好三个月后它可能因为架构调整把所有 Agent 策略都改了。你原本基于它写的流程就要被迫迁移。我不是说开源框架不好而是说当你的业务已经稳定运行你就需要一段缓冲层来隔离上游变化。自建框架的一大价值就是这个缓冲层。你可以把模型供应商封装成一个统一接口内部业务只依赖接口不依赖某个具体 SDK。今天你接的是模型 A明天想切到模型 B只要改适配层业务代码不用动。今天你用的编排策略是 ReAct明天想换成 Plan-and-Execute底层框架只改一个执行器其他模块不受影响。这种“隔离变化”的能力在没有自建层时往往不具备。你只能跟着框架走让它牵着你的技术节奏。一旦你开始追求生产环境稳定性“可替换”“可迁移”“可降级”这些词就会变得比“跑通 demo”重要得多。3. 什么情况下自建才有价值一套判断标准3.1 业务复杂度足够高复用半径足够大自建框架不是一种精神信仰它应该被当作投资。既然是投资就要看回报。我建议你先回答三个问题你现在有多少个智能体场景这些场景会不会在未来 6 到 12 个月内持续迭代这些场景之间是否有共享的逻辑比如工具调用、权限校验、上下文管理如果三个答案都是否只有一个小工具、一次性的演示那确实没必要自建。直接用开源框架能跑就行。但如果你的业务线会有多个智能体落地比如智能客服、内容审核助手、代码辅助 Agent、内部报表问答它们背后的工具注册、日志追踪、权限控制、模型调用方式高度相似那你就值得搭一个公共层。判断标准可以很简单复用半径大于维护成本自建才有意义。复用的次数越多维护成本被摊得越薄。3.2 团队有明确的“所有权”意识和工程基础另一个容易被忽略的条件是团队。自建框架最怕的不是代码写得烂而是团队没有长期认领它的意愿。我见过一些内部项目框架代码写得很漂亮但团队把它当成一次性交付后面没人维护、没人加注释、没人定期更新模型接口半年后基本成了“临时遗产”。这样的自建确实无价值。要判断团队适不适合自建可以看三件事有没有人有能力负责这个框架的持续演进。有没有人愿意为其他业务方提供使用文档和支持。有没有建立基本的质量保障机制比如单元测试、集成测试、日志规范和版本发布流程。如果这三点都做不到不如直接用开源框架。至少框架出问题时社区可以帮你兜底而自建框架出问题时你只能自己扛。3.3 一个判断表开源框架、半自建、全自建这里我给你一个比较具体的参考表。它不是铁律但可以帮你快速定位自己的处境。场景建议理由快速原型验证直接用开源框架时间成本最低社区案例多单一场景但需要对接内部系统半自建保留通用框架做模型调用自建工具和权限层多个场景、长期迭代、需要统一观测全自建编排层可控性收益大于维护成本团队规模小、无运维能力优先开源框架自建会透支人力数据合规、审计要求高全自建编排层需要完全掌控数据流转和日志“半自建”在真实项目里出现的频率可能最高。很多人把“自建”和“全自建”划等号其实没必要。开源框架处理通用任务自建层处理业务共性两者可以共存。4. 用最小成本自建一个轻量级智能体框架4.1 不是从零复刻 LangChain而是沉淀自己的编排层如果你想尝试自建我建议不要从网上那些全功能框架开始。真正务实的路径是从一个最小闭环开始慢慢抽象出自己的结构。先想清楚一件事你的智能体本质上是什么在我看来它就是一个持续循环的流程接收一个任务。向模型提供“任务描述 可用工具 当前上下文”。模型决定调用哪个工具或者直接给出回答。执行工具把结果追加到上下文。重复直到达到终止条件。自建框架不用对这个流程做太多复杂设计你只需要把每一步变成明确的对象和函数然后加上日志和异常处理。4.2 核心模块怎么设计我给过一个最小设计你可以参考。这里用 Python 代码示意具体实现你可以根据团队技术栈调整。from dataclasses import dataclass, field from typing import Any, Callable dataclass class Tool: name: str description: str parameters_schema: dict func: Callable[..., Any] dataclass class AgentContext: messages: list field(default_factorylist) remaining_rounds: int 5 class ToolRegistry: def __init__(self): self._tools {} def register(self, tool: Tool): self._tools[tool.name] tool def list_tools(self): return [{name: t.name, description: t.description, parameters: t.parameters_schema} for t in self._tools.values()] def execute(self, name: str, args: dict): tool self._tools[name] return tool.func(**args) class AgentRuntime: def __init__(self, model_client, tool_registry, loggerNone): self.model_client model_client self.tool_registry tool_registry self.logger logger def run(self, task: str) - str: ctx AgentContext() ctx.messages.append({role: user, content: task}) while ctx.remaining_rounds 0: # 由模型决定调工具还是回复 response self.model_client.generate( messagesctx.messages, toolsself.tool_registry.list_tools(), ) if self.logger: self.logger.info(model response: %s, response) if response.get(tool_call): tool_name response[tool_call][name] tool_args response[tool_call][args] try: result self.tool_registry.execute(tool_name, tool_args) ctx.messages.append({role: tool, tool_call_id: response.get(id), content: result}) except Exception as e: ctx.messages.append({role: tool, content: ftool error: {e}}) else: return response[content] ctx.remaining_rounds - 1 return 达到最大轮数任务未完成。这里有几个地方需要额外注意模型的response结构会因为供应商不同而有差异你最好在外面封装一层标准化转换。Tool 执行时不要直接信任模型生成的参数要做类型校验和权限校验。上下文不要无限追加要有截断策略否则 token 消耗会快速膨胀。这些设计看起来很简单但它已经构成了一个可扩展的编排层。后面你想增加记忆、加入重试、接入消息队列都可以基于这个骨架扩展。4.3 落地路径先跑通单场景再抽象复用很多自建框架失败不是因为设计不好而是因为一开始就想做通用平台。我建议你反过来先选一个具体场景比如“智能工单分类助手”不要管抽象直接写实现。跑通之后把代码里重复出现的部分抽出来。比如工具调用、日志记录、模型客户端、上下文拼接。第二个场景来时复用第一版抽出的组件。此时你会发现哪些设计合理哪些设计过度。当第三个场景出现你才值得把它们整合成一个内部小框架。这个顺序非常重要。它会让你的自建框架长在真实业务上而不是长在想象中。5. 自建的代价和风险同样要说清楚5.1 维护成本你购买的是控制权不是免费前面说了很多自建的好处但我也要诚实提醒你自建有一个绕不开的成本叫作“长期维护”。框架上线只是开始。模型接口变更你要适配某个工具返回异常你要在代码里补错误处理团队新成员需要读文档或现有代码你的内部 API 要跟着业务调整可能还要发版本、写迁移方案。每一样都是真实的工作量。所以我不会劝所有人自建。如果你的团队只有两个人且智能体只是业务里的一个分支功能那直接使用成熟框架把省下的时间放到业务一致性上可能更合理。自建框架更接近一次“技术投资”前期多花一些时间换取中长期的可控和复用。它适合能承受投资风险的团队不适合连基础运维都顾不上来的团队。5.2 社区生态与模型迭代的挑战开源框架的另一个优势是生态更新快。新模型一发布社区很快就有人适配好新工具一出现也很快有插件。自建框架没有这个红利你需要自己跟上模型供应商的 SDK 变化。应对方法也不难就是把模型接入做成独立适配层。你可以定义统一接口让不同供应商的 SDK 都以同样的方式接入。这样模型迭代时的变化被限制在一个小模块里不至于扩散到整条业务链。另外如果你需要新工具的集成自建也不意味着每次都要从零写。你可以自己封装一个通用 HTTP Tool把请求参数通过配置传入这样大部分内部 API 对接都可以配置化不用每个都写死代码。这比想象中简单。5.3 用“半自建”策略降低风险如果看到这里你既认可自建的价值又担心维护成本我建议你走中间路线半自建。半自建有不同层次我列个表层次开源框架负责自建负责第一层模型调用、Agent 策略业务工具、权限脚本第二层模型调用编排流、上下文管理、日志、工具注册第三层只做模型客户端全流程编排、策略、工具、观测、审计刚开始做智能体应用时可以让开源框架负责模型调用和策略你自己先专注于业务工具和权限。等团队对智能体执行流程理解得更深了再慢慢把编排层收回来。这种演进方式的好处是你始终有一条可运行的系统同时又没有把“自建”变成一项大工程。6. 我的判断别争“要不要自建”争“边界在哪里”6.1 一个可复用的决策框架每次有人问我要不要自建智能体框架我都会让他按下面这套流程判断先数一数场景数量。少于 3 个场景直接用开源框架别犹豫。再看业务耦合度。如果智能体要频繁调用内部系统、校验权限、处理敏感数据至少需要一个自建工具层和权限层。接着看团队稳定性。如果团队准备长期负责这几个场景自建编排层的回报会随着时间累积如果团队可能半年后解散那就不要为未来买单。然后看统一观测需求。你如果需要在同一个后台查看所有智能体的调用轨迹、token 消耗、失败原因靠通用框架分散日志很难管理自建会更有价值。最后看迁移成本。当你的系统已经在线上稳定运行自建一个隔离层来抵御上游框架变化很可能是最稳的选择。这五个问题并不复杂但能帮你避开两个极端一个是“闭眼自建”一个是“无脑否定”。6.2 回到最底层的经验回到文章开头那个问题。我认为“自建智能体框架无价值”这个判断在今天已经不是一句可以一概而论的话。它只有在特定假设下才成立业务通用、场景单一、团队没有长期维护计划、控制权要求低。但真实业务往往不是这样的。你需要处理内部系统、数据权限、模型切换、链路追踪、成本控制这些东西堆在一起如果不在业务边界上有一层你自己的控制面那个看似高效的智能体框架迟早会在细碎的业务差异中变得很难受。我并不是想鼓励每个人都去自研一个框架。我更想说的是先别被“造轮子”这个词吓住。在开源框架的外围用最小成本沉淀一层属于自己的编排逻辑这件事不仅有意义往往是决定智能体应用能不能从“演示得很好”变成“长期用得稳”的关键分水岭。如果你现在正在纠结这个问题我的建议很简单先挑一个真实场景跑通不加任何抽象然后看它有哪些地方是通用框架满足不了的再决定要不要自建以及自建到哪一层。这个顺序比任何争论都有用。