AI-7D-SATS 开发笔记 05:为什么企业级 Agent 需要“智能任务角色“分工?
文章目录那个诱人的想法万能 Agent 会出什么问题它会左右手互搏权限成了炸弹出了事你不知道是谁的锅企业场景和 Demo 场景要的不是同一件事角色分工不只是换个提示词AI-7D-SATS 的 8 个核心角色角色之间怎么配合最后说一句什么都能干的 AI大概率什么都干不好。那个诱人的想法做 AI 产品时几乎所有人都会在某个时刻冒出同一个念头能不能做一个超级 Agent什么都让它搞定这想法不是没道理。大模型本来就是跨领域的写代码会分析数据也会把所有权限塞给它让它自己判断该做什么不就完事了吗我们在做 AI-7D-SATS 这个 AI 驱动的性能测试平台时最初也这么想过。但很快就撞墙了。万能 Agent 会出什么问题它会左右手互搏想象一个 Agent同时负责生成测试方案和审核测试方案是否安全。这就像让同一个人既写考卷又批分数。他批的时候脑子里还装着自己出题时的逻辑结果要么过度包容自己的答案要么毫无理由地把它否掉。我们早期就遇到过这个情况。当需求分析、方案设计、脚本生成、审批执行都交给同一个 Agent 时它的行为开始飘忽。有时把合理的压测请求拒掉有时给高风险脚本盖章通过。不是模型不够聪明是角色本身就互相冲突了。权限成了炸弹万能 Agent 要能干所有事就得有所有权限。这在安全层面是个严重问题。一旦这个 Agent 的推理走歪了或者被恶意输入带偏了整个系统的能力就全部暴露出来了。在企业级场景里这是不可接受的。哪怕只有一次误操作代价可能是生产事故。出了事你不知道是谁的锅当所有事情都由一个 Agent 包办时出问题后的排查就变成了一场噩梦是需求理解阶段出错了还是方案设计阶段判断错了还是审批环节漏掉了什么没有角色边界你只能看到AI 说了什么但追不回它凭什么这么说。企业场景和 Demo 场景要的不是同一件事很多 AI 产品在演示时很惊艳但一进企业就水土不服根本原因是两个场景对可靠性的要求差了一个量级要求Demo 演示企业落地出错了怎么办重跑一次可能是生产事故权限管理基本不需要最小化、分层、有审批链能不能追溯不重要每一步必须可查、可回滚输出格式大概对就行必须是机器能直接读的结构协作方式一个 AI 搞定多角色流水线人机配合企业里需要的不是一个全知全能的超级个体而是一个各司其职的专业团队。角色分工不只是换个提示词很多人以为给 Agent 分工就是写几个不同风格的 System Prompt让一个负责需求分析语气另一个负责安全审核语气。这只对了表面一层。在 AI-7D-SATS 的设计里一个角色是由五个维度共同定义的。第一个维度是职责边界。每个角色该管什么、不该碰什么都是写死的约束。需求解析 Agent 只负责从业务描述里提炼测试指标它不能生成脚本更不能启动压测。这不是靠模型自觉而是硬约束。第二个维度是工具白名单。每个角色只能访问完成自身工作所需的工具。脚本生成 Agent 看不到审批工具执行评审 Agent 看不到脚本修改工具。这不是信任问题而是设计上的默认闭合你根本不知道门在哪也就谈不上走错门。第三个维度是权限范围。每个角色只能在自己的工作区里读写文件。跨角色的信息传递必须走正式的交接渠道而不是直接翻对方的文件夹。第四个维度是风险等级。每个角色被标注了风险系数低风险的自动通过中等风险的需要人工复核高风险的要经过专门的门禁检查。这决定了流水线在哪里暂停等人在哪里可以全速前进。第五个维度是输出格式契约。每个角色的输出不是自由文本而是结构化的数据对象字段类型、取值范围都有明确定义。下游角色不需要读懂上游说了什么只需要验证格式是否符合要求。五个维度凑齐了一个角色才算定义完整。AI-7D-SATS 的 8 个核心角色基于上面的设计思路我们把性能测试的完整流程拆成了 8 个专业角色角色负责什么风险级别需求解析从业务描述里提取测试目标和容量指标低场景设计设计测试场景矩阵计算并发用户模型低脚本生成生成压测脚本并做安全自检中执行评审审核脚本安全性和执行参数但不执行压测高指标解读分析压测过程中的系统指标识别异常低根因分析对性能瓶颈提出诊断假设和调优建议中容量预测基于历史数据预测容量增长趋势中报告生成生成测试报告草稿区分事实与推断低这 8 个角色覆盖了从需求到报告的完整链路。每个角色在自己的领域里专业但都被限定在明确的边界内算是戴着手铐的专业人士。角色之间怎么配合8 个角色如果各自为战也没什么意义。关键是让它们形成一条可控的流水线。AI-7D-SATS 用三个机制来做这件事。第一个是结构化交接。角色之间的移交不是把聊天记录传给下一个而是一份有格式的交接文件上游输出了什么、必须包含哪些字段、这次移交是自动通过还是需要审批。格式验证不通过流水线停下来不带着错误数据往下走。第二个是消息系统。每个角色只处理发给自己的消息消息里只放摘要和文件引用不传完整数据。如果某个角色处理到一半崩了超过 10 分钟的消息会自动重置流水线不会永久卡死。第三个是人工审批节点。在高风险的移交点上流水线会主动暂停等人来看。人点了通过才继续走人拒绝了就进入待处理状态。AI 可以给建议但高风险的事情得人来定。整体流向是这样的需求解析 ──▶ 场景设计 ──▶ 脚本生成 │ [人工审批] │ ▼ 报告生成 ◀── 容量预测 ◀── 根因分析 ◀── 指标解读 ◀── 执行评审 │ [人工审批] │ ▼ 对外发布不是所有节点都需要人工介入只在真正高风险的边界上设检查点。这样能保证安全也不会让人成为流水线里最慢的环节。最后说一句做这套角色体系核心不是技术难题而是一个产品设计选择你要一个听上去很强大的超级 AI还是一个实际上可信任、可追溯、出了事能查清楚的协作体系万能 Agent 是演示的好素材但落地之后分工明确、权责清晰的多角色流水线才是真正能用起来的东西。企业级 AI 的目标从来不是造一个最强的 AI而是建一个可控、可审计、出了问题能找到人负责的智能协作系统。角色分工就是这个系统最底下那一层。