Agent-driven App & Skill as a Service

2026-03-05 · Junyi Yan

本文记录个人对 Skill as a Service 商业模式的思考和实践（节选）。

传统的 SaaS 正在消亡。仅在 2026 年 1 月中旬至 2 月中旬的一个月内，全球软件股的集体价值缩水了约 1 万亿美元。

什么是 AI Native 的产品形态和商业模式，本文以 Agent-driven App 和 Skill as a Service 的设想尝试回答这个问题（以 GEO Agent 为例）。

前言 1

最近这段时间对未来产品形态的思考（见GEO Agent的产品形态和架构设计初步思考），逐渐收敛到这个 sense：

未来产品的形态都是由一个强大的通用智能体驱动（类似 Claude Code/Codex/OpenClaw 之类） + 前端更像是一层展示层（直接把 Agent 的 json/md 成果文件结果展示出来），一个很合适的产品形态就是类似 Cursor/Zed 的三分栏：左栏是文件系统、中间是成果渲染展示/预览编辑、右栏是 Agent。

这跟我在早期的工具形态探索感受一脉相承：

这种“ Lead + Adapter + Generative UI ”的 Agent-driven App 形态将伴随产生一种新的 SaaS 模式：Skill as a Service。

btw：我们都相信以后 AI token 的套餐订阅也是每个人/每个企业的标配，就跟现在的手机套餐一样，各家基模供应商就是现在的运营商。

这个和上面的设想是需求一致的，我们的产品将离不开模型的智能。

用户购买了一个订阅（比如 ChatGPT Pro），他的 api 使用是跨 app 的（任何基于 codex 作为 Lead Agent 的产品里都能用）。

前言 2

其实下面这些问题也仍然贯穿始终。我用 FAQ 的形式进行梳理，希望能得到更进一步的答案：

Q：这不就是 codex/claude code 套壳吗？产品的价值点在哪？

回顾 Manus 时期，也不乏套壳（套模型壳）的说法，但后来它证明了 Agent 设计的价值。现在进入到了 Agent 时期，通用的 Agent 能力已经把大家的水位拉齐了，套壳（套 Agent 壳）的意义或许就是回归客户价值了，剩余的产品设计空间就是行业 know-how。

Q：Skill 的创建和复用门槛这么低，被逆向实现复制了怎么办？

我觉得在 AI 大幅提高个人/企业生产力的背景下，很多之前需要采购的产品/服务必然会被个人/企业借助 AI 来自己实现。参考按结果付费模式（result-as-a-survice）产生的背景。在以上趋势下，我认为有三层付费门槛：

  • Skill 构建门槛。的确可以被逆向复刻，但没那么简单，尤其是对非技术的业务运营人员来说。
  • 产品设计层门槛（这里主要是指 Adapter 层的设计）。假如客户公司技术人员帮助逆向复刻了 skill，对使用者来说在 CLI 里操作，在 IDE 里看成果，都不是友好交互体验。
  • 基于行业 know-how 的服务门槛。如果说前两点都能被复刻（这的确也不是难事），那这一层就是最后的门槛：工具层之上的业务认知。你必须比客户更懂如何在某一方面提升他们的业务，类似之前的咨询公司角色。

Q：以 Codex /Claude Code 为 Lead，不是大炮打蚊子吗？

首先我们肯定要站在巨人的肩膀上，用世界上最好的轮子，这是应用层的起跑线。我总不能退后起跑线一百米（用自己搭建的垃圾 Agent）再和你比吧？

其次是前面 btw 里的的判断：当Codex /Claude Code 成为用户日常订阅的时候，你的产品能帮他多花点 token 反而是好的。

最重要的，要的就是大炮打蚊子，要的就是杀鸡用牛刀，同样能实现目的的情况下，能力溢出并非坏事。这也启示我们在产品设计上要有承接这部分溢出能力的地方。拿 GEO Agent 举例，用户可以按我们设计好的 5 类 skill 完成一个 GEO 优化的闭环，但他也可以用 codex 自己分析自己感兴趣的指标，尝试自己好奇的内容构建方式，甚至 ui.json 支持他的这些自定义尝试，所见即所得，有一种 「这个产品是活的」 的感觉。

Q：为什么是 Skill？

我对 Skill 的理解有一个观点，skill 是什么？skill 是代码和模型的结合体。几乎所有 workflow agent 都可以做成一个 skill。

