青蛙小白

Claude in Chrome vs Codex Chrome:MCP 工具层 vs Node REPL 的两种路线

两家公司给自己的 AI Agent 分别推出了 Chrome 扩展。表面上都是"让 AI 能操作浏览器",但出发点几乎相反:Claude in Chrome 是把 AI 嵌进浏览器里,Codex Chrome 扩展是把浏览器接进 AI 任务系统里。 产品定位 Claude in Chrome 是 claude.ai 的浏览器扩展,主要形态是侧边栏。浏览时 Claude 在旁边响应,可以读当前页面、执行操作、或者后台跑多步骤工作流。也对接了 Claude Desktop,可以在桌面端控制浏览器。

#Codex #Openai

Codex Security Plugin: 把安全扫描嵌进 Codex 工作流

Codex Security Plugin不是一个独立的安全工具,而是以插件形式嵌入到 Codex 工作流中的漏洞扫描系统。这篇文章整理一下它的工作原理、扫描流程和 CI/CD 集成方案,也对比一下它和传统静态分析工具的思路差异。 背景:为什么是插件而不是独立工具 传统的代码安全扫描(SAST)工具,比如 Semgrep、CodeQL、SonarQube,走的是规则匹配的路子:维护一套漏洞特征规则库,扫描代码时对模式进行匹配,找出潜在问题。这类工具的优点是确定性强、速度快、可以自动化集成。缺点也很明显——规则库覆盖不到的变种绕过不了,误报率偏高,而且几乎没有对业务逻辑的理解能力。

Claude Code Artifacts:把 Agent 的工作过程变成活文档

Claude Code 现在支持 Artifacts —— 一句话版:你让 Claude Code 干活时,它可以把过程和结果生成一个可交互的网页,分享给团队看,而且会随着 Claude Code 继续工作自动更新。 Artifact 是什么 以前 Claude Code 的工作成果散在终端输出和对话里。查完 bug、读完代码、推理出根因之后,要把这些东西传递给其他人,只能截图、复制粘贴、或者口头转述。Claude Code 的 Artifacts 把这些工作打包成一个可访问的网页。

#Codex #Openai

Codex 远程连接:两套方案,两种边界

Codex 的远程连接不是一个功能,而是两套相互独立的方案,分别服务于 Desktop App 和 CLI,适用场景和限制也完全不同。 两套方案概览 主机端 客户端 传输协议 Remote Connections Codex Desktop App ChatGPT 手机 App 专有协议 Remote TUI Codex CLI(app-server) 另一台机器的 Codex CLI WebSocket 两者之间没有交集:手机 App 只能连 Desktop App,另一台 CLI 只能连 CLI 的 app-server,不能混用。

#Claude Code

Claude Code Remote Control:用手机或浏览器接管本地会话

Claude Code 2.1.51 之后加了一个叫 Remote Control 的功能,允许在 claude.ai/code 或 Claude 手机 App 上远程操控本地正在运行的会话。Mac 上用起来基本开箱即用,但在 Linux 上配置的过程里遇到了一个不太直观的坑,记录下来。 Remote Control 是什么 和 Claude Code on the web(在 Anthropic 云端跑)不同,Remote Control 的会话始终运行在本地机器上,远程界面只是一个窗口。这意味着:

Claude Code 的三种驱动机制:goal、loop、workflows

默认状态下,Claude Code 在完成一个任务后就停下来等待 —— 即每轮结束后,将控制权还给我们,由我们决定下一步。这种交互方式对大多数任务足够,但某些工作需要 Claude 跨越多轮自主运行:修复一批测试直到全部通过、定期检查部署状态、对整个代码库做并行扫描。这时候需要的不是更多的手动催促,而是一套合适的驱动机制。

git worktree:同时在多个分支上工作

AI 编程工具改变了写代码的节奏。以前一个人同时只能推进一条线,现在用 Claude Code 或者其他 AI agent 可以很自然地并发:一个任务交给 agent 跑着,自己再开一个 session 做另一件事。问题随之而来——两个任务如果在同一个工作目录里,文件系统是共享的,两个 agent 会互相踩脚。 这不是 AI 工具的问题,是 git 工作目录没有为"并发"设计。git worktree 才是。

#Codex #AI Agent

学习笔记:Codex 使用电脑的三种方式

Codex 已经不只是一个待在终端和编辑器里的编程助手了。它现在可以通过不同的 surface 接触外部环境。这里的 surface 可以理解为 Codex 操作电脑和网页的入口,目前最容易混在一起的三种是:@Computer、@Chrome 和 @Browser。 它们看起来都和“用电脑”“打开浏览器”有关,实际边界却差得很远。选错入口,体验会立刻变差:需要登录态的后台任务,如果交给隔离的内置 Browser,它拿不到你的账号、Cookie 和浏览器扩展;只是看一个本地 localhost 页面,如果让 Computer Use 去打开真实浏览器一步步操作,就会把简单的页面验证变成慢点要死的慢动作。

#AI Agent

Google 发布 OKF:把 LLM Wiki 变成开放标准

今天 Google Cloud 发布了 Open Knowledge Format(OKF),一个把 LLM Wiki 模式标准化的开放规范。读完之后感觉这件事比标题看起来重要得多——它触碰的是构建 AI Agent 时一个真正的基础性问题。 问题:上下文组装是一个重复造轮子的苦差事 基础模型越来越强,但限制它们能做什么的往往不是模型能力,而是相关上下文的缺失。当一个 Agent 需要回答"怎么从我们的事件流里算 weekly active users?“时,它得从以下地方拼凑答案: