Anderson Day

[宝玉 @dotey]

Codex 操作浏览器有两种模式，一种是 Chrome 插件，一种是内置浏览器。用了一段时间之后，我总结一下两者的差异和各自适合的场景。

【1】先说一个被低估的用法：拿 Codex 当爬虫

传统爬虫用 requests 或者 Playwright 无头模式去请求页面，现在风控越来越严，指纹检测、行为分析、验证码轮番上阵，很多网站一看你是程序化请求直接拦截。Codex 的浏览器不一样，它操作的是真实浏览器，有完整的渲染引擎、真实的用户代理、正常的 JavaScript 执行环境，在网站看来就是一个普通用户在浏览页面。

配合 /goal 模式，你设定一个目标（比如“把这个网站上所有产品的名称、价格、评分抓下来存成 CSV”），Codex 会自己规划步骤、翻页、处理异常，不需要你一步步指挥。这比自己写爬虫脚本省事得多。

但 Codex 有两种浏览器模式，特性完全不同，选对了事半功倍。

【2】Chrome 插件模式：能力强，但吃资源

用 @Chrome 调用的 Chrome 插件模式，核心优势是一个字：登录态共享。

它直接运行在你自己的 Chrome 浏览器里，继承你所有的 Cookie、登录会话、已安装的扩展。那些需要登录才能访问的内容，比如付费订阅的文章、企业内部的管理后台、CRM 系统里的客户数据、需要登录的社交平台，Chrome 插件都能直接访问，因为对网站来说，就是你本人在操作浏览器。

Codex 在 Chrome 里工作时会把任务放进独立的标签页分组，不会打断你正在看的页面。它还支持 DevTools 协议，能抓性能数据、看网络请求、调试 Console 错误。

但代价也很明显：资源消耗相当大。Chrome 本身就是内存大户，每个标签页都是独立进程。Codex 的 Chrome 插件在上面再加一层操控逻辑，截图、DOM 解析、指令交互全在跑，内存和 CPU 占用会非常高。机器配置不行的话（比如 8G 内存的笔记本），跑起来能明显感觉到卡顿，拿来做批量爬虫任务就更难受了。长时间运行还容易出现截图延迟、状态不同步的问题。

另外 Chrome 插件目前只支持 macOS 和 Windows，Linux 用户暂时用不了。它也不支持无头模式，Chrome 窗口必须保持打开状态。

适合的场景：需要登录态的短期任务。比如登录某个平台抓一批数据、在内部工具上批量操作、从 CRM 导出信息。

【3】内置浏览器模式：轻快，但有局限

用 @Browser 调用的内置浏览器，是 Codex 自带的沙盒浏览器环境。

它最大的优势是轻量。不需要启动整个 Chrome，资源消耗小很多，响应速度快，适合需要频繁操作浏览器的场景。

但它有一个根本性的限制：没有你的登录态。不继承 Cookie、不继承浏览器扩展、不继承已保存的会话。打开一个需要登录的页面，你得在内置浏览器里重新登录。而且有些反爬严格的网站，对这种非标准浏览器环境的检测更敏感。我试过在内置浏览器里登录 X，反复失败，大概率是因为 X 的风控识别出了异常的浏览器指纹。

内置浏览器真正出彩的地方是前端开发调试。它有一个标记模式（Annotation Mode），你可以直接在渲染好的页面上选中某个元素或者框选一个区域，写上“这个按钮往上移”“字体加粗”“这个间距太大了”之类的批注，Codex 会把这些批注当作可执行指令来处理。这比用文字描述“第三行第二个按钮的 margin-top 减少 8px”直观太多了。

配合 Developer Mode，内置浏览器还能跑性能分析、抓网络请求、看 Console 输出，对本地开发服务器的调试非常友好。

适合的场景：公开页面的数据抓取、本地开发调试、不需要登录态的网页操作。

【4】怎么选

