很多工具接入大模型以后，只是把原来的按钮换成了聊天入口：用户说一句话，Agent 再替用户点几个按钮。这当然有价值，但还不是 AI 原生工具。

更值得关注的是另一种形态：工具一开始就不是为人手动点击设计的，而是为 Agent 调用、观察、纠错和编排设计的。也就是现在常说的 Agentic Skill。

一句话定义：Agentic Skill是一段能被Agent理解和稳定调用的能力契约。它要告诉Agent自己能做什么、需要什么前置条件、当前执行到哪里、失败了怎么恢复、结果如何结构化返回。

yoko-collector是一个适合解释这个思路的例子。它做的事情很具体：在用户自己的浏览器里，围绕关键词搜索抖音公开账号结果，提取账号公开资料中可见的微信号、电话等线索，并把结果交给Agent客户端继续处理。

它不是一个完整的私域运营机器人，它是Yoko生态里的一个"线索采集技能"：负责把公域公开线索变成Agent可读取、可停止、可导出的结构化结果。

为什么普通插件不等于Agentic Skill

传统浏览器插件通常面向人设计。用户打开面板、输入关键词、点开始、等进度条、最后导出文件。这个流程对人是清楚的，但对Agent并不友好。

Agent真正需要的是一组可判断的状态：

问题	普通插件常见做法	Agentic Skill应该提供什么
当前环境能不能执行	用户自己看页面	checkEnvironment 返回是否在抖音、是否登录、是否可执行
怎么开始任务	点按钮	collect.start 接收关键词、模式、滚动上限等结构化参数
任务是否还在跑	看进度条	collect.status 返回 jobId、状态、进度、线索数、当前关键词
失败了怎么办	弹窗报错	返回结构化错误码和修复建议
能不能中断	用户手点停止	collect.stop 可被Agent或用户随时调用
结果怎么交付	导出 CSV	collect.getLeads 返回结构化线索，面板也保留 CSV 导出

普通插件在回答"用户怎么点"，Agentic Skill在回答"Agent 怎么可靠地完成一项工作"。

yoko-collector 的一个典型执行流程

假设用户在 YokoAgent 里说：

帮我在抖音找做微信机器人、私域运营相关的潜在客户联系方式。

一个 AI原生的采集技能不应该直接开始乱跑，而应该拆成几个阶段：

1. Agent先调用环境检查：浏览器是否安装扩展、是否打开抖音、是否已登录。
2. 如果未登录，Agent 不继续采集，而是提示用户在浏览器里完成登录，并轮询环境状态。
3. 登录状态满足后，Agent 调用采集任务，传入关键词列表和采集模式。
4. yoko-collector打开抖音用户搜索页，按关键词执行拟人滚动，采集公开账号资料。
5. 扩展持续上报jobId、当前关键词、滚动次数、线索数量和风险状态。
6. 如果检测到登录弹窗、验证、页面异常或相关性下降，任务停止或切换关键词。
7. Agent 获取结构化结果，再决定是否导出 CSV、筛选含联系方式的线索，或进入后续私域跟进流程。

这个流程里，人仍然保留控制权：登录发生在用户自己的浏览器里；任务可以停止；结果可以清空；采集范围限于公开可见信息。

Agentic设计的 3 个原则

1. 自描述：让 Agent 先知道你能做什么

AI 工具最容易犯的错，是把调用方式写死在某个客户端里。这样做短期能跑通，长期很难扩展。

yoko-collector把能力描述成明确的命令契约，例如：

命令	用途
describe	描述技能名称、能力、参数和返回结果
checkEnvironment	检查浏览器、抖音页面、登录状态和可执行条件
collect.start	按关键词启动采集任务
collect.status	查询任务状态和进度
collect.getLeads	获取本机已采集线索
collect.stop	停止当前任务

这样设计后，YoBot助理只是第一个调用方。未来其他Yoko产品或Agent也可以按同一套契约理解这个能力。

2. 长任务必须可观察

线索采集不是一次HTTP请求，而是一个长任务。长任务如果只有"开始"和"结束"，Agent就很难判断中间发生了什么。

yoko-collector为每次采集生成任务ID，并持续记录状态。面板中展示最近任务ID，Agent侧也能通过状态接口拿到任务进度。

这件事的价值不只是方便调试。它让后续能力可以继续扩展，比如：

• 按任务批次查看本次新增线索；
• 判断任务是正常完成、用户停止，还是风险中断；
• 把计费、试用次数、导出记录绑定到有效任务结果，而不是简单绑定到"点击开始"。

3. 结果要结构化，而不是只给一个文件

CSV对人很友好，但对Agent来说还不够。Agent更需要结构化字段，例如昵称、抖音号、简介、主页链接、微信号、电话、地区、认证信息等。

