Workflow Intake Brief：AI 数字员工开工前，先把需求写成可运行任务
Workflow Intake Brief 是 AI 数字员工开工前的任务准入 brief：它把一句模糊需求转换成可运行 workflow 所需的目标、Source Data、产物、Trust Mode、owner、排期和拒绝条件。很多团队每天都把重复、手动、耗时的任务丢给 Agent，例如“帮我做个客户续约分析”“整理一下竞品动态”“把这些发票看一下”。问题不是这些任务不能自动化，而是需求进入 Agent Builder 前太松，导致后面反复补资料、改口径、重跑产物。Axon 的 Workflows 路线要稳定，第一步不是马上建 Agent，而是先把任务写成能运行的 brief。
Anthropic 在 Effective Context Engineering for AI Agents 中强调，进入模型上下文的内容需要被策划和筛选；在 Building Effective Agents 中也把 workflows 与更开放的 agents 区分开来。放到 Axon 里，Workflow Intake Brief 就是把业务意图、上下文和执行边界放在同一张纸上。
一个好 Agent 不是从一句愿望开始，而是从一份能被 Skill 链执行、能被 owner 验收的任务 brief 开始。
从坏需求到可运行 brief
坏需求通常听起来很自然，但对 workflow 来说太危险：
| 模糊说法 | workflow 不知道什么 | brief 要补齐什么 |
|---|---|---|
| 帮我看一下这些客户 | 哪些客户、看什么、交付什么 | 客户清单、判断标准、产物格式 |
| 每周给我一个行业摘要 | 来源、时间范围、摘要深度 | Source Data、频率、接受标准 |
| 自动处理发票 | 识别、对账、归档还是审批 | Skill chain、Trust Mode、异常 owner |
| 写一封跟进邮件 | 收件人、依据、是否发送 | 邮件草稿路径、人工确认边界 |
这和 Context Packets 是前后关系。Context Packets 负责把上下文组织给运行中的 Agent；Workflow Intake Brief 负责判断这个任务是否已经足够清楚，可以进入 workflow 设计。
一份任务准入 brief
workflowIntakeBrief:
request: "prepare renewal risk brief for top 20 customers"
businessGoal: "help account owner decide renewal follow-up order"
sourceData:
required:
- "customer list with renewal date"
- "usage export for last 90 days"
- "support ticket summary"
artifact:
type: "renewal-risk-brief.md"
acceptance: "ranked customers, risk reason, suggested next action"
trustMode:
confirmBefore:
- "send customer-facing email"
- "update CRM field"
owner:
requester: "customer success lead"
reviewer: "account owner"
rejectIf:
- "customer list missing renewal date"
- "usage data older than 30 days"
这份 brief 不追求复杂，它只回答一个问题：这个需求是否已经具备被 Agent Pipeline 执行的最低条件。
brief 比 prompt 更接近业务事实
很多团队把“写好 prompt”当成自动化起点。Prompt 当然重要，但 prompt 通常描述模型如何说话；Workflow Intake Brief 描述业务如何授权任务。两者差别很大。
brief 先固定业务目标，再固定 Source Data、产物和拒绝条件。这样构建 Agent 时，System Skills、User Skills 和 Trust Mode 才能围绕任务组织起来，而不是围绕一句临时指令 improvisation。你可以把它看成 Workflow Runtime Contract 的上游：intake brief 判断“是否值得建”，runtime contract 判断“允许怎么跑”。
三类需求不该进入 Agent Builder
资料范围说不清。
如果 requester 说“你自己找找相关资料”，这更像探索任务，不是可调度 workflow。先把 Source Data 字段 固定下来。
产物无法验收。
“写得专业一点”不是验收标准。产物至少要有文件类型、字段、阅读对象和接受条件。
风险动作没有确认边界。
涉及外发、删除、发布、更新客户记录或覆盖文件时，brief 必须写出 Trust Mode。否则后续界面再漂亮，也只是把风险藏起来。
intake review 的三个问题
步骤 1：问这个需求最后交付什么 artifact，而不是问模型该怎么回答。步骤 2：问哪些 Source Data 是必须的，缺失时是否直接拒绝。步骤 3：问哪些动作需要确认、授权或人工接管。
如果这三个问题都能回答，再进入 AI Workflow 界面 或 Agent Builder；如果回答不了，先不要把它变成自动化。
任务准入问题
Q1：Workflow Intake Brief 会不会让构建 Agent 变慢？
短期会多几分钟，长期会减少重跑和返工。最慢的不是写 brief，而是 Agent 跑完后才发现资料和目标都错了。
Q2：brief 应该由谁写？
业务 requester 提供目标和验收，workflow owner 补齐 Source Data、Skill chain 和权限边界。不要把全部责任丢给模型。
Q3：临时研究任务也需要 brief 吗？
轻量探索可以简化，但只要任务要复用、定时或交给其他人验收，就应该写 brief。
先把一句需求改成 brief
选择一个你最常丢给 Axon 的重复任务，不要先写 prompt。先写目标、Source Data、artifact、Trust Mode、owner 和 rejectIf。了解更多 Context Packets、Runtime Contract 和工作流界面，探索更多任务准入写法后，再开始构建 AI 数字员工。这个小动作会让后面的 Skills 链更稳定，也让业务团队更愿意接受自动化结果。