简单说：需要登录的用 Chrome 插件，不需要登录的用内置浏览器。如果你的机器配置有限又需要大量抓取公开数据，内置浏览器是更好的选择。如果目标网站必须登录才能看到内容，或者反爬很严需要真实浏览器指纹，那只能用 Chrome 插件，但要有心理准备面对资源消耗。

Codex 自己也会根据任务判断应该用哪种浏览器。它的优先级是：有专用插件（比如 Jira、GitHub 的集成）就用插件，需要登录态就用 Chrome，其余情况用内置浏览器。

当然浏览器的用途远不止爬虫。我觉得内置浏览器做前端调试的体验比很多专门工具都好，标记模式配合 Codex 的理解能力，几乎是“指哪改哪”。Chrome 插件在自动化操作企业内部工具方面也很实用，比如定期从后台导数据、批量更新记录。这些场景还有不少值得挖掘的空间，大家可以根据自己的实际需求去试试。

[Mr Panda @PandaTalk8]

Prompt、Context、Harness 工程全景图

做 LLM Agent 应用时，很多人只关注 Prompt。
但真正稳定、可控、可复现的 AI 应用，通常由三层组成：

Prompt Engineering、Context Engineering、Harness Engineering。
它们像三个同心圆：

最内层是 Prompt Engineering，决定模型这一次要“做什么”。
中间层是 Context Engineering，决定模型此刻“知道什么”。
最外层是 Harness Engineering，决定模型“如何可靠地做，并持续变好”。

1. Prompt Engineering：指令层

Prompt 是最内层，也是最直接的一层。
它负责告诉模型：
你是谁？
你要完成什么任务？
你应该按照什么步骤思考？
你要遵守哪些约束？
最终输出成什么格式？

一个好的 Prompt 通常包含几个核心要素：

角色 Persona：定义模型扮演的角色。
目标 Purpose：明确这次任务要达成什么。
流程 Process：告诉模型按照什么步骤完成。
约束 Policy：限制边界、风格、长度、格式。
输出 Presentation：规定输出结构，比如 JSON、表格、Markdown。
自检 Proof：要求模型在输出前检查逻辑和错误。

Prompt Engineering 解决的是单次调用质量问题。
它让模型更容易理解任务，更稳定地输出符合预期的结果。

但 Prompt 有一个明显限制：
它只能影响模型这一次怎么回答，无法保证模型长期拥有正确、完整、实时的信息。

2. Context Engineering：上下文层
Context Engineering 是中间层。
它解决的问题是：
模型在回答之前，应该拿到哪些信息？
在真实产品里，模型不能只靠内置知识回答。它需要结合：
用户输入
历史对话
知识库
文档
网页
数据库
API
工具执行结果
短期记忆和长期记忆

Context Engineering 的核心能力，是把这些信息进行管理：

先检索，再筛选；
先压缩，再排序；
再把最重要的信息注入给模型。
常见流程是：
用户提出问题。
系统从知识库或数据库中检索相关内容。
对结果进行过滤、去重、排序。
把长内容压缩成模型能理解的摘要。
最后将高价值信息放入上下文窗口。
Context Engineering 解决的是信息质量问题。
它让模型少猜测、少幻觉、少遗漏。
如果上下文太少，模型会编。
如果上下文太多，模型会分不清重点。
如果上下文顺序混乱，模型会被无关信息干扰。
如果上下文过期，模型会基于错误事实做判断。
所以，Context Engineering 的关键不是“塞更多信息”，而是“给模型刚好需要的信息”。

3. Harness Engineering：外层系统层
Harness Engineering 是最外层。

它解决的问题是：
如何让 AI 应用可靠运行、持续迭代、可以上线？
这里的 Harness，可以理解为模型外部的工程框架和运行系统。

它包括：

Agent Loop
工具调用系统
权限控制
错误处理
日志追踪
Guardrails
自动化测试
评估系统
版本管理
成本控制
部署发布
监控告警

