返回首页
最新
我建立了一个仪表板，旨在使国家级经济数据变得易于理解。<p>它不是简单地显示“出口额为X十亿美元”，而是展示意大利出口了9600万件连衣裙、11000艘游艇和21亿升葡萄酒。<p>截图：<a href="https://imgur.com/a/kuxWr55" rel="nofollow">https://imgur.com/a/kuxWr55</a><p>该仪表板涵盖了37个国家的贸易（联合国商品贸易统计）、政府支出（经济合作与发展组织/政府职能分类）、收入、债务、战略资源依赖以及24个世界银行指标。<p>技术栈：Next.js + React + D3.js，FastAPI + SQLite后端。<p>目前尚未上线，分享截图以便在发布前获取反馈。想知道这对任何人是否有用，或者我是否只是在为一个人而构建。
我开发了一个基于浏览器的工具，利用视觉-语言模型（VLMs）通过自然语言提示在卫星图像中检测物体。用户可以在地图上绘制多边形，输入想要查找的内容（例如：“游泳池”、“油罐”、“太阳能板”），系统会逐块扫描，并将边界框以GeoJSON格式投影回地球上。
工作流程如下：选择缩放级别 + 提示 → 将地图切割成商业瓦片 → 将每个瓦片和提示输入VLM → 创建边界框 → 投影到WGS84坐标系 → 在地图上渲染。
演示不需要登录。对于明显的结构，系统表现良好，但在处理密集或被遮挡的物体时，狭窄的YOLO模型仍然更具优势。
代理的核心能力完全源于基础的大型语言模型（LLM）。因此，代理的未来严格取决于当前LLM的状态。
那么，LLM现在处于什么阶段呢？
我认为我们目前正处于人工智能的“家庭工业”阶段——工业化的黎明。用一个历史类比来说：我们刚刚发明了第一台蒸汽机。它们笨重、固定，只能用于从煤矿抽水。我们距离拥有蒸汽机车还远得很。
现在，定制代理的数量正在迅速增长。但如果仔细观察，它们几乎都是“自给自足”的，并且相互孤立。每个人都在为自己特定的用例构建自己的代理，但要将它们适应或扩展到更广泛的用途却非常困难。这就像每个家庭都有自己的织布机，织自己的布料，从不使用别人的。
为什么会这样？这归结于当前LLM的局限性。如果暂时不考虑多模态能力，基于文本的LLM基本上有四个核心支柱：
1. 自然语言理解（NLU）
2. 自然语言生成（NLG）
3. 工具调用
4. 推理
前面三个已经非常成熟且可靠。但第四个——推理——仍然是一个充满幻觉的雷区。
然而，代理开发者最为痴迷的是什么？推理。为什么？因为在演示中看起来很酷。这种痴迷正是我们无法真正“工业化”代理的原因。这也是为什么在实际应用中很难找到一个真正可靠的通用代理（最近关于Manus的炒作与现实检查就是一个教科书式的例子）。
当然，总有一天LLM的推理能力可能会超过99%的人类。当那一天到来时，我们将最终看到真正强大、通用的代理。但老实说，没有人确切知道这个时间表会在何时到来。
我的结论是：如果我今天要为生产构建一个通用代理，我将严格利用NLU、NLG和工具调用。我会尽量避免依赖“推理”。
最近和一些朋友关于人工智能的对话让我思考了这些。我的观点似乎引起了他们的共鸣，所以我在这里分享，希望听听你的想法。
如果你曾想让你的高大上的 TUI 接受一些混沌工程的考验，看看它如何应对 500ms 的抖动，而不必真的去找一个信号差的 Wi-Fi 点，我为你开发了一个工具！<p>ttylag 将任何命令包装在一个“形状”的 PTY 中。无需复杂的管道，也不需要 tc 排队规则。它可以处理 RTT 和抖动，双向延迟，甚至还有一个 --bits-per-byte 标志（如果你对此感兴趣的话）。<p>它仅在用户空间中运行，支持 macOS，可能也支持 Linux，无需调整网络命名空间或防火墙规则。
我编写的每一个爬虫都有相同的失败模式：它工作三个月后，网站进行重新设计，我的 CSS 选择器默默地返回空字符串。数据仍然在页面上——人类可以瞬间找到它——但爬虫却失去了视线。
Trawl 通过将问题拆分来解决这个问题。你描述你想要的内容：
```
trawl "https://books.toscrape.com" --fields "title, price, rating, in_stock"
```
大型语言模型（Claude）查看一个示例项目并推导出完整的提取策略——CSS 选择器、属性映射、类型转换、后备选择器。该策略会被缓存。每个后续具有相同结构的页面都使用纯 Go 和 goquery 提取。没有 API 调用，没有令牌成本，完全并发。
关键见解：大型语言模型擅长理解 HTML 结构，但你不需要它们来提取 10,000 行数据。使用 AI 进行智能处理，使用 Go 进行高吞吐量处理。
当网站重新设计时，结构指纹会发生变化，缓存失效，Trawl 会自动重新推导。
你可以预览它到底推导出了什么：
```
$ trawl "https://example.com/products" --fields "name, price" --plan
策略针对 https://example.com/products
项目选择器：div.product-card
字段：
name: h2.product-title -> text (string)
price: span.price -> text -> parse_price (float)
置信度：0.95
```
一些需要真正工程努力的功能：
- JS 渲染的单页应用：无头浏览器与 DOM 稳定性检测——轮询直到元素数量稳定，骨架加载器解析，滚动以触发懒加载，自动点击“显示更多”按钮
- 多部分页面：启发式检测候选数据区域，使用 `--query "Market Share"` 针对特定部分，利用容器选择器进行提取范围
- 自我修复：监控提取健康状况（填充字段的百分比），如果低于 70%，则重新推导策略
- iframe：自动检测并从 iframe 中提取数据，当它们包含比外部页面更丰富的数据时
输出格式为 JSON、JSONL、CSV 或 Parquet。管道清晰：
```
trawl "https://example.com/products" --fields "name, price" --format jsonl | jq 'select(.price > 50)'
```
使用 Go 编写，MIT 许可。
我创建了ccp，因为我注意到编码代理在终端输出上浪费了大量上下文。<p>它会执行真实的命令，修剪重复的部分，同时保持命令行为不变。<p>以下是两个来自实际工作的真实案例：<p>Java/Gradle任务（Claude Code）：5,330,571 -> 90,127 估计标记，跨越88个命令（节省了98.31%）<br>跨4个代码库的研究任务（Claude Code）：944,007 -> 59,195 估计标记，跨越96个命令（节省了93.73%）<br>你可以通过安装脚本进行尝试，运行ccp init，然后通过ccp gain检查效果。<p>这并不是每个命令都能神奇地节省上下文。在这个代码库与Codex的实际使用中，当命令中有大量像sed和openspec这样的传递命令时，整体节省效果较低。<p>它还可以通过ccp init在广泛的代理中使用，包括Codex、Claude、Cline、Cursor、Gemini、GitHub Copilot、Roo Code、Aider等。<p>代码库：<a href="https://github.com/SuppieRK/ccp" rel="nofollow">https://github.com/SuppieRK/ccp</a><p>如果你大量使用编码代理，哪些命令在你的工作流程中浪费了最多的上下文？