1. 从定制Agent到通用Agent为什么要做这件事先说一个我踩过的坑。去年我们内部做了一批Agent有客服售后类的、有政策文档问答类的、有报表生成类的还有几个用于内部工单流转。最开始每个Agent上线时效果都不错用户也觉得方便。但三个月之后问题就集中爆发了政策一变文档问答Agent要重新切数据源、重调提示词报表需求新增了一个维度报表Agent要改工具代码、改输出模板客服那边新开了一条业务线原来的意图识别规则根本覆盖不住。更尴尬的是这几个Agent之间有很多能力是重复的。比如都需要查内部知识库、都需要调用用户信息接口、都需要做相似度匹配但每个Agent各写了一套维护两份甚至三份同样的逻辑。我当时的感受是定制化Agent本质上是在为每一个场景重新发明一遍轮子短期上线很快长期维护非常痛苦。后来我们做了一个方向上的调整不再为每个任务单独造Agent而是维护一个通用Agent底座把领域能力拆成可插拔的Skills让模型自己根据用户诉求去调度技能、组合执行。经过大概两个月重构我们把原来五个定制Agent收敛成了一个通用Agent 十几项技能新增场景的开发成本从以周为单位降到了以天为单位。这篇文章就把我这次从定制化Agent走向通用Agent Skills的完整思路和实操过程拆开讲一遍包括架构设计、技能定义规范、调度策略、上下文处理以及我在实际落地中踩过的一堆坑。如果你也在做Agent类项目或者正准备把一堆零散的Agent收拢成统一平台这篇文章应该能帮你少走不少弯路。1.1 定制化Agent的四个典型痛点我们先不急着讲通用方案先把定制化路线为什么难受说清楚。我总结下来是四个问题。第一个是流程僵化。定制Agent通常把业务流程写死在提示词和工具调用序列里比如先调用接口A再根据返回调用接口B最后把结果填到模板C。这个流程只要有一个环节调整整条链路就要跟着改。业务方今天说加一个步骤明天说换一个顺序开发同学每天都在跟着需求微调产出却不稳定。第二个是能力不可复用。不同Agent之间的公共能力没有被抽象出来。知识库检索、API调用、数据计算每做一个新Agent都要重新搭一遍。搭建的时候觉得反正就是几段代码结果多来几个Agent之后重复代码越积越多查问题也变得更费劲。第三个是提示词膨胀。定制Agent喜欢把所有约束、背景、示例全部塞进系统提示词里。我见过最夸张的一个Agent系统提示词超过一万个token模型每回复一次都要带着这一大坨指令推理延迟和费用都下不来而且提示词越长模型越容易在某些角落上犯糊涂。第四个是模型升级的回归成本。底层大模型一换所有定制Agent都要重新测试。不同Agent对模型版本的敏感程度还不一样有的换完效果变好了有的换完反而变差了。每次升级都要逐个调至少花掉两三个工作日。这些痛点集中在一起让我意识到一个问题我们太关注具体任务了反而忽略了Agent真正应该具备的通用能力。所谓通用Agent并不是说一个Agent什么行业都懂、什么活都能干而是把任务里的变数和业务逻辑解耦开——模型负责理解意图、做规划业务能力以技能的形式沉淀下来按需调用。1.2 解耦的本质推理与执行分离想明白这个之后我又把问题往深挖了一层。定制Agent和通用Agent Skills本质上差在推理和执行有没有分开。定制Agent的做法是把推理和执行绑在一起模型既要想用户要什么又要按照固定套路去做事。一旦业务的做事方式变了模型也要跟着重新适应。而Agent Skills的做法是让模型专注于推理——判断这个需求属于什么类型、需要哪些能力、这些能力按什么顺序组合而做事的部分被抽象成一个个独立的、可测试的技能模块。举个例子。以前做一个工资条查询Agent提示词里会写着先调用身份验证接口再调用工资明细接口然后按部门模板生成报表。这其实是把流程写进了模型指令里。重构之后Agent只需要知道一件事这里有一个获取工资明细的技能可以使用。至于这个技能内部是先做权限校验还是先查缓存那是技能函数里确定性的代码逻辑模型不需要知道也不需要参与判断。这种解耦带来一个很直接的好处模型永远不需要学会业务流程它只需要学会使用工具。业务调整时改的是技能内部实现模型调用方式不变Agent的行为就能跟上新的业务要求。这才是通用Agent Skills真正的价值所在。2. 通用Agent Skills的整体设计思路方向定了接下来是设计。我们不是从零开始而是把之前几个定制Agent里反复出现的公共能力先捞出来然后反推整个架构应该长什么样。先说结论我们最终采用了一个核心、一套技能库、多个运行机制的结构。一个核心是指Agent引擎它只做四件事——理解输入、判断意图、选择技能、组织输出。一套技能库是指所有可复用的能力都注册到这里每个技能包含描述、参数定义、执行入口。多个运行机制包括技能调度、上下文管理、日志追踪和权限控制。这个结构不是一开始就设计成这样的而是在重构过程中逐步收敛出来的。下面我把每个部分的设计思路和关键决策逐项拆开。2.1 架构分层决策、执行、资源我们把系统分成了三层每一层的职责都尽量单一。第一层是决策层也就是Agent核心。它接收用户输入负责判断用户想要什么结果然后根据技能库里的技能描述决定调用哪些技能、按什么顺序调用、参数怎么填。这一层几乎不写任何业务逻辑甚至不写具体的工具调用代码它只做选择和编排。第二层是执行层也就是技能运行环境。每个技能是一个独立的执行单元接收结构化的输入返回结构化的输出。技能内部可以封装任意复杂的逻辑调数据库、请求外部API、跑一段脚本、检索知识库都可以。这一层是纯代码确定性执行不允许模型直接生成代码来跑避免不可控。第三层是资源层包括知识库、向量数据库、业务系统接口、权限服务等。这一层对技能提供统一的数据访问能力对上层屏蔽差异。技能不需要关心数据存在哪里、通过什么协议取只需要从资源层拿结果就行。这三层的关系可以简单理解为用户 - 决策 - 技能 - 资源。决策层想执行层做资源层提供材料。每一层只依赖下一层暴露的接口不跨层操作。这样做的直接收益是任何一层的内部改动都不需要动到其他层。2.2 Skills的定义不只是工具的改名在动手之前团队内部对Skill到底是个什么东西还产生过争论。有人说Skill就是工具函数的封装换了个名字而已有人说Skill是把提示词片段结构化。我们实际做完之后我对Skill的定义是一组面向特定领域能力的、具备完整输入输出约定和资产说明的可复用执行单元。它和Tool工具的区别在于Tool往往是最小的原子操作比如执行HTTP请求读取文件计算两个日期差几天而Skill是领域中真正有业务含义的能力比如查询订单状态生成销售周报核对报销单合规性。一个Skill内部通常会串联多个Tool调用但对外暴露的是一个语义明确的整体。它和Plugin插件的区别在于Plugin更偏重资源打包比如一组预设提示词、一组API配置、一组UI组件而Skill不仅有资源还有明确的执行逻辑和处理流程是一个完整的闭环。我们给每个Skill定义了一套统一的元信息用一个JSON结构来描述。字段包括字段说明示例skill_id技能唯一标识order_status_queryname可读的名称订单状态查询description自然语言描述用于模型判断何时调用当用户询问订单物流、签收、配送进度时使用input_schema参数定义JSON Schema格式必填order_id字符串output_schema返回结果结构状态、时间、备注的字段列表execution_type执行方式code/api/knowledge_basecodetimeout_ms超时时间3000auth_scope需要的权限范围order:readversion技能版本1.2.0描述这一项特别重要。模型不会看代码它决定调不调这个技能主要靠description来判断。描述写得太笼统模型就不知道该什么时候用写得太细又容易把模型搞糊涂。后面我会专门讲这块的调优经验。2.3 通用底座技能库为什么能解决扩展性问题回到最初的痛点通用Agent Skills怎么解决新增场景慢的问题以前加一个新客服场景要重新设计意图、写提示词、写流程、接数据源、做测试。现在逻辑变了先看看这个场景需要哪些能力——需要查知识库已有知识库检索技能直接用需要查用户信息已有用户信息查询技能直接用需要判断用户情绪没有现成技能那就新写一个情绪判断技能注册到技能库里。整个Agent核心一行代码都不用改。这就把扩展问题从每次重做一遍变成了每次加一个模块。而且技能是独立测试的新增技能的回归范围很小不需要把整个Agent流程全部走一遍。我当时跟团队讲了一个比喻定制Agent像是请一个只做过这一个岗位的员工换岗就得重新培训Agent Skills像是搭建了一个通用的工作台工作台的各种能力是标准化的工具模块来什么活就往上挂对应的工具。这个比喻不一定严谨但用来跟业务方解释为什么这次改起来快是挺好用的。当然通用底座也不是没有代价。它的推理负担比定制Agent更重模型要在一堆技能里做选择技能多的时候容易选错或犹豫。这个问题的解法不是砍技能数量而是优化调度策略。我们最终采用的是管理员预配置路由 模型自主选择结合的混合调度模式后面第3章会细说。3. 核心模块拆解与实操要点设计归设计真正落地还是有很多细节要抠。这一章把我们在实操中碰到的关键模块逐个拆开讲清楚每个模块要解决什么问题、怎么实现比较稳。3.1 技能注册与发现机制技能库要能正常工作第一步是让系统知道现在有哪些技能可用。我们做了一个极简的注册中心本质上是一个服务目录技能上线时把自己的元信息注册进去Agent引擎启动时会拉取一份完整目录缓存在本地。注册中心存储的核心数据就是上面那张表里的字段。技能代码本体是以独立模块部署的注册中心里保存的是调用入口和元信息不包含代码实现。也就是说注册中心只是目录真正的货架在技能运行环境里。这里有一个容易被忽视的细节版本管理。技能升级是常态但已开始的会话可能还在使用旧版本不能直接一刀切。我们的做法是每个技能支持多个版本并存新请求默认走最新版本会话内保持一致由Agent引擎根据会话创建时间决定使用哪个版本。测试和灰度也可以靠版本号来切流量。另外技能注册之后不是马上生效建议加一个可观测的生效状态。我们统一用status字段来标记draft草稿、active生效、deprecated废弃。只有active的技能会进入Agent引擎的选择候选池这样新技能可以先注册成draft做联调不影响线上决策。3.2 调度层设计路由规则与模型选择的配合技能调度是整个系统里最容易出问题、也最关键的一环。我们的调度策略经过三轮迭代才稳定下来。第一轮是最朴素的方案把所有技能描述拼进系统提示词让模型自己选。技能数量在十个以内时问题不大一旦超过十五个模型做选择的准确率明显下降会出现该用A技能却用了B技能的情况。而且描述越长token开销也大。第二轮我们做了预筛在模型之前加一个轻量级路由层根据用户输入的关键词和语义分类先过滤出一批候选技能再让模型从候选集里选。比如输入里包含订单物流等词就先把订单类技能筛出来其余无关技能不进入模型的候选列表。这个方案把选择准确率提升了不少也节省了token。第三轮在预筛基础上增加了模糊兜底预筛如果匹配不到任何候选技能不直接报错而是把排名靠前的通用技能比如知识库检索作为兜底交给模型决定。做过调度之后我觉得完全靠模型做技能选择的方案看起来很智能实际工程里不可控。正确做法是让前置规则承担大部分确定性筛选模型只负责在少量候选技能中做决策这样既保留了灵活性又保证了稳定性。调度还有一个细节技能之间可能存在依赖关系。我们定义技能时用depends_on字段声明依赖其他技能Agent执行引擎会按依赖关系自动编排顺序。但这个字段我们默认不给模型看是由引擎在后台处理的避免模型在规划时因为依赖关系陷入死循环。3.3 上下文与记忆的分层管理这是另一个很容易翻车的地方。Agent的核心提示词需要包含技能目录和调用规则用户的对话历史又可能很长两边加起来非常容易超上下文窗口。我们的做法是把上下文分成四层。第一层是固定系统层。存放Agent角色设定、通用交互规范、技能目录摘要。技能目录摘要不是把所有技能描述原样放进去而是由调度层先生成一份当前会话可能用到的候选技能摘要动态拼到系统层。这样既保证了模型知道有哪些可用能力又不会把系统提示词撑爆。第二层是会话摘要层。历史对话不完整塞进上下文而是由模型实时生成摘要。每次对话结束后引擎会把用户诉求摘要 已用技能 关键结果压缩成几条结构化记录。下一次请求时这些摘要以精简形式放回上下文原始完整历史放到外部存储里。第三层是工作记忆层。存放当前任务中模型需要记住的中间状态比如用户已经提供了订单编号当前正在执行退款操作还差审批人确认。这个层是易变的任务结束后就被清理。第四层是长期记忆层。保存用户的偏好、常用信息、历史偏好等按需调用。比如用户每次问订单都要带订单号长期记忆里存下这个习惯下次模型会自动追问订单号。四层分开之后上下文长度稳定下来了模型的表现也变好了。实测下来系统提示词加摘要平均控制在三千到四千token以内比之前动辄上万token的提示词轻量很多。3.4 技能的内部实现规范技能内部怎么写直接决定整个系统的可靠性。我们总结了一套硬性规范。第一技能输入必须是结构化参数不能指望模型直接把自然语言传进来。模型只负责按照input_schema填充参数参数校验是在技能入口用代码完成的。参数缺了、格式不对技能应该返回一个明确的错误信息而不是抛异常或默默失败。第二技能内部不要依赖模型。技能里可以调用外部API、查数据库、跑计算但原则上不允许在技能内部再掉一次大模型接口。一旦技能内部也调模型整个执行链路就不可预估了耗时和成本都会爆炸。如果某个技能确实需要语义理解能力那应该把语义理解拆成一个独立技能由Agent引擎统一调度。第三技能要有明确的成功和失败返回。我们统一用result字段包一层结构返回code0成功、非0失败、data、error_msg。这样Agent引擎能根据返回码决定下一步动作。模型看到失败信息后可以判断是重试、换技能还是直接告知用户。第四每个技能要有超时和降级策略。技能执行超过设定时间就中断返回超时错误。降级方面我们给每个核心技能配置了一个备用实现比如线上接口挂了就降到本地缓存数据。这个策略在定制Agent里是分散在各处的重构之后统一成了技能级别的通用配置。写好这四个规范之后新技能的开发基本成了套模板的工作团队上手速度明显快了很多。4. 实操落地从零搭建一套可用的Agent Skills前面讲的是设计这一章讲一个具体的落地过程。我们重构时的目标很明确两周内让三个原来跑在定制Agent上的场景平滑迁移过来。下面按实施步骤记录一下。4.1 技术选型与基础框架技术选型我们没有追求新东西一切以稳定为先。推理模型选了一款支持结构化输出和工具调用的商用大模型当时对比过好几款最后用的是响应速度和函数调用准确率综合表现较好的那款。底层框架没有用重型编排框架而是自己写了一套不到两千行的核心循环代码因为我们的调度策略比较定制化套通用框架反而要绕很多弯。技能运行环境用的是容器化的独立服务每个技能一个部署单元通过gRPC接口对外暴露调用入口。注册中心是一张数据库表加一个轻量缓存服务元信息分页拉取到Agent引擎。向量检索、知识库、业务系统接口保持原有系统不变通过资源层统一封装。这套组合整体运维负担不重扩展性也够用。核心循环大概长这样async def agent_loop(user_input: str, session_id: str) - str: # 1. 加载会话上下文和技能候选 ctx await load_context(session_id) candidates await intent_router(user_input, ctx) # 2. 让模型规划本轮动作 plan await llm_select_skills( user_inputuser_input, skill_candidatescandidates, system_ctxctx, ) # 3. 按规划执行技能 results [] for action in plan[actions]: result await execute_skill( skill_idaction[skill_id], argumentsaction[arguments], ) results.append(result) if result[code] ! 0: break # 4. 汇总结果并生成回复 reply await llm_generate_reply( user_inputuser_input, skill_resultsresults, ctxctx, ) return reply这只是核心骨架实际生产里还有权限校验、限流、日志、trace等逻辑但主流程确实只有这四步。4.2 第1步先梳理场景沉淀首批技能很多人一上来就想把技能做得很全这是误区。我们的做法是先梳理三个待迁移场景里共用的能力首批只沉淀了五个技能知识库检索、用户信息查询、订单状态查询、工单创建、数据指标查询。以知识库检索为例它服务的场景是用户问政策条款和用户问售后规则两个场景共用同一个检索逻辑只是检索的知识库范围不同。我们把知识库范围作为参数暴露由调用方传入。这样就是一个技能服务两个场景而不是做两个技能。沉淀技能的时候有一个关键动作把原来定制Agent提示词里的业务规则挤出来。如果某个业务规则是该技能领域内部的就写进技能代码里如果是跨技能的全局规则才留在系统提示词里。这一步做完之后系统提示词规模降了一大截。4.3 第2步定义技能Schema与注册流程每个技能上线前要先写一份schema注册进注册中心。我们用JSON Schema定义参数的格式引擎侧校验使用现成的校验库不用自己造轮子。以订单状态查询技能为例schema长这样{ skill_id: order_status_query, name: 订单状态查询, description: 当用户询问订单的物流、配送进度、签收状态时使用。用户需要提供订单编号。, input_schema: { type: object, properties: { order_id: { type: string, description: 订单编号通常是纯数字 } }, required: [order_id] }, output_schema: { type: object, properties: { status: { type: string }, tracking_time: { type: string }, remark: { type: string } } }, execution_type: code, timeout_ms: 3000, auth_scope: order:read, version: 1.0.0 }这里要特别注意参数描述。description里的订单编号通常是纯数字是写给模型看的模型会根据这句描述决定怎么从用户原话里提取参数。描述得越具体参数抽取越准。注册流程我们定成写schema - 提交代码 - 跑自动化测试用例 - 灰度上线 - 标记active。每个技能都配了一组固定的测试用例用于验证输入输出的正确性。这一套流程熟练之后新技能从开发到上线差不多一天内能完成。4.4 第3步实现调度与路由调度层初始实现我建议简单一点先用关键词规则做候选筛选再让模型从候选中选一个技能组合。关键词规则看似朴素但实际效果很稳而且没有额外成本。我们维护了一张路由映射表- intent_group: order keywords: [订单, 物流, 配送, 签收, 快递] skills: [order_status_query, after_sale_creation] - intent_group: knowledge keywords: [政策, 规则, 条款, 怎么退, 能报多少] skills: [knowledge_base_search] - intent_group: data_query keywords: [报表, 统计, 上周, 环比, 总量] skills: [data_metric_query] - intent_group: user keywords: [我的信息, 手机号, 地址, 身份] skills: [user_info_query]输入先做一次关键词命中命中的技能进入候选池一个输入可能命中多个组候选池可能包含三四个技能模型就在这几个里面选选错的概率就低很多。如果命中的技能为空调度层会把所有技能里description和输入文本的向量相似度算一遍取top3作为兜底候选。这次兜底交互其实是重构后效果提升比较明显的一环因为我们发现用户表达习惯千差万别纯靠关键词真的会漏。4.5 第4步调试与效果验证调试是整个重构里最耗时间的一环。我们花在让模型正确调用技能上的时间比写技能代码多得多。验证方式分三层单技能测试、场景回归测试、线上小流量对比。单技能测试的指标是参数抽取准确率、技能调用成功率、返回结果格式合规率。场景回归测试是把原来定制Agent上的典型用户问题集拿出来逐条跑到新系统上对比新旧结果。线上小流量对比是我们最推荐的验证方式——新旧系统各接一部分流量连续跑三到五天用任务完成率和用户反馈做对比。这里要说一个容易被忽略的点输出的稳定性评价远比单个回复的惊艳感重要。定制Agent偶尔会给出很漂亮的回答但经常不稳定通用Agent重构之后我们追求的是同样的问题每次回答一致、正确哪怕不那么炫。这个思路调整对验收标准影响很大。三个场景迁移完成时整体效果基本追平了原系统接入新场景的效率提升非常明显。到第五个场景接入时从需求到上线只花了三天而之前一个新定制Agent至少需要两周。5. 常见问题与排查技巧实录这个章节是我最想写的部分。整个重构踩过大量坑有些坑在文档里根本查不到我把最有代表性的几个写出来供参考。5.1 模型就是死活不调用某个技能我们遇到过好几次这种情况技能代码没问题、描述也写了但模型在决策时就是无视这个技能。排查后发现大部分原因是技能描述和用户表达之间存在语义断层。举个例子。我们做了一个销售周报生成技能描述写的根据销售明细生成周报。看起来没毛病但实际用户根本不会说生成周报他们说的是帮我看看这周卖得怎么样。两个句子在语义上相关但在模型眼里不是一个意图。后来我们把描述改成了当用户询问本周销售情况、周报、业绩汇总时使用可自动汇总销量和金额模型就正常调用了。所以技能描述不能写官话要写用户会说的人话最好把常见表达方式都写进去。我建议每维护一个技能就翻一翻真实对话记录把用户问法里最高频的十种说法记一记写进skills的alias字段里。5.2 技能选择多了就乱怎么收敛技能数量超过15个时模型的选择准确率会明显下降。前面讲了我们可以用路由预筛解决一部分但还有另一招把技能做层级分组。我们后来把技能分成了三层一级是领域分组比如营销域、客服域、数据域二级是具体技能三级是技能内部的执行方案。调度时先按领域分组做路由再在组内做技能选择模型每次面对的技能数量最多不超过六七个。分组收敛之后还有一个附加好处系统提示词里的技能概述可以更简洁。我们不再把所有技能描述列出来而是一级只展示分组列表等模型确定分组后再动态展开该组的技能描述。如果你也遇到技能一多就乱的情况不妨把精力先花在做分组上而不是写更长的描述。这个投入产出比很高。5.3 多技能串联时参数传递错乱场景稍微复杂一点比如查询用户上个月的订单并生成消费分析就会涉及多个技能串联。每个技能的输出要作为下一个技能的输入但模型在规划时经常填错参数名或者把上一个技能的系统返回信息直接塞给下一个技能当用户输入。我们解决这个问题的思路是不让模型直接传复杂参数。把上一个技能的输出先经过一个轻量的字段映射器由代码把输出结构映射到下一个技能能接收的格式。模型只负责声明先调A再调B不负责A和B之间的数据转换。这里有一条经验Agent的执行链路越长越要减少模型对中间数据的处理。中间数据的清洗和转换一律用代码完成模型只做高层决策。这是保证长链路执行稳定性的核心。5.4 成本与延迟超预期通用Agent Skills在推理成本上天然比定制Agent高因为模型每次回复都要做技能选择消耗的token更多。我们在优化成本时做了三件事。第一路由预筛完成后把未命中的技能描述从系统提示词中去掉减少不必要的token开销。第二技能执行结果做了摘要不把一大段完整数据直接交给模型生成回复而是先提炼成要点。第三设置了模型调用层级简单问答走轻量模型复杂多步任务才走强推理模型由调度层根据任务复杂度动态决定。延迟方面技能并行执行是一招很有效的优化。相互之间没有依赖的技能可以并发调用比如同时查用户信息和查订单状态。我们实测之后这部分能把整体延迟压缩掉30%到40%。6. 踩坑总结与下一步扩展想法重构项目做到现在我最大的体会是想从定制化Agent走向通用Agent Skills最难的不是技术实现而是思维方式的转变。你要接受一个事实模型不可能每次做对但你可以通过架构设计让出错的范围越来越小。技能把业务能力收拢成了可控的单元路由规则和参数校验把模型出错的概率压到最低剩下的一小部分不确定性再靠日志追踪和回归测试慢慢收敛。如果你现在正准备做Agent项目的架构升级我的建议是先克制一下想一次把所有能力都变成技能的冲动。从两三个场景开始把公共技能沉淀出来验证通用底座跑得通再逐步扩大技能的覆盖范围。这个节奏最稳。至于下一步扩展我在内部规划的思路有三个方向。第一个方向是主动技能学习。现在技能主要由开发人员人工定义和注册后续希望沉淀一套数据闭环每次模型调用技能成功或失败都把记录留存下来定期分析哪些场景有高频需求但没有对应技能让技能的生成从被动开发变成一个半自动的流程。第二个方向是多Agent协同。当一个请求涉及的领域跨度过大时比如既要查业务数据又要做合规分析一个Agent在规划和执行上会显得吃力。我们打算在通用Agent之上让多个Worker Agent各自负责一个领域分头执行由主Agent统一编排汇总。Skill是这些Worker Agent的能力基础不会推翻现有架构。第三个方向是技能质量的度量体系。目前我们评判技能好用不好用基本靠调用成功率和任务完成率这两个指标还不够细腻。后面想引入更多维度比如技能调用后是否真正解决了用户问题结果相关性、技能描述对模型决策的贡献度描述信息量、技能组合模式里的高频路径链路热力图。有了这些度量技能库才能持续迭代而不只是越堆越多。这次从定制化到通用化的重构是我最近一年做的回报率最高的一次架构调整。它不复杂但确实把过去分散的工程量攒到了一套可以被持续复用的体系里。如果你也在做类似的Agent项目欢迎用这篇文章里的思路去做一轮复盘——把你们现有的Agent能力按技能重新理一遍你也会发现通用的底座并没有想象中那么难。