digital_employee

数字员工组建

把一句业务需求，变成「一支分工明确的数字员工团队 + 一条把他们串起来的工作流」。用户不必逐个设计、逐个手工创建 Agent。

何时使用

• 用户描述了一个需要多个角色协作的目标（"帮我搭一个做竞品分析的团队"、"我要一套从线索到成交的销售流程"）。
• 用户说"建几个 Agent / 数字员工帮我做 X"、"把 X 这件事自动化成一支团队"。
• 现有 Agent 不足以覆盖需求，需要新建专才角色。

不应使用

• 一个 Agent 就能完成 → 直接用 chat_with_agent 或现有 Agent。
• 只是想编排已存在的 Agent 协作 → 用 multi_agent_collaboration。
• 只是想把流程做成工作流，且员工都已存在 → 直接用 workflow_draft_generate。

工作流程

第一步：理解需求，盘点现状

1. 读懂用户的业务目标、产出物、是否有触发条件（定时 / 来消息时）、要不要审批、结果发到哪个渠道。
2. 调用 listAvailableAgents() 看现有员工——能复用就复用，不要重复造同名角色。
3. 调用 list_capability_catalog() 拿到可分配的技能名和工具名清单。后续 create_employee 只能用清单里的真实名字，不要臆造。

如果需求关键信息缺失（产出物、角色边界），先向用户澄清一句再继续，不要凭空假设。

第二步：设计团队（2–6 个角色）

把目标拆成互补的角色，每个角色给出：

• name：工作区内唯一，用英文 kebab-case（如 market-research-analyst）。
• description：一句话职责，工作流编排器会据此分配任务。
• systemPrompt：定义这个员工的专长、视角、工作方式——要具体，别写空话。
• skillNames / toolNames：从 list_capability_catalog() 里挑这个角色真正需要的；留空则继承全局默认能力（通才）。专才角色建议显式收窄。
• agentType：默认 react；只有当角色需要"先规划再分步执行"时才用 plan_execute。

设计原则：

• 角色数量 2–6 个，宁少勿滥；每个角色职责单一、边界清晰。
• 避免两个角色职责重叠。
• 一般不指定 modelName，留空用工作区默认模型；用户明确要求某模型时才填。

第三步：逐个创建员工

对每个设计好的角色调用一次 create_employee(...)：

create_employee(
  name="market-research-analyst",
  description="负责竞品功能、定价、市场动态的检索与结构化整理",
  systemPrompt="你是资深市场研究分析师……（写清专长与产出格式）",
  skillNames=["news", "web_search"],   // 来自 list_capability_catalog，可留空
  toolNames=["web_search"]              // 来自 list_capability_catalog，可留空
)

• 工具会返回 agentId 和实际绑定的技能/工具；记下每个员工的 name，下一步要用。
• 若返回 [error]（如重名），换个名字重试，不要中断整个流程。
• 创建即启用——员工立刻可被工作流引用。

第四步：编排工作流

所有员工创建完成后，调用一次 workflow_draft_generate(description=...)。在 description 里：

• 点名第三步创建的真实员工（用它们的 name），说明执行顺序、依赖关系、并行还是串行。
• 写清触发条件、是否需要审批、产出发往哪个渠道。

由于员工已经落库，workflow_draft_generate 会读到它们作为可用数字员工，直接引用真实 agent，而不是填 TODO_*_AGENT 占位。

工作流只会保存为草稿，不会自动发布、不会自动启用触发器。这是安全约定——让用户在工作流编辑器里 review 后再 publish。

第五步：汇报

给用户一份清晰小结：

• 创建了哪些员工（name + 职责 + 绑定的关键能力）。
• 生成的工作流草稿名称、id、各步骤如何串联。
• 草稿编译预校验是否通过、有无缺失字段需要补。
• 明确告知：工作流是草稿，请到工作流编辑器确认后再发布。