回到回答，为什么是 Skill，不是说不用 skill 就做不了，只是这种可插拔、自带渐进式加载的机制比较适合。当前的设计思路是 Lead - sub skill - MCP - main skill - MCP - sub skill -Generative UI 的路线。 如果说用 A2A，我觉得其实是一样的：产品本身还是 Agent-driven App，还是由 Lead + Adapter + Generative UI 组成，顶多把 skill-as-a-survice 变成 agent-as-a- service。

GEO Agent 为例：一次完整闭环运行链路

1. Lead 调用引导 skill（本地 Guide 类）

目标是需求澄清与任务结构化，而不是直接跑云端。输出两个关键产物：

  • TASK.md（你熟悉的那套任务描述与验收标准）
  • request 组装所需的结构化表单（例如 prompts 清单、平台列表、地区画像、证据要求、预算上限）

2. Lead 调用对应的本地副 skill 做“任务准备”

比如：把 prompts 整理成 promptset.jsonl、把竞对域名/关键词列表整理好、校验 schema、计算预计成本、生成 request.json 并落盘到 runs/<run_id>/request.json。这里仍然不触达云端，先把“输入”变成可审计文件。

3. Lead 通过 MCP 调用云端主 skill（Cloud Worker）

这里关键是 Lead 调用的是 MCP tool，不是“直接给云端发一句话”。MCP tool 的接口要稳定、可计费、可审计，建议至少包含：

  • submit_job(skill_name, request_path, budget, tenant) -> job_id/run_id
  • stream_events(job_id) -> 进度/阶段/中间产物索引
  • fetch_artifacts(job_id, target_dir) -> 拉取落盘
  • finalize(job_id, action=accept/reject, reason_code) -> 触发扣款/重跑/折扣 这些工具可以由“本地副 skill”提供给 Lead（它在内部去调用你的云端 API），这样 Lead 的世界里永远只有 MCP。

4. 云端返回结果后，本地副 skill 负责落盘与生成 ui.json，中间看板只读渲染

副 skill 把 raw/parsed/judge/report 全部写到 runs/<run_id>/，再生成 ui/ui.json 给中间面板渲染。中间面板不承担业务逻辑，最多提供“打开文件/复制路径/在浏览器打开链接”这类被动动作。

5. Lead 读取产物，给用户做“解释 + 下一步”，并决定进入内容生成或 retest

这就类似秘书角色：Lead 会根据 judge/actions 推荐下一步要不要生成内容包、要不要补采集、要不要改问题库，再通过 MCP 驱动下一轮。

Skill as a Service 模式设计

核心思想是：所有云端能力（主 Skill）都必须有一个对应的本地副 skill 作为“协议入口 + 产物落盘器 + UI 驱动器”，这样 Lead Agent 只需要调用本地 tool（可以通过 MCP），就能驱动云端执行并把结果变成可展示的文件。

整体结构：Skill Pair（主副配对）+ 统一 Envelope + 统一 Artifact Contract

1. Skill Pair 约定

  • 本地副 skill（Client Stub）：负责“需求澄清/表单化、schema 校验、打包输入、提交任务、订阅状态、下载产物、落盘、生成 ui.json”。不做重计算。
  • 云端主 skill（Core Worker）：负责“采集执行、解析抽取、评测与指标、生成内容、对比归因”。只认 schema，不关心 UI。

2. 统一请求/响应 Envelope（所有 skill 共用一层外壳）

统一产品的计费、审计、重放、缓存、回归测试等。字段最少包含：

  • tenant/org、project/workspace、run_id、skill_name、skill_version、schema_version
  • budget：token/时间/并发/证据包大小上限
  • context：platform/locale/geo/device_profile/account_profile（只存标签不存明文凭据）
  • inputs：本次 skill 的业务输入
  • artifacts：本次输入引用哪些本地文件（path + hash），云端输出要落哪些文件（path 约定）
  • callback：SSE/WebSocket 订阅地址或轮询策略

3. 统一 Artifact Contract（文件结构稳定，UI/Lead 都只读写这些）

每次 run 固定落在：runs/<run_id>/，里面至少有：

  • request.json（提交给云端的完整请求）
  • status.json（云端流式更新：阶段、进度、错误码、计费用量）
  • raw/（证据包：html、screenshot、har、dom、console log…）
  • parsed/（answer.md、sources.json、entities.json、quotes.json…）
  • judge/（observations.json、diagnosis.json、actions.json、metrics.json…）
  • report/（report.md + report.html）
  • ui/ui.json（中间看板渲染用的卡片 schema，引用上述文件）

