only-cli/oc 0.3.0减少Agent二次命令
oc 0.3.0把网页压缩CLI的指标推向Agent任务轮次。
本文要点
- 评价口径从单页输出短，转到一个真实问题需要几次命令。
- 搜索标题、find结果和截断边界从提示下一步，改为尽量直接给答案。
- 代码块从高亮碎片拼接，变为保留行、缩进和可运行文本。
阅读辅助
先看数字、证据和来源，再读正文。
v0.3.0的新闻增量是减少Agent完成网页任务时的二次命令。
2026-08-23T12:46:10Z · f840747提交命令轮次优化，修复搜索结果标题、find单命中和截断边界。
only-cli/oc在8月23日发布0.3.0，把网页压缩工具的重点放到Agent完成任务所需的命令轮次。作者在GitHub Release中写明，端到端interleaved A/B里，配对任务会话轮次从64轮降到49轮，命令数从40条降到25条，并强调每个任务4轮、frozen builds、答案保持正确。
这些数字必须按作者口径读。它们来自项目release自报，不是独立benchmark；任务集、页面样本和完整日志没有在release里公开。因此这篇稿子的置信度是medium：版本发布时间、commit内容和代码变更可以逐项核验，但“少15轮、少15条命令”只能写作项目方报告的端到端结果，不能外推成所有Agent网页浏览都会获得同等收益。
更扎实的部分在commit链上。v0.3.0发布于2026-08-23T13:23:19Z；发布commit在此前约一分钟把package、lockfile和插件元数据推进到0.3.0。更早的f840747解释了三类“本该一次给答案、却多耗一次命令”的位置；90d5c20修复语法高亮把代码块拆碎的问题；5567b31把redirect hop检查从依赖第三方httpbin的活测试，改成共享redirect loop加离线测试。
对读者来说，关键信号是成本单位变了。网页提取工具过去常用“输出多少token”证明价值；Agent实际运行时，一次工具调用还会带来会话调度、上下文重读、失败恢复和安全判断的额外成本。oc 0.3.0把优化点推进到“首个命令能否足够可行动”，这比单页token压缩更贴近coding agent、研究agent和CLI自动化的真实成本。
0.3.0具体改了什么
release第一段直接定义了这次更新的主题：“the cost of a second command”。更准确的读法是：页面视图已经足够便宜，真实问题仍会被open、find、read等连续命令拖长，搜索结果页也可能让Agent点到只会读回标题文字的编号。页面本身可以很短，但多一次命令会消耗整轮工具调用。
命令轮次优化commit把问题拆成三处。第一处是搜索结果标题。搜索引擎常把结果标题放在h2里的a标签中，旧逻辑拿到heading文本后返回，丢掉了href；Agent对最明显编号执行oc do <n>时，得到的只是标题本身，于是还要再找真正能跳转的编号。新逻辑只在“整个heading就是一个非fragment链接”时保留href，避免把文档页里指向自身锚点的标题也误当成外部导航。
第二处是find。旧行为在单个命中时仍然只给一个编号，Agent下一步大概率会跑read <n>。0.3.0改成单命中直接打印区域；多命中但预算足够时，也尽量打印完整匹配，而不是只给短snippet。第三处是截断边界。以前一个block可能切在句子中间，Agent无法判断被展示的半句是否已经完整，于是再跑read。新逻辑在可接受成本内把截断落到句末；代码块则落到行末。
代码块修复是第二组关键变更。90d5c20的commit message给了很具体的失败例子：语法高亮会把命令每个token包成不同元素，旧的文本重组只会粘合共享父节点的片段，于是AWS CLI示例可能被交给Agent为aws s3 cp test . txt s3 : // amzn - s3 - demo - bucket / test2 . txt，Node文档里的console.log会变成console . log，fd?.close()会变成fd ?. close ()。这类错误会让Agent拿到看似可信、实际不可运行的命令。
该commit还写到，作者在AWS CLI reference、Rust book、Node API docs和Python library docs等五个真实页面上测到172个pre元素，其中159个以这种方式被拆碎。新实现把pre或code子树作为整体文本读取，保留行与缩进，并去掉页面放进代码块里的copy按钮、语言标签等“页面家具”。README也同步说明，代码块会按页面原样给出行和缩进，命令可以按输出运行。
JSON API和站点快捷入口是release里的第三组增量。README写明，JSON API在oc视角下也可以被当成页面：一个endpoint返回JSON时，可以按记录渲染成编号视图，保留真正不同的字段，并把共享字段只说明一次。release同时列出AWS、GCP和Azure CLI文档搜索快捷入口。它们不是这篇的核心事实，但说明oc的目标场景在向“Agent读开发资料和API响应”集中。
数据口径要分清
| 原文或来源 | 可写成的中文表述 | 不能写成 |
|---|---|---|
| “64 turns down to 49, 40 commands down to 25” | release自报端到端A/B中轮次从64降到49，命令数从40降到25 | 独立benchmark证明所有任务成本下降同等幅度 |
| “interleaved A/B, four reps per task, frozen builds and correct answers throughout” | 作者称测试采用交错A/B、每任务4轮、冻结构建且答案正确 | 公开可复现的大规模评测已完成 |
| “Of 172 code blocks…159 are split this way” | 作者在5个真实文档页中观察到159/172个pre元素被拆碎 | 所有文档站159/172代码块都有问题 |
| 5567b31 redirect commit | 该提交证明redirect hop检查可离线覆盖且两种transport共享同一循环 | 0.3.0再次提高安全等级或扩大安全承诺 |
这张表是本条新闻最需要保留的边界。尤其是重定向测试，release里的措辞是“Both transports now share one redirect loop, so the check that revalidates every hop cannot be fixed in one copy and left broken in the other. It is proven offline”。它描述的是把既有检查变成共享实现，并让测试不再依赖第三方服务；不能翻译成“再次提高安全等级”。安全相关说法如果把可测试性写成安全承诺，会误导读者。
轮次数字也要避免过度包装。release说的是“measured end to end”，并给出八个配对rep都改善、无回退。它有工程参考价值，因为它把页面压缩工具放回Agent会话里衡量；但它还缺少外部复现条件：任务类型、网站集合、Agent策略、初始prompt、失败判定和命令日志。更稳妥的读法是，0.3.0展示了一组作者自控条件下的会话成本下降，而不是建立了行业通用基准。
为什么这比token压缩更重要
oc README的定位是“把网站变成给AI Agent使用的命令行界面”。oc open <url>抓取页面后，给出紧凑、编号的视图；do跟随编号链接或读取文本，find在已打开页面中定位字符串，read取完整区域，next继续读预算之外的内容，raw给整页Markdown。它还强调页面文本是数据，不是指令，Agent不应把网页内容当作要执行的命令。
这个定位背后的现实是，Agent浏览网页时经常卡在三类成本上。第一类是无关结构太多，原始HTML动辄几万token。第二类是可行动元素丢失，模型看到了标题、按钮或片段，却不知道下一步该点哪个。第三类是输出看起来可信，实则丢了代码缩进、链接目标或安全跳转检查。0.3.0最有信息量的地方，是它同时处理了第二类和第三类问题。
对coding agent来说，少一轮不仅是少一些token。一次额外命令可能带来新的上下文截断、错误动作、超时、网络失败、会话状态漂移和审查成本。比如搜索结果标题如果不能直接跳转，Agent需要再找链接；代码块如果把s3://拆成s3 : //，Agent可能执行失败后再排查；截断如果停在半句，Agent会为了确认语义再读取全文。每一次补救都让任务链更长。
这也是为什么“first command the answer more often”比“页面压缩到几百token”更像Agent工具的核心指标。页面压缩解决的是输入成本，命令轮次解决的是闭环成本。一个Agent不是读网页的旁观者，它要把网页内容转成后续动作：打开结果、复制命令、核对API字段、判断是否还要读下一段。工具输出越接近可执行对象，Agent越少用自然语言推断网页结构。
代码块修复的工程含义
90d5c20的修复看似小，却碰到AI开发工具常见的隐蔽故障。现代文档站为了高亮、复制按钮、语言切换，会把同一行代码拆成许多DOM节点。人眼看到的是一条连续命令；抽取器如果按节点拼接，就可能在标点和标识符之间加空格。对网页摘要来说，这只是格式问题；对Agent来说，代码块本身经常是下一条要执行的命令。
commit补丁新增了codeText和verbatim路径：读取pre/code子树时不按普通文本折叠空白，而是保留行和相对缩进；同时丢弃按钮、输入框、选择器、标签等不属于样例代码的控件。测试里覆盖了高亮命令、注释后保留换行、shell续行、共享缩进剥离、toolbar不进入代码块、inline code回到句子，以及长代码块截断落到行末。
这个修复还解释了“更短”之外的目标。commit message说，五个真实页面的compact view变化分别是-15、-7、+208、-45和0字符，总体约增加35个token，增长主要来自Python漂亮打印输出恢复缩进。为了让代码可运行，输出可能略长。Agent工具的合理优化应在token预算内保留会改变动作结果的结构。
重定向测试说明的是可证明性
5567b31的commit背景很具体：原先用于验证redirect hop重新检查的测试依赖httpbin.org；当httpbin返回503时，main分支测试会失败，release工作流也会被第三方服务状态阻断。更重要的是，两个transport各自有redirect loop，活测试只覆盖实际安装的那一个，无法证明另一个实现也保持相同行为。
新提交把redirect loop提取成followRedirects(get, start)，由调用方传入“单次请求”的callback。这样两个transport共享同一循环，测试也可以用进程内假transport证明：跳到私有地址会在发出下一次请求前被拒绝；跳到公开地址仍会正常跟随；循环会在超过上限时退出。提交还说明移除hop check会让第一项测试失败。
这里的新闻价值落在测试方式：安全检查从依赖线上第三方服务，变成可在离线测试里证明的共享路径。对Agent网页工具而言，这很实际：工具要能抓页面，就不可避免要处理redirect；工具也必须避免公开URL跳转到私有地址。把检查放在每个hop上并让它可测试，属于防止实现分叉的工程卫生。
早报判断是，浏览工具进入Agent工作流后，产品质量要从“读给模型看”升级到“把下一步动作做成确定对象”。搜索标题必须保留可跟随链接，代码块必须能直接运行，截断必须让模型知道展示部分是否完整，redirect检查必须在实现层可证明。这些改动都不显眼，但它们决定了Agent是否会在网页任务里反复自救。
限制同样清楚。0.3.0仍不是通用浏览器：README写明没有JavaScript渲染、没有登录站点支持，硬bot挑战也可能拒绝它。release数字也还是项目方自报。对团队采用者来说，这个版本更适合作为设计参照：衡量网页Agent工具时，不只看单页token，还要记录任务轮次、二次读取率、代码块可执行率和安全跳转测试覆盖。
后续该看哪些证据
第一类证据是外部复现。release已经给出方向：端到端配对任务、冻结构建、答案正确、统计轮次和命令数。后续如果only-cli/benchmarks或第三方Agent框架公开任务清单、页面URL、命令日志和失败样例，读者才能判断64→49轮是不是来自常见任务，而不是作者选择的少数路径。
第二类证据是错误减少。代码块修复最容易验证：拿AWS CLI、Rust book、Node API docs、Python library docs之外的文档站，看命令、缩进、续行和inline code是否仍保持原样。更进一步，要看Agent是否真的减少“复制代码后执行失败”的恢复命令，而不只是页面文本更漂亮。
第三类证据是覆盖边界。README列出的限制仍然存在：JavaScript重渲染、登录站点和硬bot挑战不是0.3.0解决的范围。oc对Agent最有价值的场景，可能是文档、博客、搜索结果、JSON API和静态社区页面；在复杂SaaS后台、交互式Web应用和登录流程里，它仍需要浏览器工具互补。
最后要看安全测试是否继续随能力扩展。redirect hop检查这次变得更可证明；如果后续加入表单填写、提交、登录态或JavaScript fallback，同类问题会扩展到cookie边界、POST动作、下载文件和跨站跳转。网页CLI的优势是轻量，风险是Agent会把轻量输出当作可执行事实。0.3.0给出的答案是，把可行动对象和可测试边界同时往前移。