阿里云 Agentic SOC 团队：从 51 天到 14 天，多智能体协作下的组织重构方法

当 AI 代理承担越来越多的执行步骤后，团队面临的下一个问题不是工具能力，而是协作结构本身。阿里云 Agentic SOC 团队在开发这款安全运营产品时，尝试将多智能体协作嵌入组织流程，并记录了一套具体的重构方法。

问题的起点是顺序交接的固有延迟。传统模式下，产品完成需求、安全完成规则、工程完成实现、测试完成验收，每个阶段产出一个交付物，但客户的问题要到整条链跑完才算解决。加速其中任何一环，总时间的缩减都有限——目标在交接中被反复解读，不同职能各自排队，验收集中在末端，问题沿同一条路径回传。

该团队用一个需求的排期对比说明了差异。顺序交接模式下，需求澄清、设计、安全标准、后端开发、前端开发和集中验收依次进行，总计 51 天。替代方案在任务开始前确立 12 条验收标准，指定一个人对结果全程负责，并将产品体验、工程交付和安全有效性组织为并行任务，周期缩短到 14 天。

这个对比中值得注意的不是天数本身，而是两个结构性变化：验收标准从末端移到起点，问责从逐段转移变为始终归属一个人。前者让各职能从一开始就按同一标准工作，后者消除了交接中目标被反复重新解读的损耗。

要让代理在并行结构中自主推进，团队定义了四类边界。目标边界回答可以解决什么问题——任务目标、优先级、输入范围和预期交付物必须明确，超出范围需要重新确认。质量边界回答什么状态算完成——原始问题必须通过复测，约定评估范围内不得出现回归，证据不足时不得给出确定性结论。权限边界回答可以访问和修改什么——可用数据、工具和环境必须受限，高风险操作须在事先授权范围内，生产变更必须可追溯和可回滚。停止边界回答何时必须交还给人——异常、未授权操作、关键指标恶化、重试或资源消耗达到上限、或无法继续做出可靠判断时，任务暂停。

边界越清晰，代理可以自主推进的范围就越明确。人的精力因此集中在目标设定、关键判断和风险控制上。团队将预期演进路径描述为：从辅助执行，到自主完成单步任务，最终在定义边界内完成自我进化闭环。

评估基础设施是这套方法运转的另一根支柱。团队围绕安全调查任务构建了 SOCBench，在记录阶段包含 211 个真实调查任务，覆盖 16 类事件，评估五个调查阶段和九个维度。问题集、执行配置和评分规范全部版本化，使结果可复现、发布可比较。安全调查是长周期任务，仅检查最终结论会遗漏许多问题，因此评估还需判断环境识别是否准确、入口点是否确认、主攻击链是否重建、影响范围是否检查、最终结论是否有证据支撑。

一个具体案例展示了评估如何将缺陷转化为回归资产。在一次调查中，报告将攻击者和受害者角色颠倒。根因分析发现三个模块缺乏共享判定。修复因此从纠正报告中的一段文字，扩展为结构化重设计：生成攻击者、受害者和判定结果的统一字段，再让报告、时间线和处置建议复用这些字段。复测时，团队重新运行原始场景，确认 A 被识别为攻击者、B 被识别为受害者，同时验证三个模块输出一致。角色字段和检索逻辑随后进入生产发布，对应的回归用例被加入评估基线。此后，任何对模型、提示词或规则的变更都必须使用该样本验证角色判定及其跨模块一致性。一次修复因此产出两个结果：一项有效的产品能力，和一个可反复运行的验证样本。

初步统计显示，从需求创建到完成的平均周期从 50.9 天降至 13.8 天，测量窗口内的吞吐量从 63.9% 升至 98.9%。团队认为下一步需要验证的问题是：同一机制能否从单个项目复制到更多模块；依赖个人主动性的实践能否固化为稳定的团队能力；共享结果标准能否进入日常评估而非仅在特定项目中生效。