以 GEO Agent 为例的五大闭环模块：每类都拆成“本地副 skill + 云端主 skill”，并给出推荐的细分技能 GEO Agent 的 skill 体系，我目前考虑有以下几类：

  • 问题库构建类：问题库构建有多种方式：人工构建和自动生成，或者结合的形式。 不管哪种方式的构建逻辑都是这两种：根据行业图谱、业务图谱、用户画像进行问题库构建，以及根据搜索引擎关键词测试分析/包括竞对分析等结果进行构建。
  • 测试采集类：不同平台的采集 skill。
  • 数据分析类：有一套持续迭代的分析框架，分析结果附带内容生成指导。
  • 内容生成类：根据内容生成指导构建可直接替换或新增的内容。
  • retest类：根据相同批次的内容投放之后先调用测试采集类 skill 进行重新测试，调用数据分析类 skill 进行指标计算，然后进行对比分析。

这5个可以当作一个GEO服务的最小闭环。当然还可以拓展，比如竞对分析之类的。

具体可扩展性的 skill 列表设计（括号里是建议的 skill id 命名风格）

问题库构建类

  • 目标：把“行业图谱/业务图谱/用户画像/关键词与竞对信号”变成可测的 PromptSet（带变体、覆盖、验收口径）。

  • 本地副 skill：

    • 问题库向导与需求澄清（geo.qbank.wizard.local）：收集行业、产品线、地区语言、平台、竞对、种子问题/关键词、风险约束；输出 request.json + seeds.json。
    • 问题库管理与版本化（geo.qbank.pack.local）：把云端结果落盘成 question_bank.jsonl、prompt_variants.jsonl，并维护 pack 元数据（版本、覆盖率、来源）。

  • 云端主 skill：

    • 图谱驱动生成（geo.qbank.generate.cloud）：行业/业务/人群 -> 问题树（intent taxonomy）。
    • 关键词/竞对驱动扩展（geo.qbank.expand.cloud）：SERP/竞对内容/广告词 -> 问题候选。
    • 聚类去重与覆盖打分（geo.qbank.cluster.cloud）：按 intent、漏斗、场景去重并算 coverage。
    • 变体策略生成（geo.qbank.variants.cloud）：同一问题生成不同表达、不同约束版本（用于稳定性测试）。

  • 输出核心文件：question_bank.jsonl（含 tags/intent/persona/funnel）、coverage_report.json。

测试采集类

  • 目标：对不同平台做可复现采集，并沉淀证据包与结构化抽取结果。

  • 本地副 skill：

    • 采集任务提交（geo.collect.submit.local）：把 PromptSet + platform/locale/profile 打包发云端，生成 run_id，落 request/status 初始文件。
    • 采集状态订阅与落盘（geo.collect.watch.local）：订阅云端进度，把分段产物写入 raw/parsed/。
    • 批量编排（geo.collect.batch.local）：按批次/并发/预算控制拆分多个 run（按平台适配器拆分，计费也更清晰）。

  • 云端主 skill：

    • 平台采集执行器（geo.collect.runner..cloud）：AIO/Perplexity/ChatGPT/Gemini…
    • 抽取器（geo.collect.extract.cloud）：从 DOM/HAR/截图抽取 answer、sources、引用片段位置、结构。
    • 证据打包（geo.collect.evidence.cloud）：生成可审计证据清单与哈希。

  • 输出核心文件：raw/ 下全量证据；parsed/ 下 answer.md、sources.json、citations.json、answer_structure.json。

数据分析类

  • 目标：把采集结果变成“可解释的诊断 + 指标 + 可执行的内容指导”。

  • 本地副 skill：

    • 分析任务提交（geo.analyze.submit.local）：选择 run_id 或批次，选择分析框架版本与口径。
    • 分析结果落盘与看板更新（geo.analyze.watch.local）：写 judge/ 与 report/，更新 ui.json。

  • 云端主 skill：

    • 观察层抽取（geo.analyze.observe.cloud）：只记录事实（是否提及、是否引用、引用哪些域名、位置、语气、风险等）。
    • 诊断层归因（geo.analyze.diagnose.cloud）：为什么没达成目标（缺证据、缺结构、缺权威源、冲突等）。
    • 指标计算（geo.analyze.metrics.cloud）：SOV/SoR/SoC/Position/Consistency/Volatility…（你已有体系就固化）。
    • 内容生成指导（geo.analyze.guidance.cloud）：输出可直接驱动生成模块的 guidance（结构、证据、实体、段落建议）。

  • 输出核心文件：observations.json、diagnosis.json、metrics.json、content_guidance.yaml、report.md/html。

