★ FEATURED ARTICLE 1. 选型背景通用框架看着很美但真的够用吗接手这个项目之前团队已经在跑几个独立的单Agent应用每个Agent负责一类任务有的做文档抽取有的做检索问答有的做数据清洗。业务发展起来之后单一Agent撑不住复杂流程得让它们互相协作A做完抽取把结构化结果丢给B做信息补全C再根据补全结果决定下一步调用哪个工具还要兼顾人工审批环节。这种多Agent协作流程基本就避不开“编排”这件事。编排怎么做当时主要有两条路直接用某个开源的通用Agent编排框架或者按业务需求自己写一套调度逻辑。团队里不少人有使用通用框架的经验一开始我更倾向直接上框架毕竟现成的东西能省下不少开发时间社区方案也成熟。但真正深入评估之后发现事情没那么简单。先说说通用框架吸引人的地方。它的设计理念是把Agent之间的交互抽象成图、状态机或者消息总线模型开发者只需要声明节点和边就能拼出一条执行链路。这种思路天然适合那种流程稳定、节点明确、并行关系清晰的多Agent协作。很多框架还内置了记忆管理、工具调用、人机交互中断恢复能力相当于把一个Agent服务端要做的脏活累活都包了。我用一个标准的多Agent协作场景做了原型验证三个Agent协作完成一个带状态流转的申请审批流程模拟了分支路由、条件判断、人工审批暂停、超时重试。原型跑得很顺这给了团队信心但同时也暴露了一些隐藏问题。第一个问题是调试和追责。通用框架把调度逻辑收进了框架内部运行时通过事件回调或者日志观察局部信息但你想“看到”某个Agent当时为什么做出这个决策、它基于什么上下文、它为什么走了那条分支就得依赖框架把相关数据记录下来。不同框架的日志记录粒度不一样有的能记录节点级输入输出有的只记录事件摘要真正出现问题的时候排查链路非常痛苦。第二个问题是状态管理的黑盒化。框架会帮你管理Agent的会话状态、中间结果和工具调用的结果缓存这对简单场景很友好。但一旦需要两个Agent共享某份中间数据或者某个Agent的输入依赖于另一个Agent在某个节点内的局部输出框架的抽象层就开始变得别扭。你得想办法把数据塞进预设的存储结构里或者绕过框架的模型去操作底层数据这就背离了“用框架省事”的初衷。第三个问题也是最后压垮“纯框架”方案的是业务对编排控制力的要求。真实业务场景里不是所有Agent之间的协作都可以预定义成一张静态图。有些任务是动态生成的比如一个分析任务在执行过程中发现需要临时启动一个数据校验Agent校验完再决定原流程是继续还是回退。这种动态分支在通用框架里也能做但每加一种动态逻辑都得去理解框架对图节点、条件边、路由策略的实现约束最后变成我们在适配框架而不是框架在服务业务。团队内部讨论了很久结论是通用框架适合做“标准件”但不适合做我们需要的那种“可定制的总装线”。于是我们把视线转回自研编排。2. 自研编排的动机我们要的不是调度器是控制权决定评估自研编排的时候团队内部争议很大。反对的声音主要来自交付周期自研一套编排系统少说两三个月多则半年业务等不起。但支持自研的理由也很充分因为我们真正需要的不是“调度器”而是对Agent协作全过程的控制权。当时整理了自研编排要解决的核心诉求一共四点状态可视化与全链路审计业务方和安全团队要求能随时回放一次多Agent协作的完整轨迹包括每个Agent的输入、输出、耗时、Token消耗、决策依据。动态任务路由同一个流程里不同用户、不同数据内容可能触发完全不同的Agent组合和分支顺序需要能在运行时动态修改执行计划。深度的流程干预部分场景需要人工打断Agent的执行、修改中间结果后让它继续跑这要求编排层必须提供暂停、恢复、回滚、修改状态的接口。资源与并发控制不同Agent类型需要不同的并发配额、超时策略和失败重试策略并且这些参数要能在线调整不能每次改配置都重启服务。这四个诉求里第一点和第三点最要命。通用框架大多把执行流程封装成了一个原子单位你可以“整段重跑”但很难“从中间某个节点接着跑”。比如某个Agent在处理数据时因为超时失败了业务希望人工修正后从失败节点继续而不是把整个流程推倒重来。基于通用框架实现这种“断点续跑”的复杂度其实不亚于自己写一套状态管理。自研编排的方案设计核心是三个模块。第一个模块是执行计划模型。我们没用传统的工作流节点图因为节点图在静态场景好用但动态分支一多图的边维护起来就是灾难。我们换成了“阶段列表 规则网关”的模型一次任务被拆成若干个有序阶段Stage每个阶段里可以包含一个或多个Agent执行单元Unit。一个Unit执行完之后结果交给规则网关Gateway判断下一步是进入下一个Stage、并行拆分成多个分支还是回到之前的某个Stage重试。这个模型看起来比图简单但表达能力足够应付绝大多数动态路由需求而且非常容易做状态持久化——你只需要记录“当前执行到哪个Stage、哪个Unit”就行。第二个模块是状态存储设计。这是自研编排和通用框架最大的区别之一。每个任务实例维护一个共享上下文Shared Context所有Agent的输入输出都往里面写但又通过命名空间隔离——每个Agent只能读写自己被授权的命名空间。这个设计避免了一个经典问题Agent太多了之后谁改了谁的变量状态发生错乱。同时共享上下文会被完整持久化到存储层任何时刻服务重启都能从最近一次持久化点恢复任务执行。第三个模块是组件化Agent封装。我们没有眉毛胡子一把抓地统一所有Agent的接口而是定义了一个极简的协议每个Agent实现一个run(context, payload)函数输入一项任务载荷和一个上下文句柄输出一个结果对象。至于Agent内部是由大模型驱动、规则引擎驱动、还是普通的HTTP接口调用编排层一概不管。这个协议很简陋但好处是接入成本极低老的单Agent应用改几个接口就能接入新系统。当然自研决策不是拍脑袋做的。当时团队内部做过一次成本评估列了一张对比表把通用框架、纯自研、混合架构三者的优缺点摆在一起看维度通用框架纯自研混合架构开发周期1~2周3~6个月2~3个月动态分支支持受框架约束完全自定义自研编排层完全自定义状态可观测性依赖框架日志自研完全可控自研完全可控断点续跑能力部分支持受限制自研设计自研设计生态复用能力强弱中等框架能力做底层长期维护成本跟随框架升级全部自己维护核心自研底层借助框架看完这张表结论其实很清楚了纯通用框架适合快速验证和标准流程场景但撑不住我们后续要做的动态路由和深度干预纯自研虽然可控但开发量太大而且底层工具调用、模型管理这些基础能力没必要重复造轮子。混合架构是唯一既能保持业务灵活度又能控制开发成本的选择。3. 混合架构落地方案通用框架垫底自研编排掌舵混合架构的核心思路用一句话说就是底层能力用通用框架上层编排逻辑完全自研两者通过一个薄薄的适配层连接。这里的“底层能力”指的是不区分业务场景的通用技术组件包括大语言模型的统一接入与模型路由、工具/API调用的协议封装和参数校验、Agent会话历史的存储与检索、向量库的读写、以及通用文本切分和Embedding计算的逻辑。这些能力放在通用框架层一是因为社区已经把它们打磨得足够好边界清晰接口稳定升级迭代风险可控二是因为它们本身不涉及业务逻辑自研的价值不高。“上层编排逻辑”则完全由我们自己控制。这部分包括Agent协作流程的编排模型Stage/Unit/规则网关、动态任务路由引擎、共享上下文的状态管理、任务的暂停恢复回滚、并发配额和超时控制、以及执行轨迹的记录和审计查询。这些都是通用框架想管但管不好、想放又放不开的地方。这里需要说清楚一个容易踩坑的点有很多框架也允许你编写“自定义节点”或者“自定义回调”来嵌入自己的逻辑很多人就觉得这已经是混合架构了。实际上不是。那种方式下整体执行流程的控制权还在框架手里自定义节点只是框架流程中的一个步骤能做的事情被框架的调度语义限制住了。而我们做的混合架构是直接把“流程控制权”整体拿回到自己手上框架退化为一个被调用的能力池。两者的本质区别是框架编排逻辑还是编排逻辑里调框架。前者是框架主导后者是自研主导。这个边界必须在设计阶段就划清楚不然很容易做着做着又回到“适配框架”的老路。适配层的设计是混合架构能否落地的关键。这个层做的事情很纯粹把自研编排层的调用请求翻译成底层框架能力的具体调用。举一个真实的例子。我们有一个Agent需要调用一个第三方数据分析工具的接口。在自研编排层这个Agent就是一个Unit输入是一份清洗后的业务数据输出是一个分析结果对象。但实际执行的时候Agent内部会先通过底层框架的模型路由调一个大模型生成分析参数再通过框架的工具调用协议把参数发给数据分析工具然后通过框架的上下文工具把工具的返回结果存回会话记录。这些内部的复杂过程自研编排层看不到也不需要看到。为什么要把这层做成“薄适配”因为适配层越薄底层框架的可替换性就越强。我们初期选择了一个功能全面的开源编排框架做底层但并没有跟它绑定死。适配层的接口可以完全可以换成另一个框架实现甚至以后某个组件觉得自研更合适也可以单独替换掉。后面一次底层框架版本升级适配层只改了两百行代码这个设计让团队省了很大力气。混合架构下整体任务的调用链路大致是这样的用户发起一个多Agent协作任务请求进入自研编排层。编排层根据任务类型和上下文数据通过规则网关生成初始执行计划。执行计划被翻译成若干个Stage每个Stage包含一组待执行的Unit。编排层按顺序执行Stage把Unit的输入从共享上下文里取出传给适配层。适配层调用底层框架的执行能力框架内部完成大模型调用、工具调用、回复生成等动作。框架返回执行结果适配层将其解析成标准输出对象写回共享上下文。规则网关读取当前Stage的输出决定下一步是继续、分支还是重试。这条链路跑通之后最直观的变化是调试一个多Agent协作问题不再需要翻框架的日志了直接看执行计划的每个Stage的状态、每个Agent的输入输出就够了。状态回放、断点续跑、人工插入修改中间结果这些通用框架上很费劲的功能在自研编排层变成了基础能力。4. 关键实现细节与踩坑实录这些环节不处理好架构再合理也白搭混合架构的思路定下来只是万里长征第一步。真正开始写代码之后才发现每个模块里都藏着不少坑。这里挑几个影响最大的环节展开说希望能给后面做类似方案的同学一些参考。4.1 共享上下文设计好记性不如烂笔头共享上下文是整个自研编排层的数据中枢所以它的设计直接影响系统的稳定性。我当时定了一个原则上下文的写入必须是“追加式”的不允许Agent随意修改已有键值只能新增带版本号的数据块。这样做的好处很直接。Agent执行过程中产生中间数据这个数据一方面会被后续Agent使用另一方面也是审计追溯链路上的一环。如果允许随意修改就会出现“查A时看到的是版本1查B时看到的是版本2但版本2是谁改的说不清”的局面。追加式写入把每次写入都记录成一条独立的、带时间戳和写入者标识的记录查询时默认取最新版本但历史版本随时可以回溯。举个例子一个文档处理任务包含两个Agent一个做格式清洗一个做信息抽取。清洗Agent处理完文档后把结果写入共享上下文键名是doc.clean_result。信息抽取Agent读取这个键值发现自己需要的字段缺失于是它有两种选择直接抛出异常让编排层处理或者写一条补充说明到自己的命名空间然后继续。如果是直接修改共享上下文里的源数据后面的人复查时很可能就分不清这个缺失字段到底是被清洗Agent丢掉的还是被抽取Agent改掉的。有人会觉得追加式写入占存储空间确实占但换来的是极强的问题排查能力和数据可解释性。我在实际项目里一般会给共享上下文设置一个归档策略任务结束72小时后超过7天的历史版本会被合并压缩只保留最新版本和关键节点的快照这样存储成本就能控制住。4.2 规则网关设计条件判断要多留一个“兜底”规则网关决定了多Agent协作的分支走向是编排层里风险最高的模块。一个分支判断写错轻则让任务走进错误分支重则引发循环调用把下游服务打爆。网关的实现本身不难本质上就是一个函数输入当前执行结果和共享上下文输出下一跳的路由指令。但我在设计时给自己加了一条约束任何规则网关都必须有一个显式的“兜底路由”也就是没有任何规则命中时任务应该往哪走。很多初版方案会忽略兜底路由默认“没有任何规则命中就终止任务”。这在测试阶段没问题但生产环境里一旦某个Agent输出格式变了、字段名改了、或者内容为空这种静默终止会让整个任务看起来像“卡住了”既没有报错也没有下一步动作排在任务队列里像个僵尸。我的做法是兜底路由不是终止任务而是进入一个“人工复核Stage”。在这个Stage里没有配置任何Agent只有一个等待人工指令的暂停位点。操作人员在系统里能看到“该任务走到了所有规则都不匹配的状态需要人工确认下一步”然后手动选择是把任务转移到某个Agent继续处理还是直接标记为失败终止。组件化设计允许每个Agent在输出时带上一个“置信度”或“状态码”规则网关可以基于这些信息做更精细的兜底判断比如“置信度过低则不进入自动检测分支转入人工抽检队列”。另一方面规则网关的执行也做了超时和熔断处理。如果某个Agent的返回结果迟迟不到编排层不会无限等待而是触发重试逻辑重试达到上限后把该Agent标记为失败由网关决定是降级处理、重跑一次还是转入人工。4.3 Agent接入协议接口越简单接入越快自研编排层面临的Agent类型很多有调用大模型的智能Agent有纯规则处理的逻辑Agent有调用外部服务的集成Agent还有本身就是一系列简单函数组合的流程Agent。把它们统一起来的协议一定要足够简单不然每接一个新Agent都要翻一堆文档违背自研的初衷。我最终定的协议长这样AgentResult run(AgentContext ctx, AgentPayload payload)每个Agent只接收两个参数上下文句柄和任务载荷。Agent内部想做什么都行但返回结果必须是一个结构化对象至少包含status成功/失败/需人工、data处理结果、meta调用元信息比如Token消耗、处理耗时、失败原因。这个协议的好处是一个Agent的代码量被压缩到极简测试起来也方便可以直接用一个临时payload跑单个Agent看它返回什么。但它在面对流式输出场景时有点力不从心因为流式输出没法一次性返回两个参数里的那个结果对象。我们的解法是加了一个回调接口Agent在流式执行过程中可以主动向编排层推送中间事件编排层再根据事件类型决定是转存到共享上下文还是触发规则网关的实时判断。想想看以前的Agent之间互相调用每个人都要理解对方的接口定义和数据结构还得处理对方抛出来的异常。统一协议之后Agent之间的耦合度降到了最低每一个Agent都是“输入输出都是标准对象不管别人内部是怎么实现的”的黑盒。这带来一个额外的好处可以方便地替换任何Agent的底層实现比如把某个基于规则的处理逻辑换成大模型驱动只要返回结果格式不变编排层根本不需要感知。4.4 框架升级与适配层维护省心背后的代价前面夸了混合架构的适配层很薄升级省心但这不意味着不需要维护。实际运行中底层框架的版本升级、组件更新还是会偶尔破坏适配层的接口尤其是底层框架做较大的重构时。我们的应对办法是双轨制保留一套线上锁定的框架版本生产环境不轻易升级同时在测试环境维护一套最新版本跑完整的Agent回归用例集。只有回归用例全部通过才会启动生产环境的升级窗口。这套流程不复杂但能在底层框架发布新版本后第一时间发现问题而不是让线上环境做测试场。适配层本身还有一些“兜底实现”。某些底层框架能力在实际调用时可能不稳定比如偶尔超时、偶尔返回格式不规范。适配层设置了超时保护、重试机制和降级方案。降级方案的意思是如果一个底层框架能力连续失败多次适配层会自动切换到一个备用实现可能是另一个框架的类似能力也可能是一个自己写的简化版本不至于让整个编排流程卡住。4.5 任务恢复机制切换了执行进程现场还在前面提到共享上下文具备持久化能力这份持久化数据要做不仅是为了审计更是为了任务恢复。设计时我把任务恢复分成两个层次一是进程内恢复。如果编排服务本身没有挂只是某个Agent执行失败机制的触发点就在编排层内部。具体做法是规则网关根据失败类型生成一个新的Stage把失败Agent标记为“需修复”同时保留之前的全部上下文和执行轨迹。操作人员可以修改Agent的运行参数然后从失败的Stage重推。二是跨进程恢复。如果编排服务宕机了重启之后要做的是从持久化存储里把所有上次还在运行中的任务捞出来标记为“中断”然后根据每个任务当前执行到的Stage位置逐个恢复。这里有一个很关键的设计决策任务恢复不能“自动继续执行”而应该“进入待确认状态”。原因也简单Agent执行是有副作用的比如已经给外部系统发过通知、已经扣过费用、已经写入过数据。如果服务重启后自动恢复执行可能导致同一个动作被执行两次。进入待确认状态后操作人员可以查看任务的历史行为再手动决定是继续、跳过还是回滚这个逻辑尽可能避免了“事故叠加”。4.6 并发配额和超时策略别让一个Agent拖慢所有任务多Agent协作系统里一个常见的滥用场景是任务A里有一个Agent调用了大模型响应特别慢导致整个任务的执行时间被拉长。如果同时有几十个任务都卡在同一个慢Agent上系统的资源很快就被吃满后续任务全部排队。自研编排层里我为每种Agent类型配置了独立的并发配额和超时策略。超时策略不是一刀切而是分“软超时”和“硬超时”软超时后触发一次重试重试仍然超时才触发硬超时把Agent标记为失败并把任务交给规则网关处理。并发配额则控制同一时间某个类型的Agent最多能同时执行多少个实例超额的任务自动排队等待。这个策略看起来简单但非常有用。之前压测时发现某一个耗时长的子任务类型比如深度分析型Agent占用了大量底层大模型令牌配额把其他简单任务全部阻塞。当时我们把该Agent类型的并发配额从默认值调低到5同时把它的超时时间从120秒调整为300秒其他类型的Agent立刻通畅了。这里有一个调参细节值得记住并发配额和超时策略不是越苛刻越好过分收紧配额会导致大量任务排队无法利用空闲算力完成跑得快的任务。合理的调参逻辑是观察慢任务的耗时分布把超时时间设为P95耗时的1.5倍同时把并发配额设为“它能同时占用的最大底层资源÷单个任务资源消耗”的一半留出冗余空间应对突发流量。5. 调优实战与效果对比混合架构上线之后我们观察到了哪些变化架构方案上线之后团队做了一次为期两个月的运行观察期间对比了三种形态下的关键指标之前用纯通用框架跑原型的阶段、排期做纯自研的原型阶段、以及最终混合架构正式上线后的阶段。先看稳定性相关的数据。纯通用框架阶段一个典型的多Agent协作任务能跑通的概率大概在70%左右剩下的30%要么是某个Agent超时没有触发重试要么是动态分支处理不好导致流程卡死。到了混合架构阶段经过一段时间的调优同类任务的首次执行成功率稳定在92%以上。剩余失败的8%里绝大多数是外部服务不可用或者输入数据异常经过规则网关处理后都能转入人工复核真正需要人工干预的比例控制在3%以内。成功率的提升主要来自两个设计一是之前提到过的Agent间状态通信的显式化。用通用框架时Agent之间的数据传递依赖框架内部的会话状态机制一旦某个Agent的输出格式跟另一个Agent的预期不一致整个链条就断了还得靠人去翻日志。我们的共享上下文用命名空间隔离和版本化处理之后Agent读写的是明确的、可校验的数据块格式和字段的变更会第一时间暴露在编排层日志里而不是藏在某个Agent调用栈的最深处。二是规则网关的兜底机制。之前纯通用框架阶段动态任务路由常常需要写不少条件判断逻辑但这些逻辑散落在各个任务定义里没有统一管理和兜底一旦有未预期的输入就会出现“静默失败”——任务不报错、也不继续直到监控告警发现它超过了最长时间阈值。自研规则网关之后所有分支判断都集中到一个地方而且强制要求存在人工复核的兜底出口这类卡死问题基本被消灭了。再看系统资源的利用效率。纯通用框架阶段我们总感觉并发能力上不去——明明底层资源还有很多空闲但系统对并发任务的处理能力就是有限。原因在于框架为了维持会话状态的一致性会在内部做不少串行化处理。混合架构下自研编排层对状态的管理粒度更细更轻资源被释放得更及时系统的整体吞吐大约提升到之前的2.5倍左右。比如某个深夜重点跑批任务以前需要开6个容器才能跑完的负载现在4个容器就够了省下的算力还能同时支持几十个实时查询任务。在模型和Token成本控制上混合架构也带来了清晰的收益。通用框架阶段Token消耗的计算比较粗犷只知道一个任务总共用了多少Token不知道哪一步消耗最多。自研编排层加上共享上下文的版本化记录后Token消耗明细精确到了Agent粒度哪个Agent在多轮对话里重复把同一份数据反复传给大模型、哪个Agent调用链路上有冗余的中间解析过程全部能统计出来。当时统计完发现一个典型的文档审核任务中有一个Agent因为设计得比较膨胀一下就把数据全塞给大模型做细节提取导致Token消耗占了整个任务的一半以上。我们把它的输入逻辑改成“先通过下游规则做字段筛选再只把关键字段输送给大模型”那一项单独就省掉了约25%的Token开销。这个优化完全依托于编排层提供的可观测数据换在通用框架下想定位到“是谁在哪一步浪费了Token”难度非常大。再说说排查故障的体验。混合架构上线后从外部用户反馈“这个任务有问题”到定位到具体失败Agent平均时长从原来的以小时计压缩到十几分钟。这中间最有用的是执行计划的“状态时间线”视图一个任务从开始到结束每个Stage的开始时间、结束时间、参与Agent、输入输出摘要、失败原因都排成一条时间线人一眼就能看出问题发生在哪个环节。比如有一次线上告警说某个跨部门协作的审批任务总是卡在“待人工审批”节点不前进。放在通用框架阶段我们可能要先看一堆日志猜是不是框架哪里的回调没有触发。在混合架构下打开执行计划发现问题很简单那个审批任务在“人工审批”节点的触发条件里引用了共享上下文里一个不存在的字段规则网关判断条件永远不成立于是任务就卡在“待人工审批”状态等待人工介入。我们把字段引用修好之后这类问题的复现率降到了零。6. 经验沉淀什么样的团队和场景适合混合架构项目走到这个阶段再回头看整个架构选择的过程我的结论是混合架构不是所有多智能体系统的最优解但它是“紧急业务需要”和“长期技术可控性不要太高”时最稳妥的选择。如果你现在的业务形态是几十个Agent其次是相对固定的调用链A调用B、B调用C不需要太多动态分支和人工干预那直接用通用框架的效率最高。装好框架、定义好链路、写好Agent一两周就能跑起来省下的开发时间投入业务打磨价值更大。但如果你的业务里存在大量动态路由、状态回放、断点续跑、人工介入修改这类需求同时你又需要按Agent粒度审计Token和计算成本那纯通用框架会很吃力。这种情况下要么接受它的约束要么就直接上自研编排。自研编排不是洪水猛兽它真正的成本在于前期的工程投入和长期的维护义务只要团队里有几个人能持续维护编排层这个成本是可控的。混合架构最舒服的适应场景是那些业务已经运行了一段时间、Agent种类已经比较多、协作流程已经开始变复杂、既不想推倒重来又想尽快拿回控制权的团队。这也是我们当时的状态已经有存量Agent资产不能再等一个漫长的自研周期。有几个经验值得单独写在这里第一个经验自研编排层的原型一定不要做得太大。我当时是先花了不到两周做了一个可以跑通三四个Agent协作的最小原型只定义清楚Stage、Unit、规则网关、共享上下文这四个概念然后把最重要的场景动态路由 人工干预 状态恢复在这个原型上验证跑通才决定大规模投入开发。如果一上来就想把编排系统做成一个平台功能清单列得满满当当那大概率会陷入“永远在设计、迟迟不落地”的泥潭。第二个经验要找一个非常“较真”的人负责规则网关。规则网关是整个编排层里最容易出问题的地方因为它的判断逻辑覆盖了所有分支可能业务上要求“不能漏判”技术上要求“不能误判”。这个人需要对业务场景有很深的理解同时也需要足够的工程严谨性。建议由懂业务逻辑的系统设计者兼任而不是让只懂技术细节的人去做。别等到上线第四周才发现某个边界情况没有兜底整一个任务全卡在那。第三个经验底层框架选了之后要尽量“冷落”它。这句不是玩笑。适配层是混合架构的稳定器保持底层框架能力调用方式的稳定远比频繁地跟进它的新版本功能更重要。我们方案里用的底层框架能力只是它内部能力集合里最小的一部分很多框架自带的编排高级特性我们基本没碰。这样底层框架升级时我们只需要验证少量接口的兼容性省心省力。第四个经验文档一定要写而且要写“为什么”而不是只写“怎么做”。自研编排层这种系统代码在运行中会逐渐积累很多隐性的设计决策。如果不记录当时为什么这么选、为什么那个Agent的命名空间要那样划分几个月后接手的人面对这个系统会非常痛苦。这比写任何高深技术文章都重要因为我见过太多系统因为文档缺失最终变成“没人敢碰的巨石”。最近在规划后续的扩展方向时团队也在讨论要不要把自研编排层的规则网关部分独立成一个内部平台让业务方可以自己可视化配置Agent协作分支不用每次改动都提需求排队等开发。这个想法还在验证阶段但至少从目前的架构形态来看规则网关的集中化和配置化改造空间是足够大的。如果后面真做成了再单独开一篇跟大家一起聊聊。
阅读完成 · 觉得有帮助？
