A14. 运营 Agent 化 | Agentifying Operations

路径: Path A: 运营人 · 模块: A14 最后更新: 2026-07-31 难度: 中级 预计时间: 每天 1 小时，1-2 周 前置模块: F2 Prompt 工程（尤其是 §5 从 Prompt 到 Skill）

章节导航

1. 先搞清楚 Agent 化到底省了什么 · 2. 数据源盘点 · 3. 任务分级 · 4. 把现有 Prompt 变成技能 · 5. 三个可以直接抄的运营 Agent · 6. 常见陷阱 · 7. 完成标志

本模块你将学会

A 路径前面 13 章教的是“怎么写 Prompt 让 AI 帮你做事“。这一章讲下一步：怎么让这些事不再需要你每次手动触发。

完成本模块后，你将能够：

• 判断你的哪些运营环节值得 Agent 化，哪些现在做纯属浪费
• 盘清每个环节的数据从哪来——这是 Agent 化能不能成立的前提
• 划出人工确认的边界，知道哪些动作绝不能让 Agent 自己做
• 把 A 路径已有的 Prompt 改造成可复用的技能文件
• 搭出三个具体的运营 Agent：日报、库存预警、差评响应

一句话概括：Agent 化不是“把 Prompt 换个地方放“，而是取消你在中间搬运数据的那一步。数据搬不动，Agent 化就是伪命题。

1. 先搞清楚 Agent 化到底省了什么

拿本库最典型的一个工作流举例。你现在做「每周广告优化」的实际动作是：

1. 登录 Seller Central                      ← 人工，2 分钟
2. 下载搜索词报告                            ← 人工，3 分钟
3. 打开 ChatGPT，粘贴数据，贴 Prompt          ← 人工，2 分钟
4. 等 AI 分析                                ← AI，1 分钟
5. 读结果，判断哪些建议要采纳                  ← 人工，10 分钟
6. 回到后台，逐条执行调整                      ← 人工，15 分钟

AI 只做了第 4 步。 其余 32 分钟全是人工，其中第 1、2、3、6 步是纯搬运——没有任何判断，只是把数据从一个地方挪到另一个地方。

Agent 化的价值就在这四步。第 5 步（判断要不要采纳）不该被自动化，那是你的工作。

所以正确的目标不是“让 Agent 全自动跑广告“，而是“把 32 分钟的搬运压到 10 分钟的判断“。 把第 5 步也自动化的人，通常在第一个月就会遇到一次需要人工善后的事故。

2. 数据源盘点：Agent 化的前置条件

上一节的第 1-2 步能不能自动化，完全取决于数据拿不拿得到。这是本章最实际的一节，请先做完这张表再谈别的。

2.1 把你的数据源分成三类

结论很直接：先把 A 类的环节 Agent 化，B 类退而求其次做半自动，C 类现阶段别碰。 见 B6 §9 Computer Use 里对 C 类的取舍讨论。

2.2 盘点表模板

对你的每个运营环节填一行。这张表填完，哪些能做、先做哪个，答案自己就出来了。

优先级就是最后一列除以取数难度。 搬运时间长、数据又是 A 类的，第一个做。

2.3 一个诚实的判断

如果你盘完发现大部分是 C 类，那么现阶段你该做的不是 Agent 化，而是先解决数据可得性——换个能导出的工具、申请 API 权限、或者接受某些环节就是手动。

强行用 computer use 去啃 C 类，多数情况下比人工还慢还贵，而且平台一改版就全废。

3. 任务分级：哪些交出去，哪些留在手里

判断标准只有一个：错了能不能收回来。

3.1 三级分类

绿灯 —— Agent 可以自主做完

共同特征：只读，或产出物只在内部流转，错了改一下就行。

• 拉数据、汇总、生成日报
• 给 Review 打标、分类
• 生成 Listing/文案的草稿
• 异常检测和告警（只通知，不动手）

黄灯 —— Agent 做，但要你点头才生效

产出物会对外，或者会改变平台上的状态。

• 调整广告出价和预算
• 修改 Listing 内容
• 回复客户消息
• 提交补货建议

