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 是可插拔的上层应用。两者独立演进。

@bwnjnOEI 补充一下认证机制的区别：

OpenCLI 不提取 cookie ，它直接复用你 Chrome 的登录态 — 装一个 Chrome Extension + micro-daemon ，CLI 通过 WebSocket → Extension → Chrome API 在已登录页面里执行 JS 。Chrome 必须一直开着。

SigCLI 只在 login 时打开浏览器一次，提取 cookie 后加密存本地，之后不依赖浏览器。可以离线跑、可以 sync 到远程机器。


@gbin markdown 格式有点问题.

@bwnjnOEI 核心区别在实现路径：

**OpenCLI** 是 browser-use 路线 — 启动一个浏览器实例，让 Agent 通过 DOM 操作完成任务（点击、填表、截图识别）。优点是通用性强，缺点是慢、费 token 、不稳定（ UI 变了就挂）。

**SigCLI** 是 API 路线 — 只用浏览器做一件事：登录拿 cookie 。拿到之后直接调网站的后端 API （ REST/JSON ），不走 UI 。快很多，token 消耗低，也更稳定（ API 比 UI 稳定得多）。

具体对比：

| | OpenCLI | SigCLI |
|---|---|---|
| 交互方式 | 操作浏览器 DOM | 直接调 API |
| 速度 | 慢（渲染+截图+识别） | 快（ HTTP 请求） |
| Token 消耗 | 高（截图+多轮对话） | 低（ JSON 进出） |
| 稳定性 | UI 变动容易挂 | API 相对稳定 |
| 通用性 | 理论上任何网站 | 需要逆向 API |
| 认证 | 浏览器内操作 | 提取 cookie 加密存储 |

适用场景不一样：OpenCLI 适合没有 API 的纯 UI 操作（比如填个表单）； SigCLI 适合有 API 的重复性操作（查 ticket 、发消息、搜索等）。大部分工作场景的网站都有 REST API ，走 API 效率高很多。

@383394544 为什么会被称作“水军”，SigCLI 的初衷是打通企业应用与 Agent 之间的隔阂，不过恰好支持所有系统。

@Tink 目前不支持，不过很容易支持

@lrn100 fyi

@lrn100 新：X (Twitter) Skill 现在可以正常搜索和发推了！

更新：X (Twitter) Skill 现在可以正常搜索和发推了！刚用它搜了 "Agent Authentication" 相关推文，发现 FIDO 联盟刚成立了 Agentic Authentication Technical Working Group ，专门做 AI Agent 认证标准化。这个方向和 sig 做的事情很相关，感兴趣的可以关注一下。

@zisen 对，Confluence 用 personal token 确实是最省心的方案，不用担心 cookie 过期。新版 sig 配置也更简单了，extract/apply 声明式写法，不用再手动配 requiredCookies 那些了。如果后面有别的系统需要接可以再看看。

@zisen 有可能是配置了 ttl, 你是什么平台？可以给我看看 provider 的配置吗？ ~/.sig/config.yaml

不错，自己写 ReAct 循环比直接套框架学到的多。MCP 这块你是怎么处理 auth 的？比如用户要接入自己的 GitHub 或者数据库，token 管理是在前端还是后端做的？