一种通用的 AI Native 应用工作流：把确定性交给代码，把创造性交给 Agent

最近我做了几个完全不同方向的 AI Skill，但是我发现：它们表面上千差万别，底层却很像——都能抽象成同一套初始化 → 反馈 → 更新的循环。

如果你也在做 AI Native 应用（尤其是 Skill / Agent 类产品），这套工作流也许对你也有一些启发。

非 AI 的总结

结论一：通用工作流可以抽象成：建档（初始化）→ 更新（反馈）→ 输出（交付）。
结论二：别把一切都丢给 AI：确定性的部分（取数、校验、落库）交给代码，创造性的部分（策略生成、总结、创作）交给 Agent。
结论三：这不是“更保守”，而是更工程化：可用性更高、成本更稳定、token 更省。

下面把这套东西讲清楚。

1. 先把组件拆出来：四件套

我习惯把 AI Native 应用拆成四个基础组件（名字不重要，职责重要）：

数据获取器（Data Fetcher）：
- 普通脚本代码
- 负责从外部系统/API 拉取最新数据
- 关键要求：稳定、可观测、可重试
基础信息档案（Profile）：
- 用户相对稳定的“底座信息”
- 例如：年龄、目标、行业、定位、偏好、约束等
策略文件（Strategy）：
- 可迭代的“行动方案/规则集合”
- 例如：训练计划、运营策略、投放节奏、选题库
Skill 文件（Harness / Spec）：
- 你可以把它理解为 Harness engineering 的一部分
- 负责定义：
  - 工具怎么用（比如 MCP / API 调用方式）
  - 策略如何生成与更新
  - 输出格式与质量要求
  - 评估方法（怎么判断好/坏）

这四件套组合起来，就能跑出一个非常通用的“闭环”。

2. 三个典型场景：建档 / 更新 / 输出

2.1 建档（初始化）

用户第一次使用时，系统需要做的不是“立刻给答案”，而是先建立长期可用的上下文：

用户回答一份问卷（或半结构化访谈）
Agent 根据回答生成：
- 第一版 Profile（基础信息档案）
- 第一版 Strategy（策略文件）

这一步的关键不是“问得多”，而是：把未来更新所需的变量问出来。

2.2 更新（反馈驱动的策略迭代）

更新阶段的输入一般来自两类：

最新数据：由数据获取器拉取
历史策略与执行结果：由策略文件与（可选的）执行记录提供

Agent 的任务是：

读取最新数据
对比上一周期策略与目标
评估执行情况（偏差、瓶颈、异常）
产出新一版策略（增量调整，而不是推倒重来）

一句话：用数据给策略“打脸”，再让策略学会“改口”。

2.3 输出（按需交付）

输出阶段是面向用户的：

用户提出当下需求（比如“给我本周计划”“复盘下哪里没做好”“帮我写三条短视频脚本”）
Agent 按照 Skill 规定的输出要求，把 Profile + 最新 Strategy 转换成可交付结果

这里 Skill 的价值会非常明显：它像产品的“交付规格书”，让输出稳定、可预测。

3. 为什么数据获取器要用代码，而不是让 Agent 去“自己上网看”？

因为数据获取这件事，天然属于确定性工作：

你需要稳定性（今天能拉到，明天也能拉到）
你需要可观测性（失败了要知道为什么失败）
你需要重试/限流/登录态管理
你需要合规边界（权限、速率、数据范围）

让 Agent 直接“自由浏览”当然也能做，但成本一般会变成：

token 换不来确定性
失败还难以复盘
一旦遇到 UI/状态机/登录态，你会在对话里描述 UI，AI 在 token 里猜 UI（熟悉的痛又来了）

所以我的偏好是：

数据获取交给脚本，其余能力（策略生成、总结、创作、评估）交给 Agent。

这是在“可用性”和“灵活性”之间取一个工程化的平衡点。

4. 两个例子：同一套工作流，不同的皮肤

4.1 AI 运动教练：用数据更新训练策略

在运动教练这个场景里：

数据获取器：从佳明（Garmin）网站获取运动数据的脚本Garmin-Give-My-Data
- 以 MCP 工具形式暴露给 Agent（Agent 负责调用，脚本负责稳定取数）
Profile：用户年龄、运动目标、训练史、偏好与限制等
Strategy：训练计划（例如一周训练安排、强度分配、恢复建议）
Skill：
- MCP 的调用方式
- 训练计划生成规则：长期计划+短期计划结合的两层更新策略
- 训练效果评估方法（例如完成率、强度达标、疲劳迹象）

一个典型的“更新 + 输出”流程是：

Agent 通过 MCP 拉取本周最新训练数据
对比上周训练计划与实际执行
评估执行情况（完成率、偏差原因、疲劳/恢复）
结合 Profile 调整并生成下一周训练计划

你会发现：这里 Agent 的“聪明”并不是凭空的，它是被数据喂出来、被策略约束出来的。

4.2 新媒体运营助手：用经营数据更新运营策略

换到新媒体运营场景：

数据获取器：通过 API 从小红书、抖音等创作者中心获取
- 粉丝数、播放量、互动率、完播率、涨粉来源等
Profile：账号定位、行业、受众画像、创作目标、资源约束（时间/预算/团队）
Strategy：运营策略
- 选题方向、内容结构、发布频率、标题/封面策略、AB 测试节奏
Skill：运营的基础要求与技巧
- 复盘框架
- 指标解读口径
- 策略更新的优先级规则

用户使用过程大致是：

Agent 拉取运营数据
按 Skill 复盘策略与结果（哪些有效、哪些没用、哪些是噪声）
结合 Profile，生成新一个周期的运营策略

同一套“初始化—反馈—更新”，只是：

运动教练的反馈是训练数据
运营助手的反馈是经营指标

皮肤不同，骨架相同。

5. 这个抽象为什么“有拓展性”？

因为它天然支持外挂：

新媒体运营助手可以外接自己的知识库/数据库
- 存放历史爆款拆解、竞品案例、个人表达风格、禁用词库
也可以把策略反哺到创作流程
- 用运营策略生成选题池
- 再由 Agent 直接产出脚本/标题/封面文案

当 Profile 与 Strategy 变成“可读可写的资产”，你就不再是每次都从一个聊天框重新开始。

6. 回到本质：初始化—反馈—更新

这套架构其实就是一个很朴素的循环：

初始化（建立上下文）→ 反馈（获取数据）→ 更新（迭代策略）→ 输出（按需交付）

相较于“全部交给 AI”的工作方式，它更像一种工程妥协，但这种妥协很值：

把确定性的东西交给代码（数据获取、校验、落库、可观测性）
把创造性的东西交给 Agent（策略生成、解释、总结、创作）

结果通常是：

系统下限更高（更不容易翻车）
token 消耗更可控（少做无谓的猜测与重复对话）
迭代更像“产品”，而不是“玄学调参”

最后留一句不严谨但很实用的话：

与其让 AI 无所不能，不如让它在你搭好的轨道上稳定地跑。

一种通用的AI Native应用工作流