本次阅读小组已满员，感谢关注。没来得及加入的小伙伴期待下次一起阅读～

第一份工作： 十个月
第二份工作：七年

厉害，来考古了

触发竞业协议 dog:)

支持写操作不，比如发帖，回帖这种操作。我以前有写过类似 skill, 我其实不太愿意做 cli ，只想想好 auth 那一层。
楼主可以考虑一下使用 cookie 方案，这样我的 V2EX skill 可以放弃维护现有的那些 script ，然后使用你的 cli
fyi https://v2ex.com/t/1208212?p=1#reply10

你们负责写 cli,我给你们提供 auth

@lovestudykid 我教程写简化了 让 AI 帮你配置一下 sig provide ，或者手动 copy 一下配置，配置在 https://github.com/sigcli/sigcli/blob/main/skills/xiaohongshu/references/provider-config.yaml

还要啥前端，未来 Agent 才是主要流量入口，各大系统提供 Agent 友好的集成方式即可

c3luY3ZpaXBAZ21haWwuY29t 谢谢老板大卖

c3luY3ZpaXBAZ21haWwuY29t 谢谢老板

c3luY3ZpaXBAZ21haWwuY29t
谢谢老板

claude 模型最近降智太严重了，堪比我老年痴呆的奶奶

@h4nru1 理论上都可以 API 画，MS Teams 本质上和微信一样，也可以全部 API 自动化 https://github.com/sigcli/sigcli/tree/main/skills/msteams

我认为未来浏览器不在被需要，AI Agent 就是用户流量入口，所有系统都必须支持 AI Agent 友好的接口

你这个和 https://github.com/Thysrael/Horizon 很像。我的思路不一样——不经第三方，直接在本地用浏览器 SSO 拿 cookie ，agent 调脚本时自动注入认证。好处是不限频（用的就是你自己的登录态），也不用担心第三方挂了或者数据过第三方。坏处是每个平台得写一套脚本。

目前做了 X 、Reddit 、Slack 、Teams 、Jira 、LinkedIn 、YouTube 、B 站、知乎、V2EX 这些，开源的，Claude Code / Codex / Cursor 都能用。你说的那些场景（ Twitter 搜用户评价、Reddit 找吐槽）我每天在用。

https://github.com/sigcli/sigcli/tree/main/skills

看了下 GenericAgent ，本质还是 computer use 那套，操控浏览器去点点点。

我自己试下来这条路走不通。拿 X 举例，用浏览器操控搜个推文，截屏+识别+点击+等渲染，一趟下来十几秒、几千 token 。我直接写了个 skill 调 X 的 GraphQL API ，200ms 回来结构化 JSON ，token 消耗大概是前者的 1/10 。

浏览器适合一次性的事情，高频操作还是得走 API 。代价就是每个平台要写一遍脚本，但写完就是纯收益。

@lozzow “如何”还是“如果”？

实际上我个人并不建议越过平台风控，如果平台有风控的话，我们就不建议直接操作他的 API 。我个人认为未来的趋势都是每个平台都需要提供 agent 友好的支持，否则这些平台终将会被淘汰。

方案 1 最省心。ssh 到 VPS 跑 CLI ，tmux 挂着就行。反代容易被风控，大模型那边查得严。本地只需要能 ssh 的终端就够了。

@bwnjnOEI 再补充一个架构上的区别：可扩展性。

OpenCLI 是一体的 — 认证和操作绑在一起，每个 CLI adapter 自己处理登录态。要加一个新网站就得写一个完整的 adapter 。

SigCLI 把认证和操作脚本解耦了。sig 只负责一件事：拿 cookie 、存 cookie 、注入 cookie 。操作脚本（ Skill ）是独立的，任何人都可以写自己的 Skill 来自动化任意网站，sig 不管你拿 cookie 去干嘛。

所以扩展一个新网站的成本：
- OpenCLI：写一个完整 adapter （含认证逻辑 + 操作逻辑 + 浏览器交互）
- SigCLI： 搞定认证，然后写几个 Python 脚本调 API 就行

相当于 sig 是通用认证层，Skill 是可插拔的上层应用。两者独立演进。