大家好，我是 Ai 学习的老章。重新审视Anthropomorphic营销运营团队的工作流，我发现了一套非常成熟且可复制的Agent工作流设计范式。这套思路通过使用Codex、Claude Code、Dify、n8n等工具，成功解决了数据散落、手动报告制作效率低下的问题。
--91likeyou---
痛点一：每周营销数据周报
Anthropic 营销运营的 Ian 每周要给领导层出一份营销指标周报
理想情况下所有数据都在 Dashboard 里一键导出
但现实永远不是理想情况
- 有些指标确实在 Dashboard 里
- 有些还在数据仓库里，还没人写 query 搬出来
- 有些存在于某个同事上周发的 Slack 消息里
- 新指标可能只存在于某次会议的录音转写里
- 业务变化太快，数据源每周都在变
结果就是 —— 每周花一到两天时间满世界找数据、核对数据、手动拼报告
如果你做过任何形式的”汇总报告”类工作，这个痛点应该非常能共鸣。本质是：数据散落在十几个系统里，没有人力去做实时整合
解决方案：定时任务 + Skill 编排 + 数字溯源
Ian 搭建的自动化系统核心架构是这样的：
周日晚上（定时任务自动运行）：
周一早上 Ian 上班：
整个流程从”一到两天”变成了”两小时以内”，而且 Ian 的时间从”找数据”变成了”审核数据 + 决定叙事方向”
三个关键 Skill：
Skill 名称 功能 核心价值 Prep Skill 驱动报告组装：确定焦点、写标题、展开细节 把报告的”骨架”搭好 Proofreading Skill 每一个数字都必须追溯到可验证的数据来源 解决”AI 编数字”的信任问题 Action-items Skill 把报告中的后续跟进转成 Asana 任务 让报告产生行动，不是写完就完
最让我印象深刻的细节：当数字对不上时 Claude 会主动标记差异，而不是瞎猜一个数填上去。比如销售团队重组后导致报告口径不一致，Claude 直接说”这里有 gap，你要怎么处理？”
这就是 Proofreading Skill 的威力 —— 让 Agent 学会说”我不确定”比让它学会写报告更重要
痛点二：营销活动搭建流水线
第二个场景更复杂
Annabel 负责为每个营销活动搭建技术基础设施
每一个活动（线上研讨会、线下会议、邮件 campaign）都需要：
- Salesforce 建 campaign
- HubSpot 配邮件序列和自动化工作流
- Swoogo 做注册页和活动落地页
- 各平台之间的数据集成打通
- 确认邮件、提醒邮件配置
- 测试验证整个流程
每次都是同样的流程，每次都要手动点几十个按钮。更要命的是 —— 这些平台之间的集成从来就不是”开箱即用”的，总有各种奇怪的边界情况
解决方案：调度器 + 专家 Skill + 独立审计
Annabel 搭建的系统要复杂得多，是个多层架构：
用这张图来理解整体工作流：
Agent 工作流架构：调度器+专家Skill
第一层：Dispatcher Skill（调度器）
- 每小时自动轮询 Slack 请求频道
- 读取新请求，判断类型和优先级
- 给请求盖时间戳（防止重复处理）
- 把任务分派给对应的专家 Skill
关键设计：Dispatcher 本身不做任何具体工作，只做路由和调度。这样每个专家 Skill 可以独立迭代升级，不影响其他部分
第二层：五个专家 Skill
Skill 职责 复杂度 Event-Build 端到端活动搭建：CRM → 自动化 → 活动平台 → 邮件 → 落地页 → 集成 最高 Webinar-Landing-Page 专做 Webinar 落地页生成 中 Apply-to-Attend 处理注册流程中的临时变更 中 Approval-Support 处理活动审批流程，定时发提醒邮件 低 Data-Import 清洗参会者列表，处理数据导入 中
第三层：Audit Agent（审计代理）
这是整套系统最精妙的设计 ——
Audit Agent 是一个全新的 Claude 实例，启动时零上下文，不知道之前发生了什么。它的工作是：
为什么要用独立实例？因为如果用同一个 Agent，它可能会”记住”自己刚刚搭建的过程而跳过验证步骤。零上下文确保了审计的客观性
第四层：Manager Agent（经理代理）
Annabel 还搞了一个独立的”经理” Agent。当某个 Skill 跑出问题时，她不是自己去查 log —— 而是打开 Manager Agent 问它”看看刚才那个活动搭建哪里出了问题”，让它分析并建议修改
最核心的方法论：Skill 的持续进化
整篇案例最有价值的不是具体的技术方案，而是他们运营 Skill 的方式：
1. 每次 session 结束时的”反思”环节Ian 每周周报做完后，会问 Claude：”这次过程中有什么值得记录进 Skill 的？”
- 销售团队重组了？→ 记进 Skill
- 发现一个新的数据源？→ 记进 Skill
- 某个标题的写法被领导表扬了？→ 记进 Skill
2. 让 Agent 说出”哪里难”新流程第一次跑完后，Annabel 会问 Claude：”你觉得我给的指令哪里不好理解？”然后把 Claude 的反馈直接写回 Skill
这个思路太妙了 —— AI 读指令的方式和人写指令的方式是不一样的。让 AI 自己说出理解困难的地方，再反哺优化指令，形成正向循环
3. 重复纠正 = 该写 Skill 了如果你发现自己在纠正 Agent 同一个错误第三次，就该把纠正内容固化成 Skill 指令
国内怎么复现这套方案
Cowork 能力 国内替代方案 具体工具 Scheduled Tasks（定时任务） cron + Agent API Codex 任务 / cc-connect cron / n8n 定时触发 Skills（Skill 指令） Markdown 指令文件 Claude Code Skills / AGENTS.md / Dify 提示词模板 Connectors（平台连接器） MCP Server / API 封装 自己写 MCP 或用现成的连接器 Multi-Agent 调度 Agent 编排框架 CrewAI / AutoGen / 自定义调度脚本 Audit Agent（审计实例） 新 session 零上下文 Codex 新任务 / Claude Code 新 session
场景1 复现建议（周报自动化）：
定时任务 → 触发脚本 → MCP/API 拉数据（飞书文档/数据库/企微消息） → Agent 按 Skill 模板组装报告初稿 → Proofreading Skill 做数字溯源 → 人工审核确认方向 → Agent 展开细节 + 生成 Slide → Action-items 转待办
场景2 复现建议（活动/任务流水线）：
Dispatcher Agent（定时轮询任务队列） → 路由到对应专家 Agent → 专家 Agent 执行跨平台操作 → 独立 Audit Agent 验证（新 session） → 人工最终确认
四条黄金经验
原文给的四条建议，每一条都是从实战中提炼出来的：
重复纠正两次以上 → 写进 Skill不需要你自己写 —— 告诉 Agent “把我刚才的纠正整理成 Skill 指令”，它能自己写
先搞 Proofreading Skill这是建立信任的第一步。如果 Agent 输出的数字没有来源追溯，你就永远不敢放心交给它
让 Agent 反思”哪里难”AI 理解指令的方式跟人不一样。第一次跑完问它哪里理解困难，比你自己改十遍 prompt 有效得多
善用定时任务能每周日自动跑的事就不要让人记着去做。人会忘，cron 不会
总结
Claude Cowork 国内无法直接使用
但这篇案例真正有价值的东西 —— 定时触发 + Skill 体系 + 调度分发 + 独立审计 + 持续反思进化 —— 这一整套方法论是工具无关的
核心思想就一句话：把重复性工作拆解成 Agent 能跑的环节，把验证环节独立出来保证质量，把每次纠正都回写成 Skill 让系统越来越聪明
花两天做手工活，还是花两小时审核 Agent 的输出 —— 只要你把第一版 Skill 搭起来，后面就是滚雪球
🔥 热词：#Claude · #Cowork · #Agent · #Anthropic · #Dashboard · #用不了没关系 · #学会这套Agent工作流思路就够了 · #大家好