infometa Agentic OPC Workflow — 让 Agent 可执行，但不替你判断
Agentic 的核心不是“多弄几个 Agent”。
真正有用的是：把目标、上下文、任务边界、输出格式、验收标准和人类判断门组织清楚。这样 Agent 才能放大你，而不是把你带跑。
什么时候用
用户想把一个 OPC 项目、验证计划、内容流程、调研流程、产品推进流程交给 Agent 协作时使用。
工作流程
Step 1 · 明确任务类型
判断用户要的是：调研、用户访谈、原型验证、内容生产、销售线索、复盘，还是决策压测。
如果上下文不足，先用 AskUserQuestion 问 1 个最关键问题，不要一次问一串。优先问：
这个 Agent 最容易在哪一步替你做了不该做的判断？
Step 2 · 建上下文交接包
按 @references/agent-context-handoff.md 把背景、目标、约束、材料、反例、验收标准写清楚。
Step 3 · 拆任务卡
每个 Agent / 每个任务都要有：角色、输入、动作、输出、验收标准、禁止事项。
Step 4 · 放人类判断门
按 @references/human-gates.md 设置关键检查点：Agent 到哪一步必须停下来等人确认。
Step 5 · 设计 OPC 验证闭环
用 @references/opc-validation-loop.md 把流程落到 72 小时 / 7 天 / 14 天验证动作上。
输出格式
## Agentic 工作流目标
{这套工作流要帮用户放大什么能力}
## Context Pack
{给 Agent 的完整上下文}
## Agent Task Cards
### Agent 1：{角色}
- 输入：
- 动作：
- 输出：
- 验收标准：
- 禁止事项：
## Human Gates
| 节点 | 为什么必须人工判断 | 检查问题 |
|---|---|---|
## 7 天验证路线
- Day 1-2：
- Day 3-4：
- Day 5-7：
## 停止线
{N 天内 X 指标没达到 Y，就暂停/转向/缩小范围}
规矩
- 不要设计大而全自动化。OPC 要小、快、可验。
- 不要让 Agent 直接替用户做对外承诺。
- 每个 Agent 任务必须有验收标准。
- 每条工作流必须有停止线。
- 需要补上下文时只问 1 个问题；问完先产出一个可执行版本，不要把用户拖进长访谈。