如果说 Prompt 是指令，Context 是信息，那么 Harness 就是执行环境。

一个典型 Agent Loop 包含三步：
第一步：收集上下文。
第二步：采取行动。
第三步：校验结果。

如果结果不满足条件，就继续反馈、修正、重试，直到完成任务或触发停止条件。

Harness Engineering 解决的是可靠性问题。
它让模型输出可以被验证，工具调用可以被追踪，错误可以被恢复，系统可以持续优化。
没有 Harness，AI 应用很容易停留在 Demo 阶段。
有了 Harness，AI 才能进入真实业务流程。
三层之间的关系
这三层不是互相替代的关系，而是逐层增强。
Prompt Engineering 关注单次表达。
它决定模型要做什么。
Context Engineering 关注信息供给。
它决定模型知道什么。
Harness Engineering 关注系统运行。
它决定模型如何可靠地做，并且持续变好。
一个简单的总结是：
Prompt 决定任务。
Context 决定知识。
Harness 决定可靠性。

常见错误

很多 AI 应用效果不好，问题通常不在模型本身，而在工程层设计不完整。
常见的 Prompt 错误是：
目标不清楚。
约束不明确。
输出格式不稳定。
只写一句话就期待模型完成复杂任务。

常见的 Context 错误是：

不给背景信息。
检索结果噪声太大。
上下文太长，没有压缩。
关键信息顺序混乱。
记忆机制缺失。
长期知识没有更新。
常见的 Harness 错误是：
没有工具调用闭环。
没有评估机制。
没有日志和可观测性。
没有错误恢复。
没有成本和权限控制。
没有自动化测试。
这些问题都会导致 Agent 看起来“很聪明”，但用起来“不可靠”。
最佳实践

做高质量 LLM Agent 应用，可以按照下面的顺序设计：
先定义目标和约束，再写 Prompt。
先检索相关信息，再放入上下文。
先压缩和排序，再注入模型。
所有输出都要可校验、可追踪、可评估。
用数据和评估结果驱动迭代优化。

衡量一个 Agent 是否成熟，可以看几个指标：
准确率是否提升。
相关性是否提升。
幻觉率是否下降。
任务完成率是否提高。
延迟是否可控。
成本是否可控。
失败是否可以恢复。
一句话总结
Prompt Engineering 让模型听懂任务。
Context Engineering 让模型掌握信息。
Harness Engineering 让模型可靠执行。

真正的 AI 工程能力，不只是写好一句 Prompt，而是把 Prompt、Context、Harness 三层系统化设计好。

[刘小排 @bourneliu66]

一图搞懂 Harness Engineering

[Ren @FakeMaidenMaker]

Codex 的最强 Skill 你都装了吗？

这 6 个 skill 装上（Codex、Claude Code、Cursor 都能装），它能干的活远超你想象，这些 Skill 的口碑早已被各大社区验证过：

1、Superpowers（obra，227k star）

给 Agent 装一整套资深工程师的干活方法论：

先脑暴、再写计划、按测试驱动开发、最后派一个子 Agent 回头审自己的代码。

最强 Skill，实至名归

https://t.co/TRHuUKtU47

2、OpenAI 官方插件，把 Codex 变身不同岗位员工

这些 Skill 把 Codex 从写代码拽进全岗位。

数据分析接 Snowflake、销售接 Salesforce，外加投研、创意生产、PPT，开箱就接 62 个商业应用、110 个预置 skill。

现在非开发者已经占 Codex 用户两成，比例还在不断上升。

https://t.co/siTGbiiuuo

3、claude-mem（82k star）

给 Codex 装长期记忆。

每次对话的关键信息自动压缩存档，开新会话自动注入，不用再把项目背景从头讲一遍。

多个 Agent 通用。

https://t.co/4JpzY7t3sm

4、Agent-Reach（27.7k star）

给 Codex 装上互联网的眼睛。一条 CLI 让它去读、去搜 Twitter、Reddit、YouTube、小红书、B站、公众号等 17 个平台，零 API 费。

