AI全自动操作浏览器实测：刷Hugging Face读论文发X

最近挖到一个值得深挖的开源项目——LocoAgent，定位为AI驱动的社交媒体智能体。它通过真实浏览器自动执行操作，在X、LinkedIn等平台上完成点赞、回复、关注、发帖，基本覆盖所有网页端交互场景。

仔细研究下来，技术实现相当扎实。如果只把它看成自动发推工具，会错失背后的设计意图。更值得关注的是「本地Agent + 轻量模型 + 浏览器操作 + 工作流」这套架构——将源码克隆下来细读，本身就是一份高质量的学习资料。

项目地址

github⋅com/LocoreMind/locoagent

项目作者马诗剑，之前介绍过他那个能自主完成数据分析任务的9B小模型（基于Qwen3.5微调，消费级显卡即可运行）。马诗剑是LocoreMind创始人，背景横跨多学科：从都柏林大学市场营销起步，到昆士兰大学信息技术，再到澳门大学数据科学硕士，还在UCL机器人感知与学习实验室做过访问研究。

按照项目README跑了一遍流程：拉取项目、配置模型、抓取Hugging Face Daily Papers、筛选论文、阅读摘要、发布到X，还能自动回复。安装配置完成后，用一句话就能触发这个流程，确实便利。

完成安装与配置后，只需一条指令即可启动整个流水线，体验相当顺畅

简介

LocoAgent的核心思路清晰明确：不依赖平台API，不接入黑盒接口，而是让Agent真正打开浏览器，通过真实Chrome会话查看网页、点击按钮、输入内容。这一点至关重要——因为X、LinkedIn等平台对API调用、无头浏览器、异常登录都极其敏感，许多自动化方案在第一步就被封堵。

LocoAgent选择的技术路径是：让浏览器模拟真人操作，Agent在上层负责判断与决策。README将其定义为AI-powered social media agent，支持真实浏览器会话、平台技能、工作流引擎、操作日志、多模型供应商。从更宏观的视角看，它试图构建一个可扩展的社交媒体操作系统。

核心能力可拆解为四个模块：

• 真实浏览器操作：通过Chrome远程调试端口连接已有登录态，理论上可复用真实账号会话。
• 平台技能系统：例如/x-com这类技能，将平台操作手册注入Agent，使其知道如何浏览、点赞、回复、发帖。
• 工作流引擎：如hf-daily-papers、hf-papers-to-x等固定流程，不依靠模型自由发挥，而是按脚本稳定执行。
• 操作日志：记录已执行的动作，避免重复点赞、重复发布同一篇论文。

社交媒体自动化最怕两件事：一是模型失控乱操作，二是平台风控拦截。LocoAgent的设计至少在第一个问题上做了收敛——能固定的流程就固定下来，让Agent只负责监督与决策。

工作流

LocoAgent里最值得关注的不是聊天入口，而是工作流（workflow）。

运行bun run workflow list，本地识别出4个工作流：

x-search-reply
hf-daily-papers
hf-papers-to-x
linkedin-search-reply

这些工作流的分工十分明确：

• hf-daily-papers：打开Hugging Face Daily Papers，抓取论文标题、链接、摘要和缩略图。
• hf-papers-to-x：获取论文后，下载缩略图，再发布到X。
• x-search-reply：在X上搜索关键词，读取帖子，用模型生成回复。
• linkedin-search-reply：同样的逻辑，替换为LinkedIn。

这正是它具备潜力的地方——你可以将其视为「内容运营SOP的代码化」。以前需要人工每天打开Hugging Face、挑选论文、阅读摘要、撰写推文；现在工作流每天自动运行一遍，只要浏览器登录态和页面结构不变，就能把整个环节串联起来。

自定义工作流

仔细翻阅了hf-daily-papers的定义后，完全可以自行修改或创建新Workflow——直接编辑项目workflow目录下对应的.json和.ts文件即可。

任何依赖浏览器操作的重复性工作，都可以通过workflow实现。这为内容自动化提供了一个高度灵活的框架。

安装、配置、实测

项目克隆完成后，安装依赖：

bun install

配置方面，使用OpenAI兼容接口时需要开启兼容模式。在项目根目录新建.env文件：

CLAUDE_CODE_USE_OPENAI=1
OPENAI_API_KEY=你的key
OPENAI_BASE_URL=你的OpenAI兼容地址
OPENAI_MODEL=你的模型名
SKIP_PERMISSIONS=1
# 这里用的是火山Ark的OpenAI兼容配置

再安装浏览器控制工具：

npm install -g agent-browser
agent-browser --version

接着启动Chrome远程调试：

bun run setup-chrome

脚本会复制Chrome profile，启动9222端口，然后让agent-browser连接该端口。成功时会出现：

Chrome CDP ready
agent-browser is ready

启动Chrome远程调试后，运行hf-daily-papers。第一次使用默认配置，工作流打开了Hugging Face，但由于默认要求论文至少5个upvote，脚本未选出任何论文。返回结果为partial，详细信息如下：

{"stepsCompleted": 1,"stepsTotal": 3,"papers": [],"steps": [{ "step": "fetch_list", "status": "success", "detail": "0 papers selected" },{ "step": "fetch_abstracts", "status": "skipped" },{ "step": "download_thumbnails", "status": "skipped" }]}

程序并未崩溃，只是默认筛选条件过于严格。将门槛降到0再次运行，同一执行器成功抓取到15篇论文，并逐篇打开详情页补充摘要。这一步没有修改默认工作流文件，而是直接调用executor临时传入一份配置：

bun run workflows/executors/hf-daily-papers.ts --config '{"maxPapers":15, "minUpvotes":0 ...}'

这次返回：

Found 15 papers, selected 15
15 abstracts fetched
Data sa ved to workflows/.tmp/hf-2026-05-28/papers.json

需要区分清楚：默认Workflow未被改动，此处仅为演示而临时放宽了执行器参数，生成的数据文件保存到了本地.tmp目录。

最后是发布到X的环节，设计得相当精细——为了迎合X的推荐算法，还将链接自动回复到了评论区。

总结

重申一遍，如果只拿LocoAgent做自动发推，确实有些大材小用。如果你正在研究本地Agent、浏览器自动化，或者想把自己的日常信息流转化为自动化工作流，这个项目值得克隆下来仔细阅读源码。你可以从中学到：真实浏览器如何接入、平台技能如何组织、工作流如何拆分、日志如何记录、模型如何嵌入流程。