结构化结果的好处是，后续可以继续接工作流：

• 只保留含微信或电话的线索；
• 按关键词来源分组；
• 按蓝 V、地区、简介关键词做二次筛选；
• 交给 YokoBot 或 CRM 工具做后续人工跟进提醒；
• 生成一份"本次采集有效线索摘要"。

这也是yoko-collector和普通"导出表格插件"的差别。它不只把数据给人看，还要让Agent能继续处理。

放到Yoko生态里，它解决的是哪一段

Yoko生态更大的方向，不是把所有功能堆成一个巨大的软件，而是把不同能力做成 Agent 可调用的技能。

可以把链路粗略拆成三段：

阶段	典型问题	更适合的能力
公开线索发现	哪些账号可能是潜在客户？公开资料里有没有联系方式？	yoko-collector这类采集技能
私域承接	客户进微信后，怎么跟进、提醒、生成话术？	YokoBot这类微信私域 AI 助理
流程编排	什么时候采集、筛选、导出、提醒人工处理？	YoBot这类 Agent 客户端

yoko-collector解决的是上游"公开线索发现"。YokoBot更偏下游"已有私域关系的运营辅助"。

公开线索采集要强调公开信息、用户浏览器、人工复核；
私域运营要强调低频、可控、人工接管和客户关系维护。

和爬虫、RPA、SaaS 插件的区别

形态	优点	局限	更适合场景
传统爬虫	批量能力强，工程可控	容易遇到签名、登录、风控、合规边界	公开网页、规则稳定、授权明确的数据处理
通用 RPA	能模拟人操作多个软件	语义弱，流程维护成本高	固定办公流程、跨系统搬运
SaaS 插件	UI 完整，上手直接	往往为人点击设计，Agent 难以观察中间状态	人主导的工具使用
Agentic Skill	Agent 可调用、可观察、可恢复	设计成本更高，需要结构化契约	长任务、自动编排、多技能协作

yoko-collector更接近"浏览器扩展 + Agentic Skill"的组合。浏览器扩展负责在用户本机环境里执行采集，Agentic契约负责让Agent理解和编排任务。

这也解释了为什么它不应该只做一个插件面板。如果用户每一步都要自己判断，Agent 的价值就很弱；如果Agent不能知道登录、风控、进度、结果和停止原因，这个工具也很难进入复杂工作流。

给开发者的 Agentic Skill 检查清单

如果你也在做给AI agent调用的工具，可以用这8个问题自检：

1. Agent 能否通过 describe 知道技能能力、参数和返回值？
2. 技能能否在执行前检查环境和权限？
3. 不确定状态是否会诚实返回 unknown，而不是伪装成功？
4. 长任务是否有任务 ID、进度、状态和部分结果？
5. 用户是否可以随时停止任务？
6. 失败是否有错误码、原因和修复建议？
7. 结果是否是结构化数据，而不只是一个下载文件？
8. 这个技能能否被多个 Agent 或产品复用，而不是只服务一个页面按钮？

如果这些问题都有答案，工具才开始接近 AI 原生设计。

FAQ

Agentic Skill是什么？

Agentic Skill 是给AI Agent调用的能力模块。它不只是一个插件或API，而是包含自描述、环境检查、任务状态、结构化结果、错误恢复和停止机制的一套契约。

浏览器扩展可以做成Agentic Skill吗？

可以。浏览器扩展适合处理需要用户本地登录态、页面上下文和浏览器环境的任务。关键是不要只提供UI按钮，而要提供Agent可调用的命令，例如环境检查、启动任务、查询状态、停止任务和获取结果。

yoko-collector和普通抖音采集插件有什么区别？

普通插件主要服务人手动操作，yoko-collector的设计目标是服务Agent编排。它会把采集任务抽象成jobId、状态、进度、线索结果和错误码，让YoBot桌面AI Agent可以判断何时等待、何时提示登录、何时停止，以及如何处理采集结果。

yoko-collector和YokoBot是什么关系？

两者都属于YokoAI / Yoko生态里的能力，但位置不同。yoko-collector偏上游公开线索发现；YokoBot偏已有微信私域关系里的跟进、话术、提醒和人工接管。YoBot桌面AI助理则是把这些技能编排成一个更完整的工作流，包括上游获客 -> 私域跟进销售闭环。

Agentic Skill、MCP是一回事吗？

不是。MCP更偏工具上下文和调用协议，Agentic Skill强调面向 Agent 的完整能力设计。一个技能可以使用浏览器扩展、MCP暴露能力，但关键是它是否可描述、可观察、可恢复、可停止、可结构化返回结果。