一、前言
2025年10月，我们首次接触Skill技术时，就真切感受到了它的价值。当时我们正投身AI Agent开发，深陷一个核心困境：大模型有强大的抽象能力，却难以落地到具体业务——不同场景的能力模块杂乱无章，既无法复用，也难以协同。而Skill技术恰好能解决这个问题，它能把大模型能力拆解为独立、可调用的Skill模块，还能按业务需求灵活组合，让技术落地不再是“空中楼阁”。基于这份判断，我们快速启动调研，凭着对业务痛点的感知推进实践，到11月中旬就完成了多场景验证，顺带搭建起基础的Skill框架，攒下了第一波能直接复用的工程化经验。2026年1月，基于这些实践沉淀，我们决定走开源开放路线，计划把项目重构后落地到ooderAgent（MIT协议开源工程）。选择SDD（规范驱动开发）规范，对我们来说是倒逼自己跳出旧模式的尝试——此前开发全靠经验摸索，团队协作没统一标准，代码越写越乱，后续维护成本极高。SDD“先定规则、再生成代码”的思路，刚好能解决开源项目最核心的“规范化、可复用”问题。接下来，我就以团队视角，顺着开发轨迹，聊聊SDD在ooderAgent中的落地全流程，分享那些从实际踩坑、复盘里总结出的经验与感悟。
二、SDD与ooderAgent的适配根基
我们研发ooderAgent，本质是想做一款轻量化、标准化的开源Agent框架，解决自己和同行都遇到的多Agent协作乱、Skill集成无章法的问题。当前AI Agent技术发展快但缺乏统一标准，我们希望能提供一套经过实战验证、可直接复用的工程化方案。它的标准化架构不用额外改造，就能承接SDD规范，这也是我们最终选择它作为落地载体的核心原因。
1. 前期准备与规范模型
落地SDD前，我们没有搞复杂流程，只聚焦三项核心准备，为适配筑牢基础：一是对齐开源协议，确保SDD规范与ooderAgent框架兼容无冲突；二是细化业务场景，把模糊需求转化为明确范围，避免后期返工；三是守住架构底线，为分布式部署做好铺垫。基于这三点，我们引入ISPI四层规范模型（需求、系统、协议、实现），制定团队与AI共同遵循的执行规则，相当于为后续开发铺好了清晰的“轨道”。
2. 核心适配要点
适配过程中，我们紧盯三个关键节点，确保SDD不流于形式、真正落地：一是组件对齐，将ooderAgent的End Agent、Route Agent、MCP Agent与SDD分层规范一一对应，充分复用前期积累的Skill框架经验；二是界定Skill边界，通过SDD明确Skill的功能范围、调用方式及协作逻辑，避免大模型输入输出混乱；三是借力Scene/Group机制，提前预设协作规则，让同场景Agent自动组队通信，减少人工介入的麻烦。
三、SDD实操：以协议为核心的落地路径
做好适配铺垫后，我们按实际开发节奏优化了SDD落地流程，核心思路就是“先定死协议、再拆解需求、最后闭环落地”，每一步都围绕可执行性推进，全程清晰可控。
1. 协议打底：以MCP Agent为核心构建《协议接口基准文档》
开发的第一步，我们没有急于写代码，而是先联合团队敲定《协议接口基准文档》。全程以MCP Agent为中枢核心，刻意简化北上、南下协议逻辑，确保团队全员都能看懂、会用。MCP Agent承担着全局调度、协调的核心职责，所有协议都围绕它设计，从根源上杜绝了多组件间协议混乱、对接不畅的问题。其中，南下协议是上层系统向MCP Agent下发指令的通道，核心是明确“要做什么”——比如启动特定Skill任务、调整Agent协作关系、下发配置参数等，统一采用“指令类型+核心参数+执行时限”的简洁格式，摒弃冗余字段，保障MCP Agent快速解析执行。北上协议则是MCP Agent向上层反馈的通道，主要同步三类信息：任务执行进度与结果、系统运行状态（各Agent在线情况、资源占用）、异常告警（通信中断、任务失败及原因），让上层实时掌握系统动态。除此之外，文档还明确了MCP Agent与Route Agent、End Agent的内部通信规则，本质是将北上、南下协议的逻辑延伸至系统内部，确保指令精准传递、状态完整回传，整个协议体系简洁高效、无冗余设计。
2. 需求拆解与工程定位
协议定好后，我们以协议为基准，将需求拆分为五大模块，确保每一项都落到具体动作上：一是统一术语，避免团队沟通出现理解偏差；二是梳理业务元数据，明确各场景核心数据及流转规则；三是理清执行流程，让全员掌握任务从启动到收尾的完整链路；四是划定开发约束，明确敏感数据脱敏、分布式部署支持等硬要求；五是拆分工程职责，按Agent角色划分五个独立项目，明确各项目定位后，再对照需求逐一校验，确保任务无遗漏、责任到岗。
3. 架构搭建与代码生成
需求梳理清晰后，我们快速搭建系统骨架。技术路线选定Spring Boot，既能适配前期的分布式架构，又无需额外学习新框架，有效降低开发成本。我们重点打磨代码元数据模型，结合既定的术语与协议，明显感受到LLM对业务的理解更透彻了，生成的代码不仅规范，还能主动补充细节设计，大幅减少了人工优化的工作量。
4. 集成闭环与落地验证
各工程开发收尾后，我们围绕业务场景开展集成重构，将分散的模块整合归一，剔除冗余设计，优化组件间交互逻辑。随着整合推进，LLM对我们业务的认知持续深化，给出的方案也越来越贴合实际需求。最终落地时，我们采用“AI生成基础代码+人工优化核心逻辑”的模式，依托Trae Solo搭建测试环境，各工程先独立调试，无问题后再分批集成，收集全量日志开展回归测试，确保系统完全符合协议与需求标准。
四、实践总结与感悟
回望整个实践，ooderAgent的三层架构（执行-路由-管控）为SDD落地提供了坚实支撑：End Agent负责具体任务执行，Route Agent保障指令传递，MCP Agent统筹全局调度，三者各司其职且通过统一协议联动，精准解决了此前多Agent协作混乱的痛点。而我们搭建的核心组件体系，从Agent SDK、Skill Framework到VFS存储、UDP通信模块，均围绕“标准化、可复用”目标设计，与SDD理念高度契合，这也是二者能顺利融合的重要原因。实践中我们也踩了不少坑，好在都逐一找到了解决办法：多工程并行开发混乱，就用“角色拆分+协议分层”明确分工，规避协作冲突；长程任务反复重启，就拆解为原子异步任务，借助VFS保存状态，实现重启后无缝续行；不同大模型适配效果不均，就采用“主Skill+辅助Skill”模式优化；AI自测出现幻觉，就强制各Agent独立记录日志，汇总后交叉校验；UDP通信不稳定，就针对性补充保障机制。这些经历让我们明白，SDD不是万能的，但能为解决问题提供清晰框架，而ooderAgent的灵活性则赋予了我们调整优化的空间。这段旅程也让我们对技术边界有了更清醒的认知，摒弃了不切实际的幻想：SDD作为一种方法论，必须通过代码审查、测试校验等手段强制落地，无法自动生效；Agent自动建组需要基础配置铺垫，复杂集群关系仍离不开人工干预；Agent SDK仅提供基础能力封装，复杂业务逻辑还需自定义开发；现有工具对开源Agent生态的支持尚不成熟，诸多场景仍需自主探索。这些不足也指明了后续优化方向，我们计划在多模型适配、Skill协同调度、日志验证体系、边缘计算支持及可视化工具开发上持续深耕。总体而言，这次用SDD重构ooderAgent的尝试十分成功。我们不仅摆脱了“凭经验开发”的混乱状态，将开发流程纳入规范化轨道，更沉淀了一套能应对实际业务的开源Agent工程化方案。在AI Agent技术高速发展却缺乏统一标准的当下，ooderAgent的这些实践或许能给行业同仁提供一些实在参考，而SDD与开源框架的结合，也让我们看清了技术规模化落地的可行路径。我们期待与开源社区的伙伴们携手共建，在实际应用中不断完善方案，让AI Agent技术真正走进更多业务场景、创造实际价值。