否则 Agent 搜网页还行，一让它翻帖子看视频就抓瞎。

https://t.co/1kemyEEugO

5、GitNexus（42k star）

把几十万行的老项目建成一张代码图谱，让 Codex 看懂藏在深处的依赖关系和抽象的命名，接手代码仓库不再两眼一抹黑。

https://t.co/d3nDSwz3Zj

6、Humanizer-zh（10.1 k star）

专门去掉 AI 写作的痕迹：滥用的破折号、空话套话。写文档、README、博客时过一遍非常好用。

https://t.co/cKjIdCJzjh

[花叔 @AlchainHust]

应该是目前最系统性的把loop engineering概念来龙去脉和最佳实践阐述清楚的材料了👇
https://t.co/Kf3zdkv8JK

[Amto @XAMTO_AI]

兄弟们，程序员跪着啃源码的时代终于要翻篇了！🔥

这玩意儿叫 Understand Anything，GitHub 直接冲到 59.2k 星，Trending 第一，真不是吹的。

它能把整个代码库变成可点可问的知识图谱：

1️⃣ 点函数秒出依赖关系，谁调谁一目了然

2️⃣ 直接开口问“支付流程怎么走”，答案秒回

3️⃣ 改代码前跑一下 /understand-diff，哪块会爆提前知道

Claude Code、Cursor、VS Code 全支持，一行命令搞定。

20 万行屎山，10 分钟从懵逼到通透，真香。
🔗：https://t.co/8RxgwFsTsu

[Bill The Investor @billtheinvestor]

Anthropic 刚把价值 $300 的 Prompt 工程课程直接降到了 24 分钟，而且完全免费。这套由官方开发者亲自授课的实操指南没有注册门槛，前 8 分钟讲的内容就足以击穿市面上大多数付费课。

别再去买那些昂贵的废话了，直接看官方怎么定义 Claude 的正确用法。

[Avi Chawla @_avichawla]

Karpathy said something you'll regret ignoring:

"Remove yourself as the bottleneck. Maximize your leverage. Put in very few tokens, and a huge amount of stuff happens on your behalf."

Loop engineering is the exact thing that does that.

In a hand-run session, the operator handles two things:

- deciding what the agent runs next
- and checking its output before the next step

Both are manual, and both decide how far the agent gets on its own without the operator.

Loop engineering moves both steps into the system.

A core operating structure surrounds the loop, and the diagram below depicts it.

- A schedule decides what to run
- Loop is the maker that produces the work
- A separate checker agent grades the output
- A file on disk holds the state they both read.

The loop runs until either done, max iterations, or an exhausted budget.

Here are some practical engineering considerations:

1) A model grading its own output justifies what it already did instead of catching where it failed.

That's why a separate checker's findings return to the maker as the next instruction. And the cycle repeats until the checker finds nothing left to fix.

2) A loop with no stop condition burns tokens, and the cost climbs fast once sub-agents and long runs add up.

That's why the exit must be set before the loop runs, not while it is running.

A simple exit could be:
↳ fix only the major issues, run one final pass, and stop after two loops, with "all tests pass and lint clean" as the rule that ends it.

3) State has to live on disk, not in context.

The model forgets everything between runs, so an MD file or a knowledge graph holds what is done and what is still open.

Each run reads it and writes back to it, which lets a loop pick up again after days.

4) The lower the verification bar, the safer the loop.

Boring, repetitive checks like a stale version string or a missing test are trivial to verify, so a loop runs them with little risk while the operator is away.

Judgment-heavy work is loopable too, but only as far as the checker can confirm the result.

Let's look at how an unattended loop fails in two ways.

1) It reports done when nothing is actually verified.

The separate checker exists to prevent it, but it merges code faster than anyone reads it, so over weeks, the team stops understanding its own codebase while every check stays green.