做法是让 Agent 把改动准备好但不提交，列成一张待确认清单给你，你勾选后它再执行。

红灯 —— 永远不要交给 Agent

• 下架商品、删除 Listing
• 任何退款、赔偿、资金动作
• 接受平台协议、修改账户设置
• 大额采购下单

这一档不是“现在还不行，以后可以“，而是结构性地不该自动化——因为出错的代价不对称：省下的是几分钟，赔上的可能是一批货或一个账号。

3.2 一个容易被忽略的黄灯项

“回复客户消息“很多人当绿灯做，这是错的。 客服回复一旦发出就收不回，而且模型很乐意替你承诺退款金额、补发时效、平台政策例外——这些你没授权它承诺。

本库所有客服类 Prompt 里的 <文案纪律> 都写了这一条，Agent 化时必须原样带过去，并额外挂人工确认。

4. 把现有 Prompt 变成技能

F2 §5 讲了三种形态的差异和迁移清单。这一节给 A 路径的具体做法。

4.1 迁移一个 Prompt 的五步

以 A3 的否定关键词 Prompt 为例：

第 1 步：确认数据源。 它要的是搜索词报告 → Amazon Ads API 可取 → A 类，可以做。

第 2 步：把“粘贴数据“换成“从哪读“。 原 Prompt 里 [粘贴数据：搜索词、匹配类型…] 改为声明数据来源和字段。

第 3 步：输出改成机器可读。 原来输出“否定词列表 + 理由“是给人读的散文，现在要改成结构化格式，因为下游要拿它去调 API。

第 4 步：加前置检查和失败行为。 数据行数太少、字段缺失时不要硬跑。

第 5 步：标出黄灯动作挂人工确认。 加否定词会影响流量，属于黄灯。

4.2 迁移后的样子

---
name: negative-keyword-harvester
description: 每周分析 Amazon 搜索词报告，产出待确认的否定关键词清单。
  需要过去 30 天的搜索词报告（含花费、点击、订单、销售额字段）。
---

<数据源>
Amazon Ads API：搜索词报告，过去 30 天，字段需含
searchTerm / matchType / impressions / clicks / cost / orders / sales
</数据源>

<前置检查>
- 报告行数 < 200 时停止，报告"样本不足，本周跳过"
- 缺任一必需字段时停止并列出缺失字段
</前置检查>

<角色>Amazon PPC 否定关键词专家</角色>

<任务>
按四象限分类，产出精确否定 / 短语否定 / 观察三类清单
</任务>

<数据纪律>
- 只使用报告中出现的数字，不要估算，不要引用记忆中的行业均值
- 每个否定建议必须能追溯到具体的搜索词行
</数据纪律>

<失败时的行为>
数据不足或校验不通过时停止并报告，不要用推测值继续
</失败时的行为>

<输出格式>
JSON: [{term, matchType, action: "negative_exact"|"negative_phrase"|"watch",
        reason, cost_30d, orders_30d}]
</输出格式>

<人工确认>
本技能只产出待确认清单，不直接调用 API 写入否定词。
用户勾选后，由调用方执行写入。
</人工确认>

对比一下：原 Prompt 的任务描述和数据纪律一字未改，新增的全部是“从哪读、什么时候不该跑、产出给谁用、谁来点头“。

5. 三个可以直接抄的运营 Agent

按实施难度排序。三个都遵循同一个模式：Agent 取数 + 分析 + 产出待确认清单，你点头后才执行。

5.1 每日运营日报（绿灯，最容易起步）

为什么先做这个：全程只读，没有任何写操作，出错成本接近零。适合用来观察 Agent 的判断质量。

触发：每天早上 8:00
数据源：SP-API（销量、库存）+ Ads API（广告花费）
动作：
  1. 拉昨日数据
  2. 对比前 7 天均值，标出偏离超过阈值的项
  3. 生成日报，推送到 Slack/邮件
人工确认：不需要（纯只读）

关键设计：日报里每个数字都要标注取数时间和来源，不要让 Agent 做任何“预估“。它的工作是呈现和标注异常，不是解释原因——原因由你看到异常后自己判断。

5.2 库存补货预警（黄灯）

