gingiris-1031 AI Agent Workflow Playbook — 从专家经验到可规模化交付
适用于：把研究、营销、运营、分析、内容生产等高认知任务，改造成可测量、可纠错、可复用的 Agent 工作流。
先判断：这个任务该不该 Agent 化
只有同时满足以下多数条件才进入自动化：
- 输入和合格输出可以被描述；
- 专家能说清“什么是对、什么是错”；
- 任务重复发生，或交付成本随客户数近似线性增长；
- 关键数据能合法、稳定取得；
- 错误可以在发布、付款、删除或对外发送前被拦截；
- 结果能通过 rubric、样例集或业务指标复核。
如果任务低频、目标持续变化、没有验收口径，先做人工 SOP，不要先搭多 Agent。
1. 建立基线，不要直接写 Prompt
选择 10–30 个近期真实任务，记录人工基线：
| 指标 | 定义 |
|---|---|
| 任务成功率 | 首次交付通过验收的任务数 / 总任务数 |
| 一次通过率 | 无返工即通过的任务数 / 总任务数 |
| 周期 | 从收到完整输入到可交付输出的 elapsed time |
| 人工工时 | 研究、制作、复核、返工所花人时 |
| 单次成本 | 模型、工具、数据和人工复核成本之和 |
| 重试率 | 发生工具重试或整段重做的任务占比 |
| 严重错误率 | 错误发布、错误付款、数据泄露等高风险事件占比 |
没有这张基线表，就只能证明 Agent “能跑”，不能证明工作流变好了。
2. 从业务链路拆 Skill
先画业务链路，再按可验收结果拆 skill：
需求澄清 → 数据获取 → 证据整理 → 分析 → 产出 → 质检 → 人工批准 → 交付 → 反馈沉淀
每个 skill 至少包含：
name: competitor-evidence-pack
input_contract:
required: [product, market, competitors, time_window]
output_contract:
required: [claims, source_urls, captured_at, confidence, unknowns]
tools:
allow: [search, fetch]
deny: [publish, delete, payment]
acceptance:
- every material claim has a source
- source capture time is recorded
- unknown facts are labeled, not guessed
escalate_when:
- authenticated source is inaccessible
- sources conflict on a decision-critical fact
优先做单一职责 skill。只有当步骤间存在清晰依赖时，才增加 orchestrator。
3. Harness：让系统知道边界、记住纠错、持续评测
Prompt 只描述一次交互；harness 管理长期运行环境。至少包含五层：
- Context：品牌、客户、目标、禁区和数据权限；
- Skills：通用技能与客户专属技能分离，按任务选择调用；
- Memory：只沉淀经过确认的偏好、错误和纠正，不把猜测写成事实；
- Evaluation：固定样例集、rubric、回归测试和业务指标；
- Observability：每步输入摘要、工具调用、证据、成本、耗时、重试和最终批准人。
一次失败的正确处理方式不是无限加提示词，而是：记录失败类型 → 判断是数据、工具、推理还是验收问题 → 修改对应层 → 用旧样例集回归。
4. 选择编排方式
| 模式 | 适用情况 | 主要风险 |
|---|---|---|
| 顺序 | 后一步严格依赖前一步输出 | 上游错误级联 |
| 并行 | 多个独立来源或方案可同时产生 | 合并冲突、重复成本 |
| 路由 | 不同任务应调用不同专长 | 分类错误 |
| 主管—执行者 | 任务可拆成多个独立子任务 | 主管成为瓶颈 |
| 评审—修订 | 输出有明确 rubric，可迭代改进 | 无界循环、成本失控 |
默认从单 Agent + 多 skill 开始。只有观测数据证明吞吐或专长隔离确实需要并发，才升级为多 Agent。
5. 人工介入与权限
以下动作默认需要人工批准：
- 对外发布、群发、私信或代表个人表态；
- 付款、退款、采购和价格承诺；
- 删除、覆盖或批量修改数据；
- 使用未获授权的个人数据；
- 低置信度但会影响客户决策的结论。
连续任务不要重复索取同一授权；记录授权对象、范围和有效期。权限不足时返回缺失项和恢复路径，不要假装完成。
6. 上线门槛与回滚
按四阶段推进：
- Shadow：Agent 生成结果但不影响人工交付；
- Copilot：人工选择、修改并批准每次输出；
- Guarded automation：低风险步骤自动执行，高风险动作审批；
- Autonomous：仅用于已稳定通过回归测试、可完整审计且可回滚的边界任务。
每次版本变更比较同一批任务的成功率、周期、人工工时、成本和严重错误率。任一安全指标恶化，回滚到上一稳定版本。
真实案例：营销洞察交付从项目制走向产品化
来源：Gingiris 飞书会议纪要《AI agent实践落地困境与规模化尝试分析》，2026-05-10。以下是会议中的经验陈述，不是独立审计或随机对照实验。
旧链路
- 运营人员手动浏览小红书约 10 天到 2 周；
- 早期自动化把信息收集压缩到数小时，但报告仍依赖人工思考、迭代和制图；
- 一个高质量 PPT 交付需要约 15 人、3–4 周，难以复制到 100 或 1,000 家客户。
新链路
- 将达人筛选、赛道分析、人群识别、内容与投放建议拆成通用 skill 和客户专属 skill；
- 把正例、反例、验收标准、记忆和反馈链路放进 harness；
- 系统先识别任务，再组合调用技能；专家负责策略判断与最终验收；
- 结果、洞察过程和纠错留在系统中，供下一次复用。
已报告结果
- 约 15 人 × 3–4 周 的 PPT 项目，变为 1 名策略师 + AI 系统，5 天一次通过；
- 一份竞品分析与投放建议可在 不到 1 天 内交付；
- 会议报告的服务成本相较早期方式下降 两个数量级；
- 专业策略师仍需约 2–3 个月 学习并迁移到新工作方式，说明专家并没有被“零成本替代”。
这个案例真正验证了什么
它支持“把专家判断编码为 skill + harness，可以减少交付周期和边际人工”的判断；它不证明所有行业都能获得相同幅度，也没有披露统一口径下的错误率、模型成本和客户长期留存。因此复用时必须重新建立本团队基线，并补测质量、重试和严重错误率。
7 天落地清单
- Day 1：选一个高频任务，收集 10–30 个真实样例和人工基线；
- Day 2：定义输入、输出、rubric、禁区与人工审批点；
- Day 3：拆成 3–7 个单一职责 skill；
- Day 4：接入证据记录、日志、成本与失败分类；
- Day 5：Shadow replay，修复最高频失败；
- Day 6：Copilot 小流量运行，比较人工基线；
- Day 7：决定继续、回滚或只自动化其中一段。
最终输出模板
每次工作流评审必须交付：
- 业务链路和自动化边界；
- skill 清单与输入/输出 contract；
- 编排图和工具权限；
- 评测集、基线和本次结果；
- 人工介入、失败恢复与回滚方案；
- 下一轮只改一个变量的实验计划。
Built by Gingiris. Historical figures are labeled as reported case evidence; do not present them as guaranteed outcomes.