AI-SDLC工作流设计选型，Agent操作CLI为何成为主流方案

在AI深度介入软件开发流程的当下，一个核心问题浮现：当一次交付需跨越需求、设计、开发、验证与交付五个阶段，且各阶段可能分散在不同会话中时，如何确保流程连贯、产物可控？这不仅是技术实现问题，更关乎AI辅助开发能否从实验走向工程落地。

早期探索中，团队尝试过两种极端路径：一是将全流程逻辑完全交给大模型Agent自主推进；二是将每一步动作固化为脚本，仅让Agent负责填空式执行。前者看似灵活，实则风险显著——模型易因上下文压缩或提示偏差而自由发挥，导致中间产物偏离规范；后者虽稳定性高，却牺牲了AI应有的适应性与创造性，一旦需求微调，整套脚本即需重写。

最终，一种折中但更具工程可行性的方案被采纳：Agent操作CLI。该模式下，CLI（命令行接口）承担流程骨架职能——定义Workflow（流程结构）、Phase（阶段规范）与State（实例状态），并管理产物校验、进度登记与阶段推进规则；而Agent则在每个阶段内部行使决策权，通过调用CLI命令查询当前状态、提交产出、请求进入下一阶段。

这一分工明确的设计解决了三大痛点：其一，流程正确性不再依赖“hook必触发”的脆弱假设；其二，阶段间交接通过标准化文件与状态记录实现，避免信息断层；其三，人在关键节点（如需求确认、重大变更审批）保留最终裁决权，而非全程干预。

具体而言，Workflow是纯拓扑描述，仅声明节点ID、所引用的Phase、依赖关系及输入来源。例如快速交付流程可跳过需求与设计阶段，直接从“开发→验证→交付”启动，无需虚构前置文档。Phase则细化为输入、执行、输出三段：输入来自上游交接或用户请求；执行部分指定目标、执行者（通常为主Agent）、可用skill集合及读取权限；输出则明确必需产物、交接项及其校验合同。

值得注意的是，skill（能力单元）并非一次性全部注入Agent。系统采用分阶段加载机制：每个Phase声明自身所需skill，并通过hook在阶段启动时动态注入；同时，CLI维护一张“skill图”，记录各原子skill在哪些阶段可用、何时加载、为何加载，确保Agent仅接触当前阶段所需的最小能力集，降低幻觉风险。

状态（State）的推进同样经过精心设计。CLI遵循三条核心规则：第一，“检查通过≠推进”，即CLI仅判定产物是否合格，不自动触发下一阶段，必须由Agent显式发起推进请求；第二，“改动不覆盖”，若某阶段因需求变更需回退重做，仅清除下游任务记录，保留已验证产物供复用；第三，“阻塞只挡受影响的部分”，例如任务A缺输入导致阻塞，不影响任务B及其下游继续执行。

此外，CLI对hash与schema的处理也体现工程严谨性：hash仅用于溯源（如配置、知识库、通用产物版本），不参与强制校验；真正实施拦截的仅有四类异常——缺输入、业务失败、越权、写入冲突。这种“宽松定义、严格拦截”的策略，既保障了流程弹性，又避免了过度约束。

在会话中断或上下文压缩后恢复场景中，系统依赖State目录中的快照信息重建上下文。Agent重启后首先调用cli status获取当前进度，再根据State中记录的“卡点原因”与“下一步建议”继续工作，而非从头开始。Hook机制则被限制在固定事件点（如阶段开始、产物登记后），仅作提醒之用，绝不代行决策。

该架构已在实际项目中验证其有效性。相比纯Agent方案，交付产物一致性提升超60%；相较纯脚本方案，面对需求变更的响应速度提高近3倍。更重要的是，它使AI从“黑盒执行者”转变为“受控协作者”——既释放其推理与生成能力，又将其置于可审计、可追溯的流程框架内。

行业层面看，此类设计正成为AI-SDLC平台的底层范式。随着更多企业尝试将LLM嵌入CI/CD流水线，如何平衡自动化与可控性将成为关键分水岭。当前主流开源框架（如LangChain的Workflow模块、Microsoft AutoDev的阶段引擎）均已引入类似“状态机+指令代理”结构，印证了该路径的普适价值。

未来演进方向包括：将State持久化至轻量级数据库以支持多人协同；引入形式化验证对Phase合同进行静态检查；以及探索基于事件溯源（Event Sourcing）的状态回滚机制。但无论技术如何迭代，“流程定义归CLI、决策执行归Agent、关键裁决归人”的三方权责划分，大概率将持续作为AI辅助开发的核心治理原则。