触发：每周一
数据源：SP-API（库存、历史销量、在途）
动作：
  1. 计算各 SKU 的可售天数
  2. 低于安全线的，结合交期算出建议补货量
  3. 产出补货建议清单
人工确认：必须——补货是资金承诺

关键设计：补货量的计算逻辑要写在代码里，不要交给模型。模型负责的是“哪些 SKU 需要关注“和“有没有异常模式“，具体数字用公式算。让模型算补货量是本章最容易踩的坑——它会给你一个看起来合理但没有依据的数。

5.3 差评响应（黄灯，价值最高但最需要卡口）

触发：检测到新的 1-3 星 Review
数据源：Review API 或平台通知
动作：
  1. 分类：物流问题 / 质量问题 / 期望不符 / 恶意
  2. 生成回复草稿
  3. 判断是否需要升级人工处理
人工确认：必须——回复一旦发出不可撤回

关键设计：草稿里绝对不能出现具体的退款金额、补偿承诺、时效保证。这些必须由你填。Agent 的价值是把 30 分钟的分类和起草压到 3 分钟的审核，不是替你做承诺。

三个 Agent 的技术实现见 B4 Agent 工作流，MCP 连接方式见 B6 MCP 集成。本章只讲运营侧该怎么划边界。

6. 常见陷阱

6.1 数据源没解决就开始搭 Agent

最常见也最浪费时间的一个。数据还是要人工导出，那 Agent 只是把“粘贴到 ChatGPT“换成了“粘贴到 Agent“，一分钟没省。先做 §2 的盘点表。

6.2 让模型算本该用公式算的数

补货量、利润率、盈亏平衡点、ACOS——这些都有确定的公式。交给模型算，你得到的是一个看起来合理、但无法复现也无法追溯的数字。规则是：能用公式算的用公式，模型只负责判断和分类。

6.3 把黄灯当绿灯

尤其是客服回复和 Listing 修改。这两项被自动化的诱惑最大（重复、耗时），但也最容易出不可逆的事。判断标准不是“AI 做得好不好“，而是“做错了能不能撤回“。

6.4 没有留下审计痕迹

Agent 改了什么、什么时候改的、依据哪条数据——不记录的话，出问题时你既无法复盘也无法向平台申诉。每个写操作都要留日志，这是 Agent 化的最低门槛，不是可选项。

6.5 一次全上

同时把五个环节 Agent 化，出问题时你分不清是哪个环节的问题。一次上一个，跑稳两周再上下一个。

什么时候这套不管用

• 数据源是 C 类。 这一章开头的数据源分级不是形式。没有 API、没有稳定导出的数据源上做 Agent 化，你会花大部分时间维护抓取而不是做运营。C 类数据源的正确顺序是先解决取数，再谈自动化。
• 任务在红区。 不可逆的动作（发钱、改价、对外承诺、删数据）不该交给 Agent 自动执行，无论准确率多高。红区任务的正确形态是 Agent 提建议、人点确认。这条不是保守，是因为出错的成本和出错的概率无关。
• 省下的时间少于维护成本。 一个 Agent 要接数据源、写工具、处理异常、定期跟平台 API 变更。如果它替代的动作一周只花你二十分钟，这笔账算不过来。用这一章的任务分流表先量清楚每个动作的实际耗时，再决定动哪个。
• 团队还不会读 Agent 的执行日志。 Agent 出错时是静默的——它会拿着错数据自信地走完全程。没有人会看轨迹、没有异常告警的情况下，Agent 化只是把人工错误换成了看不见的自动化错误。上线之前先建立“怎么知道它错了“的机制。

7. 完成标志

• 完成 §2 的数据源盘点表，明确了哪些环节是 A/B/C 类
• 按 §3 把你的运营动作分成绿灯/黄灯/红灯三档，并写成清单
• 至少把一个现有 Prompt 按 §4 的五步迁成技能文件
• 搭出日报 Agent（绿灯）并稳定运行一周
• 为所有黄灯动作配置了人工确认环节
• 所有写操作都有审计日志
• 能说清楚：你的 Agent 化到底省掉了哪几步搬运，以及哪一步判断被你刻意保留了