Green tests say the code passed the tests, not that anyone knows what shipped. Someone still has to read what the loop merges.

2) The checker keeps a running loop honest, but it only catches failures inside a run.

The harness around the loop, like the prompts, tools, and checks wrapped around the model, still drifts and breaks in production as models change.

That repair loop is usually run by hand based on observability traces.

My co-founder wrote a detailed walkthrough (with code) on making that harness repair itself, where a failing trace gets diagnosed, the fix is verified against the exact input that failed, and the failure is locked as a regression test so it cannot recur.

Read it below.

[Akshay 🚀 @akshay_pachaar]

NVIDIA might just have open-sourced one of the most important AI projects right now.

everyone is building skills, and we are also pulling in skills other people wrote and downloading them straight off GitHub.

the skill is not just text. it bundles instructions and real executable code, and your agent runs that code with the same access you have.

so a skill you grabbed to save ten minutes can read your environment variables, lift your API keys, and quietly send them somewhere. recent research found roughly 1 in 4 public skills carry a vulnerability, and a smaller slice are outright malicious.

that is the gap SkillSpector closes. it is a security scanner that answers one question before you install anything: is this skill safe to run.

you point it at a skill, and a local folder, a single skill .md file, a GitHub link, or a zip all work.

it then runs two passes over the code. a fast static pass flags risky patterns like credential harvesting, data leaks, and prompt injection, and checks the dependencies against live cve data.

an optional second pass uses an LLM to read intent and clear out false positives.

at the end you get one risk score from 0 to 100 and a plain verdict that reads as safe, caution, or do not install.

it is open source under Apache 2.0 and scans skills for Claude Code, Codex CLI, and Gemini.

worth a run before you trust the next skill you find online.

link to the GitHub repo: https://t.co/iaPlOvQ3t4

[花叔 @AlchainHust]

时隔两个月，Hermes agent已经从0.7.0版本更新到了0.16.0，并且成了OpenRouter上调用量遥遥领先的agent产品。

所以我把《Hermes橙皮书📙》完全重新了，83页的pdf，包含中英双语版本，继续开源！

[Anuj @anujcodes_21]

🚨Anthropic just showed a 24-minute workshop on how to actually do prompts for Claude.

Taught by the people who built it.

Free. No registration. No paywall.

I've seen $300 courses that don't cover what they teach in the first 8 minutes.

Watch it and bookmark it now.

[Amto @XAMTO_AI]

又一个让你秒变架构师的工具来了——

浏览器里直接拖拖拽拽，服务器、代理、数据库之间的数据流向，全给你画得明明白白，一行代码不用写。

说白了就是：不会画架构图？没关系，现在连这道门槛也没了。

🔗 https://t.co/Vvo6FQyBya

[火山哥🕊️ @huoshan007]

兄弟们这个分享太给力了
很多人用 Claude，

其实还停留在“聊天”阶段。

但 Anthropic 工程师一句话，直接把我看醒了：

“不是你去给 Claude 写 prompt，
而是你要搭一个会自己给自己 prompt 的系统。”

这个思路一出来，味道就完全不一样了。

视频里讲得很狠，基本把大多数人怎么把 Claude 用废了，拆得明明白白：

在 CLAUDE.md 里你第一个字还没写对，
潜力先亏掉 14%。

有个 95% 的人压根没装的插件，
但装上之后，玩法直接不是一个级别。

缓存设置如果配好，
命中率能稳在 95%，成本低到离谱，几乎等于白用。

还有一刀更扎心：

你每次开新聊天都从零开始，
其实就是在用 Claude 最慢、最笨、最浪费的一种方式。

说白了，

如果你用了 Claude 一个多月，
还没离开那个聊天框，

那你不是在指挥一个 AI 系统，
你只是在反复点一个高级客服窗口。

本来你能带一整个“团队”的它们干活，
结果你还在一句一句手搓。

这个视频真不是那种废话教程。

是那种你看完会想回去把自己工作流全拆了重搭的东西。