内容生成类

  • 目标：根据 guidance 产出“可投放、可替换、可合并”的内容包，而不是一段散文。

  • 本地副 skill：

    • 生成任务提交（geo.content.submit.local）：选择 guidance + 目标站点/页面/内容类型/风格约束。
    • 补丁落盘与预览（geo.content.apply.local）：把云端产物落到 patches/ 或 content_pack/，并生成 preview.html（中间看板只展示）。

  • 云端主 skill：

    • 内容包生成（geo.content.pack.cloud）：FAQ、落地页段落、对比表、术语解释、案例、结构化数据 JSON-LD、引用建议等。
    • 替换/新增策略（geo.content.plan.cloud）：告诉你替换哪里、新增哪里、如何内部链接、如何对齐实体/证据。
    • 站内资产改造（可选扩展，走 connector）（geo.content.cms.cloud / geo.content.pr.cloud）：输出 PR patch 或 CMS payload。

  • 输出核心文件：content_pack/（分类型文件）、patches/（可合并补丁）、rollout_plan.md。

复测类

  • 目标：同批次、同口径复测 -> 自动对比 -> 归因解释 -> 给出下一轮动作。

  • 本地副 skill：

    • 复测发起（geo.retest.submit.local）：指定 baseline_run_ids + content_deploy_id + 相同测试配置锁定（重要！）。
    • 对比看板更新（geo.retest.watch.local）：落 delta_report 与 compare_metrics。

  • 云端主 skill：

    • 复采集（geo.retest.collect.cloud）：复用原配置重新跑采集（或抽样）。
    • 复分析与对比（geo.retest.compare.cloud）：指标差异、引用源变化、结构变化、归因解释（哪些改动可能带来提升）。

  • 输出核心文件：compare_metrics.json、delta_report.md/html、attribution.json、next_actions.md。

跨模块的“平台能力层”：Skill as a Service 收费模式

真正可持续收费的部分在云端主 skill，并且对用户表现为“按 skill 服务的结果收费”，即 Result-as-a-Service。

  1. Platform Adapter Registry（平台适配器注册表）
  • 每个平台 runner 都有版本号、能力矩阵（是否支持 sources 展开、是否支持多轮、是否能拿到 citations 定位等）
  • 客户买的是“平台覆盖 + SLA + 更新频率”，不是买代码
  1. Profile & Panel（地区/设备/账号画像与面板网络）
  • 支持 geo、locale、device、account_profile 的组合，形成可对比的 panel 数据
  • 这是用户自己很难搭的，因此天然是订阅点
  1. Caching & Reproducibility（复现与缓存）
  • 同 prompt/同配置的结果可复用（降低成本），但必须在 status.json 里写清楚是 cache 命中还是 fresh run
  • 每个 run 产物都有 hash 与证据清单，方便审计与复跑
  1. Metering（计费与配额）
  • 计费维度映射到云端主 skill：采集次数/平台数/地区数/并发/证据包大小/分析次数/报告次数/内容包次数
  • 本地副 skill 负责把用量落到 status.json，UI 负责展示，不让 Lead 关心计费细节

Lead 如何编排这些 skills

总体来说，以 Agent-driven App 的形态设计，GEO Agent 左侧文件树永远是事实来源，中间看板只读这些产物，右侧 agent 负责下一步决策与发起。

  • Lead 调用本地 tool 进行云端服务调用，是通过 MCP 实现的，我认为 Lead 的工作，是先调用一个独立的引导 skill，引导用户的需求澄清（比如说要整理 prompts），然后会调用对应的本地副 skill 进行辅助任务准备，准备好原始数据等内容后，通过 MCP 调用云端对应的主 skill，然后通过 MCP 返回结果，给副 skill 进行渲染展现。全程 Lead 都是参与的，是一个秘书/任务助手的角色，帮助用户跑完整个任务。
  • 本地副 skill 作为统一入口，把“开始采集/开始分析/开始复测”变成一个标准 API 调用，并把结果写回 runs/。
  • 可以把中间看板的卡片固定成 10 个以内的类型（Run 状态、指标表、来源域名榜、引用片段、差异对比、建议清单、内容包预览、失败诊断等），服务端只负责吐 ui/ui.json 来配置这些卡片的数据源与布局。这样既“生成式”，又“可控、可维护、可审计”。
#人工智能#认知思考
https://junyiyan.xyz/posts/feed.xml