第2章：目标用户与角色定义
在构建Agent任务编排系统时，模糊的角色定义是导致项目返工的首要原因。业务用户抱怨权限不足，管理员被操作复杂性淹没，而开发人员则因缺乏必要的调试接口而受阻。本章将通过结构化角色定义画布，系统梳理三类核心用户及其需求边界，确保后续原型设计具备清晰的服务对象与场景锚点。
2.1 业务问题：角色混用的代价
在缺乏明确角色定义的团队中，常见的失败模式包括：终端用户直接面对管理员级别的配置表单，因操作门槛过高导致功能弃用；管理员无法从全局监控中快速定位异常Agent，陷入逐条日志的手动排查；开发集成方因缺少沙箱环境，只能在生产环境反复调试接口。这些问题均源于对“谁在用、用来干什么、权限边界在哪”的认知模糊。
常见误区： 将管理员后台的复杂功能直接暴露给终端用户，或者为了满足开发集成方的灵活性而牺牲管理员的审计合规需求。三端之间的边界必须在PRD中明确划线。
2.2 用户访谈与需求拆解
以下是在用户访谈阶段需要重点覆盖的关键问题清单，帮助产品经理穿透表面需求，挖掘真实动机：
| 角色类型 | 核心痛点 | 核心诉求 | 关键交互界面 |
|---|---|---|---|
| 终端用户 （业务执行者） |
任务配置门槛高，无法快速发起符合需求的Agent协作流程 | 自然语言发起、可视化的任务进度、预设模板库 | 轻量级Web端/移动端H5 |
| 管理员 （系统管控者） |
缺乏全局视角，难以监控和治理多个Agent的执行与资源消耗 | 权限管控、审计日志、资源配额、异常告警 | 管理控制台Dashboard |
| 开发集成方 （系统对接者） |
系统封闭，无法将编排能力嵌入自有业务系统 | 开放API、Webhook、自定义插件、Sandbox测试环境 | API文档门户/SDK |
访谈校准提示： 不要直接询问用户“想要什么功能”，而是引导用户描述“完成某项任务时的障碍”。例如，对管理员用户，提问“当Agent执行出现异常时，你通常如何定位和追溯？”；对终端用户，提问“当前发起一个跨部门协作任务，你需要操作几步？”。
2.3 方案表达：三端分离的设计策略
基于角色定义，原型设计应采取三端分离策略，确保Agent编排系统的易用性、可控性与可集成性：
- 用户端（终端用户）： 界面极度简化，聚焦“发起动作”和“查看结果”。使用自然语言输入框替代复杂表单，提供预设的Mermaid模板库降低学习成本。
- 管理端（管理员）： 提供机构管理、角色权限、审计日志、资源监控、审批流配置等中台能力。强调数据可视化和策略的一次配置、全局生效。
- 集成端（开发集成方）： 提供RESTful API、Event Webhook、自定义节点SDK以及API Explorer调试工具。通过Sandbox环境隔离测试流量与生产流量。
核心交付物： 角色定义画布。该画布强制团队在进入原型设计前，对齐每个角色的目标、行为和边界。
2.4 角色关系与交互流程
下图展示了三类角色与Agent编排核心平台之间的典型交互关系：
2.5 指标验证与验收标准
角色定义的合理性必须通过量化指标进行验证。以下是针对三类角色的验收标准参考：
| 角色 | 验收标准 | 衡量指标 |
|---|---|---|
| 终端用户 | 用户可在10分钟内独立创建并启动一个Agent协作流程 | 任务发起成功率 >= 90% |
| 管理员 | 管理员可在1分钟内完成对任意Agent的权限回收或资源限流 | 策略生效延迟 <= 5s |
| 开发集成方 | 开发者可基于API文档在30分钟内完成一个自定义节点的接入联调 | API调用成功率 >= 99.5% |
2.6 交付物模板：角色定义画布
角色定义画布是本章的核心结构化交付物。它强制团队在进入原型设计前，对齐每个角色的目标、行为和边界。请在用户访谈后，为每一类角色独立填写以下画布：
角色名称：[填写，如：业务审批员]
角色类型：[终端用户 / 管理员 / 开发集成方]
核心目标：[一句话描述该角色使用系统要完成的核心任务]
代表性场景：[1-2个具体的业务场景描述]
关键交互对象：[系统内需要交互的其他角色或模块]
权限边界：[该角色能做什么，不能做什么]
默认视图/入口：[用户看到的第一个页面是什么]
成功指标：[完成任务的时效/成功率]
实践建议： 角色定义画布需要与业务方、技术方共同评审。评审通过后，再进入第3章的“场景化任务拆解”。角色定义的颗粒度可以酌情调整，但三类角色（终端用户、管理员、开发集成方）的宏观分类在大多数企业级Agent系统中是普适的。