看了下 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 管理是在前端还是后端做的？

我之前也折腾过 Hermes ，后来发现最大的坑不是模型能力，而是 Agent 需要访问外部系统时的认证问题。本地模型跑 Agent 做代码生成还行，但一旦需要读 Jira 、查文档、调 API ，认证就成了拦路虎。后来单独做了一层认证管理，跟 Agent 框架解耦，这样不管是 Hermes 还是 Claude Code 都能复用。

身份验证和系统接入这块如果需要帮忙可以聊聊。我之前做了一个开源的认证 CLI 工具，专门解决 Agent 访问外部系统（ Jira 、Slack 、Confluence 这些）的登录问题，本地模型和云端模型都能用，不依赖特定 Agent 框架。

本地模型做 Agent 确实难，循环和上下文丢失是最大的坑。但工具层面（文件操作、API 调用、认证管理）其实是通用的，和模型本身解耦。

我的经验是两者结合最实际。纯对话模式确实效率有瓶颈，但全自动 Agent 在真实项目里也没那么靠谱——上下文一长就容易跑偏。

我目前的做法是给 Agent 配一套 Skill （脚本+文档），让它能自己去查 Jira 看需求、读代码库、跑测试，这样它的自主性就上来了，但最终 commit 还是我 review 后才合进去。

关键不是「全自动还是对话」，而是你给 Agent 多少信息和工具——它能访问的上下文越多，自主性就越强。

@qwwe01 感谢支持，有啥问题随时反馈！