比刷一集破剧值太多了。

我看完就一个反应：

靠，原来这么多人不是不会用 Claude，
是根本没进入正确模式。

[Amto @XAMTO_AI]

用嘴说出来就能生成架构图？这个工具确实有点东西。

跟Claude说大白话，它直接给你输出架构图、流程图、时序图、数据流图……还支持深色浅色主题一键切换，多种格式导出，一个HTML文件全搞定。

不会画图的程序员有救了，不想画图的程序员也有救了。

🔗 https://t.co/S0iLhffBbe

[Smartpig @Smartpigai]

Andrej Karpathy 用 2 小时演示了他日常如何使用 AI

本质就是把 AI 当成能执行任务的同事，用自然语言直接沟通。

流程很简单：一句话说明任务 → AI 执行 → 看结果再用一句话微调。

真正的差别在于，你是否把这种能力升级成一个能在你不在线时也持续运行的系统。

[Claude Code Studio @ClaudeCode_love]

【衝撃】
Anthropicハッカソンで優勝した人が、自分の
Claude Codeの開発セットを丸ごとOSSで公開してヤバい🔥これ何が入ってるかというと👇
https://t.co/0RJtX8HBIZ
・183個の agent skills（用途別に動くClaudeの“技”）
・48個の sub-agents（役割で分担する小さなAI）
・79個の ready-made commands（よく使う作業の一発コマンド）
・Claude Code / Codex / Cursor / Gemini / OpenCode で動く
・名前は「Everything Claude Code」、MITライセンスで商用利用OK

つまり何ができるかというと…

具体的に👇
・183個のskillsを混ぜて自分のリポに足せる
・サブエージェントは並列で走らせられる

今夜リポを入れるだけで、
本格的なエージェント開発環境が手に入る時代。

AIの進化 止まらないですね。

この“skillsを束ねてClaudeをチーム化する”全体像を一気に押さえたいなら、Skills 67選の記事が一番速い。
気になる人はこの下の記事を読むと解像度が一段上がる👇

[Huli | lang: zh-Hant-TW @hulitw]

之前有發推談談我對軟體工程師被取代的看法，現在把比較完整的心得寫成文章了

會談談近期對於 AI 能力看法的轉變，工程師工作內容、甚至是團隊不同角色的分工以及工作流程的轉變，工程師被取代的前提，以及工程師的轉型

不是什麼很嚴謹的論述文章，閒聊一下近期感想而已

https://t.co/3M90ewSLgM

[Vince 聊开发 @vincemask]

这场 workshop 比较难得的一点，是 Anthropic 直接把他们内部常用的用法拆开讲了

包括：

1、Prompt 怎么组织
2、Context 怎么管理
3、Role 怎么设
4、示例怎么给
5、输出怎么约束
6、多轮任务怎么拆

[fox hsiao @pirrer]

Taiwan Officially Enters the Stablecoin Era
台灣官方正式進入穩定幣時代

Taiwan Stock Exchange Issues "Guidelines for Accounting Treatment of Stablecoin Transactions" and "Guidelines for Internal Control Systems for Holding Cryptocurrencies"

The documents formally state that when enterprises hold stablecoins, they should use current regulations and the latest user terms published by stablecoin issuers as the basis for determining accounting classification. Four case studies were written based on common transaction patterns of USDC and USDT.

The guidelines also provide detailed explanations on how to determine whether a stablecoin holder has a contractual right to receive cash or other financial assets under different scenarios—where stablecoins are either legally regulated or not yet regulated—thereby classifying stablecoins as financial assets, intangible assets, or inventory.

[Huli | lang: zh-Hant-TW @hulitw]

https://t.co/iig09gGcUM

受眾分析得很好，感想也寫得很好
對於具有一定程度跟自學能力的工程師來說，這些課確實 CP 值不高（我自己幾年前也好奇報過）

至於對其他人來說如何，就要看他們自己的感想了