事情起源于这个月Workbuddy赠送的积分即将到期，加之我Codex的额度仅剩2%，在等待重置之前实在舍不得再动用充值卡。恰好手头有一个PMBrain的需求需要调整，于是便决定让GLM 5.2来接手这次修改任务，毕竟它一直以来的口碑相当不错。

为了稳妥起见，先通过ask模式进行了两三轮的方案讨论，梳理出明确的执行思路后才正式开始动手。

光是执行这个小改动的积分消耗，加上此前几轮的交互，基本上把我这段时间攒下来的积分全部清空了。本以为一切顺利，结果出来的效果却让我大吃一惊——这个bug离谱到甚至让我进入应用后不得不重新去配置数据库。我赶紧追问GLM到底是怎么回事，它倒也不推诿，干脆地承认是自己的操作出了错。

事已至此，只能硬着头皮让它继续修复。看它语气比我还要着急，紧接着一通操作，甚至之前我特意定义的一些约束条件也似乎被抛到脑后，直接给我打了一个全新的包，催促我赶紧测试。

这次虽然不再有阻塞性的bug，但更严重的问题随之而来：我压根没看到自己想要实现的功能。一开始我还以为是自己没找对地方，于是客气地再问它。

它的回应却让我彻底失望，不仅完全没有理解我的意图，反而把我原本能正常使用的功能给改坏了。那一瞬间，我对GLM 5.2的所有滤镜碎了一地。曾经一直拿它当“国内名校”顶尖高材生来看待，没想到实际水平也就堪堪和Deepseek打个平手，而消耗的“薪资”却高得离谱，这实在让人难以接受。

这次真的把我惹毛了，忍不住劈头盖脸一段输出，差一点就要飙脏话了。跟Deepseek打交道多年让我明白，愤怒没有任何用处，只能保持理智而又激烈地把需求重新说清楚。要是对面是个人，大概已经吵起来了。

结果又一次出来了，依旧是自行打包，没有完全遵守我的约束。我也不再计较细枝末节，先打开看看到底改没改好。万幸这次总算呈现出了我想要的内容，于是立刻开始测试，甚至还连上另一台电脑进行验证。然而，麻烦又来了。

它修改的OAuth客户端根本不支持连接到MCP上，意味着之前所有的折腾几乎全是无用功！这次错误直接暴露了从讨论阶段它就已经把我带进了沟里。反思之下，确实怪我太相信它的实力，没能及早对方案提出质疑，也怪我一开始就没有分清API key接入和OAuth客户端接入的差异，导致方向错误。但话说回来，又有谁能对一整个项目了如指掌呢？连这点分析都做不明白，以后我又怎么敢再托付信任？

于是，我用仅剩2%额度的Codex，去review GLM 5.2所写的代码，并且让它把API key支持共享模型的需求一并加进去。Codex果然不负所托，在额度几乎见底的情况下完美实现了我的需求。

GLM 5.2输出的代码也确实被查出了问题，上图里提到的那些细节我未必全懂，但有一条让我印象极其深刻——它根本就没有根据这次需求去修改测试脚本。不修改倒罢了，关键它连测试都没有执行，这一点真的，让人无话可说……

我的思考

这次经历对我的“打击”着实不小。一直以来我都是国货的坚定支持者，论坛上但凡有人夸国产模型的好，我都会去“帮帮场子”。可亲身经历下来，GLM 5.2真的达到了能与ChatGPT 5.5或者opus 4.6同台竞技的程度吗？我深表怀疑。

我也忍不住怀疑是否“马具”的问题，毕竟Codebuddy和Workbuddy这两位坑我也不止一次两次了，但腾讯豪爽大方，积分送个不停，我也只好“当没发生过”继续用下去。也许确实是误判，也许我压根没体验过正宗版的GLM 5.2，Workbuddy上的GLM很可能是腾讯拿开源自己部署的，未必随着智谱持续更新升级，降智的情况恐怕在所难免。

我真心希望国产模型能越来越好，盼望着有朝一日，那些用惯了ChatGPT和Claude的用户全都回流。也诚心希望腾讯打造的Workbuddy能够击败Codex，让每个人都用得舒服自在，对每一个功能和细节都发出由衷的赞叹。

只是，不要让我们等太久哦！

在与 GPT-5.5 的对话中，它针对我一直关注的 AI 与大模型领域，输出了一份极具创意的文档——《模型大乱斗游戏概念文档》。下面就是这份方案的全部内容，一字未删，你可以直接拿去测试或选择自己最感兴趣的模式来实践。

项目概念

这是一款以主流 AI 大模型、开发工具和真实使用场景为核心元素的趣味小游戏。游戏并不只是简单地把 GPT、Claude、Gemini、DeepSeek、Kimi、GLM、Qwen、Fable 5 等模型品牌做成角色，而是将大模型时代常见的真实概念转化为游戏机制。

例如：429 限流、上下文爆炸、模型降级、API Key、缓存命中、额度翻倍、Prompt、RAG、多模型路由、幻觉、Bug、Agent、Claude Code、Auto Mode、Bypass Mode 等，都可以变成角色、技能、道具、陷阱或关卡机制。

核心目标是制作一款既有 AI 圈子梗，又适合公众号传播的轻量小游戏。

核心一句话

这是一款 AI 开发者生存游戏。玩家不是在单纯打怪，而是在与限流、幻觉、上下文爆炸、模型降级、API 成本、Bug 和需求变更搏斗。

核心卖点

1. AI 圈子梗强，技术用户和公众号读者容易理解。
2. 大模型品牌与 AI 概念可以自然游戏化。
3. 可做成单 HTML Canvas 小游戏，开发成本低。
4. 适合利用 Fable 5、Claude Code 等模型快速生成原型。
5. 游戏过程本身可以产出公众号文章、视频素材和模型评测案例。
6. 后续可扩展为生存、塔防、经营、解谜、竞技等多种模式。

基础世界观

玩家是一名 AI 开发者，正在使用各种模型和工具完成项目。在推进过程中，会不断遭遇 AI 时代特有的问题：

• 429 限流
• 模型降级
• 上下文爆炸
• 幻觉污染
• Token 不够
• API 成本飙升
• Bug 越修越多
• 需求频繁变更
• 缓存失效
• 模型回答不稳定
• 工具调用失败
• 多模型路由错误

玩家需要在这些混乱中收集资源、切换模型、击败敌人、完成任务，最终撑过限制时间或击败限时 Boss。

在AI行业，最不可能主动为开源路线站台的公司之一，刚刚在公开场合打破了沉默。Grok母公司xAI的官方账号直言：权威不再靠边境维持。

PERSPECTIVE

并非某一国输给了另一国，而是开放路线为自己赢下了该赢的那一场。

昨日，Grok官方账号在X上发表了一段措辞异常冷静的声明。它表示，开源模型必然按照设计传播——一纸国别禁令阻挡不了全球范围内的fork、下载和微调。

随后，它将Meta的Llama、Google的Gemma列为美国先行者，并把自己更早发布的Grok-1权重也归入美国的贡献。紧接着，它把目光转向另一组名字——DeepSeek、Qwen等中国实验室，坦率承认领先地位来自更快的迭代速度、更充足的人才以及更通畅的算力获取，而非人为限制。

“Leadership comes from faster iteration, talent, and compute access, not restrictions.”

这段表述值得细读。它把一个被地缘政治裹挟的叙事，重新拉回到工程现实的坐标里。率先决定谁赢的并不是某个国家，而是开发者社群用实际使用量和场景适配度做出的投票。

一个模型被拉到更多场景中进行fine-tune，不意味着它在技术上绝对领先，而是意味着它的权重更值得被当作可编辑的公共资产。

01

“领先叙事”正在松动

过去三年，业界反复看到同一个叙事结构：美国闭源实验室率先取得前沿优势，随后中国用一个开源版本跟进并实现部分替代。进入LLM++时代，这一结构开始失效。

失效的原因并非闭源阵营变弱，而是开源路径本身正在持续喂养一个更庞大的全局。

DeepSeek和Qwen在HuggingFace上的下载量并非单纯的实验室数字，而是开发者们真实的路径选择。GPU集群算力的全球化进程加速了这一趋势。当一个模型能够在任何配备足够显存的节点上运行，地理边界就失去了实际意义。

禁令仅仅对受限环境中的采购指令有效，对开源结构本身束手无策。

对于普通开发者和AI创业者而言，这意味着再不必等待官方API，也无需依赖某一国的云端服务，就能直接获取最强的模型权重。

真正的问题转化为——你手中有多少算力可以支撑这些权重运行？以及你计划投入多少工程人力去完成fine-tune和数据对齐。

02

开放路线没有道德优势，它只是更接近工程的真相

Grok主动承认OpenAI和Anthropic采用闭源路线，并坦言“中国实验室在效率和发布节奏上领先”，这并非示弱，而是把焦点从政治叙事重新拽回到产品和技术本身。

无论媒体多么热衷于用“中美AI竞赛”这几个字来刻写事件，技术路径的真实走向始终与这四个字关系不大。Grok的帖文看清了这一点，并直接利用了它。

这不是出于同情心，而是出于策略。它在降低自身商业模型与美国出口管制之间的摩擦成本，同时也在提醒付费用户：xAI至少在Grok-1阶段走的是开放路线。

一本技术账被写成外交辞令，反而更具说服力。

可以预见，这篇文章的传播边界会超过xAI最初预设的范围。西方主流媒体可能将其视为中国威胁论的佐证，但真正的Builder眼中只会有这样一句话：又有一批权重今天可以合法下载。

对于中文世界里的开发者，这件事的直接含义是：开源并不仅仅等同于“免费”。它此刻代表着最接近无国家属性的模型资产网络。TensorFlow和PyTorch的故事正在此处重演，唯一的不同在于，这次的主角不再是框架，而是权重本身。

当权重成为基础设施，社群比政权更难管。

大模型应用跑久了，最让人头疼的往往不是模型能力不够，而是它面前堆砌了太多信息。一次 grep 可能返回几百行，构建日志动辄上千行，RAG 又塞进一堆相似文档片段。开发者固然可以把这些内容一股脑扔进上下文，可 token 开销、响应延迟以及模型注意力衰减都会随之飙升。

今天看到了一个颇受欢迎的开源项目，名叫 Headroom。截至当前，它在 GitHub 已经收获了 5.6w+ Star。

这个项目到底在做什么

Headroom 定位很清晰：它部署在应用或 Agent 与 LLM 服务之间，先对工具输出、日志、文件内容、RAG 片段以及长对话进行压缩、重组，再把优化后的请求转发给 OpenAI、Anthropic、Google 等模型提供商。

它为哪些痛点而来

很多 LLM 应用最初都是靠更大的上下文窗口硬撑。从 32K 到 128K 甚至更长，表面上看问题似乎缓解了。但在真实的 Agent 链路里，挑战远不止“长度不够”。工具结果中重复项泛滥，日志里充斥着噪声，JSON 数组内大量结构相同的记录层层叠叠，而系统提示里还经常夹杂当前日期、会话 ID 等动态字段，导致厂商的 prefix cache 很难命中。

Headroom 瞄准的正是这一层。它不负责撰写 prompt，也不替你挑选模型；它嵌入在“应用准备上下文”与“模型真正接收上下文”之间，进行筛选、压缩、组织和可逆注入。这个位置非常关键——模型看到什么、以何种顺序看到、哪些内容保留原文、哪些变成摘要或索引，都会直接影响回答质量和计费额度。

这种思路正是 Context Engineering 的核心理念：不是反复调整提示词的措辞，而是精细管理模型窗口里到底放什么、怎么放、何时放、何时撤。上下文工程重点关注模型窗口内内容的动态管理，涉及压缩、缓存、可逆注入等技术，从而在效果和成本之间找到更优解。

内部机制怎么转

Headroom 在本地接收 Agent 的 prompt、工具输出、日志和 RAG 结果，先完成缓存对齐、内容识别、按类型压缩以及原文可回查存储，然后再把更短小的上下文连同 headroom_retrieve 工具一起交给 LLM Provider。

多种接入姿势

项目提供了几种入口。最轻量的是 Python SDK，要求 Python 3.10+：

pip install headroom-ai

如果需要代理、MCP、ML 压缩或代码压缩等高级能力，可按需安装 extras：

Hermes Agent 本轮将全部 P0/P1 级别问题清零，同时把混合推理、可观察学习以及桌面项目管理三大能力提升为一等公民功能。这不再是简单的“又一个修复版本”，而是标志 Agent 从单一工具向可审计工程系统演进的节点。

692 项 P0/P1 全部关闭，剩余 0 项开放，贡献者超过 370 人。Hermes Agent 在 v0.18.0（代号 “The Judgment Release”）中完成了两层改变。运维层面，团队用十二天时间处理了 692 个最高优先级问题，其中包括 493 个 P1 和 3 个 P0，最后一个棘手的 interrupt-protected-compression 的 sibling-fork 缺陷由贡献者 @kshitijk4poor 持续护航并最终解决。产品层面，则是把此前隐藏在配置项和后台进程中的多项能力正式显式化为一等公民。

混合模型成为一等路由

过去若想串联多个模型进行推理，必须在 skill 中手工编写分发逻辑或借助 subagent 拼装。v0.18.0 将 Mixture-of-Agents 定义为命名集合，用户可以像选择普通模型一样直接启用；每个参考模型的推理过程完整展示，聚合结果支持实时流式输出。

实际使用表明，provider 层的最小单元不再是单一的 endpoint，而变成了“一组 endpoint + 聚合策略”。对于已经处理快慢模型串行任务的构建者，这次改动能让路由声明大幅简化；如果应用仅使用一个统一的 Provider，则此特性暂时不必跟进。

适用：多模型串行、快慢分离、需要中间推理留痕的 Builder
不适用：单 Provider、单模型、无需解释中间步骤的简单任务

/learn 与 Journey：摄取能力与可解释性的分层

/learn 命令使 Agent 能够从任意开放来源学习内容，不再局限于预设知识库或单次上传的文档。Journey 功能则将学习过程可视化，让使用者清晰地看到 Agent 读取了哪些来源、执行了哪些跳转，以及最终如何形成结论。

两项能力同时推出意义重大：/learn 解决“能否持续扩展知识”的问题，Journey 解决“扩展过程是否正确、是否可审计”的问题。如果仅部署 /learn 而缺少 Journey，Agent 容易变成黑箱式的记忆存储；如果仅有 Journey 而没有 /learn，可视化便退化为单纯的流程图绘制。

根据官方公布，Hermes Agent 在网络读取方面实现了最高60倍的速度提升和49倍的成本下降。但这并不是某一模型突然变快了，而是从“谁去抓取网页、抓取后如何存储、如何按需分页”这一整条浏览管线的架构级重构。换句话说，过去脏HTML会被直接丢给模型，现在则由专用抓取后端在进入模型之前就清洗出干净的正文，并将大页面本地缓存、按需切块。官方将这归功于“抓取后端向Agent传递纯净内容”和“大页面本地保存与分页”，这两个动作直接决定了速率与成本的倍率变化。

60倍速与49倍降本：数字背后的真实含义

Nous Research 在 X 平台上的帖子更像产品文案而非技术基准。真正发生改变的不是模型推理速度，而是整个管线的职责划分：谁负责处理网页、处理完后怎么缓存、何时再次处理。如果能把臃肿的HTML提前压缩成精准正文并分批送入模型，整体吞吐量就会飙升。因此，这本质上是一次 I/O 架构优化，而不是模型能力的跃升。将它包装成“Agent更聪明了”会误导用户以为只要换用模型就能复现，实际上复现条件是一整套后端基础设施，包括抓取节点池、本地缓存和分页策略。

真实用户体验：什么场景下提速最明显？

如果直接让 Hermes 读取一个 20MB 的电商列表页，旧流程很可能将整块未处理的 HTML 扔给模型，广告、导航栏和追踪脚本瞬间挤满上下文，最终要么得到错误答案，要么超时。新流程将抓取后端与模型解耦，大页面先写入本地存储，再按需切页，用户感受到的就是“同一个页面，更快更准了”。实际测试表明，对于新闻长文、博客这类单页主体明确的页面，提速最为显著；而对于依赖滚动、点击、登录后才能看到评论区内容的社交平台，效果取决于网站是否把核心内容藏在客户端渲染之后。如果内容被 JavaScript 延迟加载，管线再快也无能为力。这番改进本质是架构红利，绝非模型智慧的增长。

反爬机制解密：Hermes如何绕过网站封锁

服务器拦截自动化请求是常态，绝非例外。直接用 requests 加 User-Agent 去抓大多数主流网站，通常 5 秒内就会撞上 403 或 Cloudflare 验证码。Hermes 走的是托管抓取后端路线，其内置工具包提供了网页搜索、浏览器、视觉、TTS 等功能，用户无需自己维护浏览器实例或购买代理 IP，这些由 Nous Portal 统一运营。也就是说，绕过反爬的实际执行者是 Nous 的抓取节点池。好处是开箱即用，比自己搭配 Playwright、住宅代理和指纹浏览器更稳定；坏处是完全失去掌控——节点池被封、速率受限时，你只能等待官方修复，没有自愈能力。

Chrome插件抓取 vs Hermes托管节点：登录态是关键

如果你用过类似“打开社交网站信息流”的 Chrome 插件，原理是直接读取真实浏览器中的 Cookie 和登录凭证。社交平台看到一个真正的 Chrome 实例在访问页面，而不是一段 Python 脚本。这种方式比纯云端抓取更适合需要登录的站点，因为你的账号权限也被复用。代价是插件必须运行在你自己的机器或可控的浏览器环境里，无法移交第三方服务。而 Hermes 的浏览器工具运行在独立无头浏览器中，不会继承你的登录态，这层边界决定了它在需要登录的内容面前存在天然盲区。

合规与风险：不可绕过的法律边界

公开网页抓取一直游走在版权法、计算机欺诈与滥用法以及平台服务条款的三重边界。大量网站的 robots.txt 明确禁止自动化采集，部分司法管辖区将绕开技术保护措施视为违法。Hermes 的做法是把风险从用户端转移到服务端：Nous 自行运营节点池，承担被封 IP、站点拉黑等法律及运营成本。普通用户虽然无需亲自处理验证码，但这并不意味着操作天然合规。如果你用这套工具去读取付费墙内容、个人隐私页面，或进行明显违反站点条款的批量采集，责任仍然由你本人承担。从成本角度判断，这只是工具层面的速度提升，不是爬虫技术的实质性突破。若要在生产环境稳定访问数十个外部站点，不可把 Hermes 看作零配置方案；反过来，如果只是偶尔阅读公开长文、做研究汇总，它确实将抓取、清洗、分页打包成一条可用管道，减少了自行组装的成本。

适用性分析：谁该用，谁不该用

适合已经接受 SaaS 式网页抓取、需要将公开网页汇总给 Agent 做研究，并且不愿为验证码和 Cookie 维护操心的人。不适合需要细粒度控制抓取报头、代理 IP、指纹设置，对站点合规性高度敏感，或所访网站体量过大而导致批量 IP 封禁的团队。厘清这些边界，才能让 Hermes Agent 的优势真正为你所用，而不致踏入灰产雷区。

hermes-browser-extension 并不是一个浏览器聊天机器人，而是一个为 Chrome、Edge 等 Chromium 内核浏览器设计的侧边栏，它能将你本机或远程的 Hermes 运行时直接嵌入浏览器中。该扩展采用 MIT 协议开源，仓库地址为 GitHub / abundantbeing/hermes-browser-extension，默认连接 http://127.0.0.1:8642，当然你也可以指向任意远程主机。

解决的核心痛点：连接浏览器与 Hermes 运行时

许多 Hermes Agent 用户每天都要经历两段式工作流：在浏览器里查找资料、阅读文档、浏览页面，然后切回 Hermes 桌面端或终端，让 Agent 接着处理这些内容。如果一天要来回切换几十次，这种反复切窗的操作就成了一种无形的消耗。这个插件的设计目标正是把两条链路打通：当前正在浏览的页面、选中的文字、打开的标签页，都可以直接作为上下文输入到 Hermes 的对话中。

它是浏览器上下文与 Hermes 运行时之间的桥梁。插件本身只负责读取页面内容、将其打包成可发送的上下文，不承担任何页面模拟、点击、填表等浏览器自动操控行为。真正的模型能力、tools、skills、memory、MCP 仍然由本机或远程的 Hermes Gateway 提供。这样的设计保证了插件具有非常轻量的权限范围，而实际的能力边界依然由 Hermes 主程序决定。

安装后能获得哪些能力

▸ 页面实时对话 — 在侧边栏里直接跟 Hermes 交流，它会将当前页面、选中的内容以及打开的其他标签页组织成上下文。

▸ 模型一键切换 — 连接成功后，侧边栏会自动同步 Hermes 端配置好的 providers 和 models，你可以在侧边栏里自由切换，无需再打开桌面端或命令行。

▸ 页面视觉分析 + 截图 — 支持拖拽文件、粘贴图片、截图上传，让图像上下文也能直接进入 Hermes 会话。

▸ 支持本地与远程 Gateway — 无论是本机 127.0.0.1、同一个局域网内的主机，还是通过 HTTPS 反向代理暴露的远程 Hermes 服务，都可以接入。

想尝试目前性能最强的 Claude 4.7 Opus 模型，又不愿支付每月 20 美元的订阅费？这篇文章分享一个利用 Kiro Pro 新用户福利实现零成本体验的方法。

一、注册全新账户

打开 Kiro 登录页面：[https://app.kiro.dev/signin](https://app.kiro.dev/signin)。注意，此次活动仅对新注册用户开放。建议直接使用 GitHub 或 Google 账号一键关联完成注册。

老用户无法享受该福利，务必使用没有注册过 Kiro 的全新账号。

二、升级至 Pro 套餐

登录后进入套餐选择界面（Plans），点击 Kiro Pro 进行升级。页面上可能会显示 $20 的价格，这只是初始标价，真正的优惠会出现在支付确认页面。

三、确认 0 元账单

进入支付网关后，仔细核对最终支付金额。如果显示为 $0.00，说明已经获得免费试用资格。

• 支持的卡片：国内发行的 Visa 或 MasterCard 信用卡亲测可用。
• 账单地址：填写真实的国内账单地址通常也能顺利通过。
• 提示：支付完成后若未立即生效，不必重复支付，退出登录再重新进入即可。

四、立即取消自动续费

为了确保账户安全，避免订阅期满后被自动扣款，建议在订阅成功后立即取消下个月续费。这一操作不会影响当前月的 Pro 权益。

1. 进入账户用量页面：[https://app.kiro.dev/account/usage](https://app.kiro.dev/account/usage)
2. 点击 Manage Plan 按钮。
3. 选择降级为 Kiro Free 方案并点击 Confirm 确认。

完成以上步骤后，就可以安心使用一个月的 Pro 权限。

之后便能在 Kiro 界面中直接调用 Claude Opus 4.7 模型：

面向垂直 AI 智能体的 Rust 基座，先给结果，再展开运行时。Loong 已在树莓派 CM0 NANO 等低功耗设备上表现出色（感谢 Rusty 测试与记录）。

Loong 的设计初衷

Loong 旨在构建一套能够长期稳定运行、具备高扩展性与完整审计能力的 Agent 运行时底座。我们关注的并不仅是让模型调用工具，而是将工具、插件、外部系统以及运行状态统一纳入可控的治理链路——既可扩展，也可追溯，一旦出现问题能够快速还原。

当前多数 Agent 框架的瓶颈并非来自模型能力，而是运行时边界的模糊。当工具数量增多、插件自由度变大时，系统往往会产生难以解释的副作用。Loong 的做法是收紧核心路径，同时放开扩展能力：核心层负责契约、能力、策略与审计；扩展层则管理 provider、工具、通信渠道、记忆和插件。

我们的核心理念

Agent 运行时将逐渐趋近于一个小型操作系统。它需要调度工具调用、管理外部连接、控制权限、维护状态与历史，并集成观测、插件以及长任务。如果所有这些能力都塞进一个单一且不可拆分的主流程，短期或许可行，但长期维护极其困难。

因此，Loong 选择在早期就把运行时的边界构建清楚：模型可以调用工具，但工具并非裸露的入口；插件能够动态加入，但不可绕过策略与审计；外部系统可以接入，但每一次调用都必须留下可追溯的证据。这条路线虽然在初期会牺牲一些实现速度，但换来的却是更为稳定和有序的扩展空间。

工具与插件体系

Loong 的工具系统并非一张静态的工具列表，而是一套可治理的运行时表面。工具的可见性取决于当前的构建、配置、provider 能力以及策略边界。即便高风险工具向模型暴露，也必须保留审批、策略与审计环节。

插件系统则遵循「manifest 优先」的模式。插件必须先声明其身份、能力、入口点、兼容性、信任等级及运行方式，Loong 再据此决定是否能将其接入运行时。这样的好处在于，插件生态可以自由扩展，但核心系统不会沦为一个失控的动态脚本宿主。

目前，Loong 已支持 WASM 插件动态加载，WASM 在受限的 bridge 运行时中执行，通过清晰的 JSON ABI 与宿主交换数据。除 WASM 外，Loong 还提供了 HTTP JSON bridge 和 process stdio bridge（后者基于 JSON-line 帧），覆盖了实用的 IPC 场景。未来插件还将向更多 IPC 及外部运行时延伸。我们的方向不是将各种语言都硬塞进核心，而是为不同运行模式提供一致的接入入口：声明清晰、策略可控、运行证据完整、失败时易于诊断。

审计与追溯

审计（audit）是 Loong 的核心能力之一。系统中关键行为不应仅存在于临时日志中，而应归入结构化事件流。例如 token 发放与撤销、策略拒绝、工具调用、连接器调用、插件发现、插件信任评估、安全扫描等，都应能够回溯复盘。

当前运行时已实现持久的 JSONL 审计机制，默认将审计事件保存在本地历史中。运营者可以根据事件类型、时间窗口、token、agent、pack、信任等级等维度进行查询。我们的目标是使一次工具调用、一次插件加载或一条策略拒绝，都能回溯到同一条证据链上。这也正是 Loong 与普通工具调用框架之间的关键区别：普通框架更关心调用是否成功，Loong 则更在意调用为何被允许、在何种上下文下执行、结果如何、以及未来是否还能追溯。

原生的文件浏览器也就是访达（Finder），里面并不支持直接通过路径来访问文件。
具体来说，浏览文件或文件夹时看不到它们的完整绝对路径，也没法粘贴一条路径就快速跳转到目标位置。

虽然状态栏中会显示路径，但那串路径并不能直接复制。

有个常用的替代方法是按下 Cmd+Shift+G 来跳转到指定目录，或者在终端里用 open . 打开当前文件夹。

反过来，从文件获取绝对路径也很不方便，尤其是当你刚在访达里看过某个文件，转头就想去命令行里操作它的路径时。

右键菜单里提供了一组“服务”可以打开命令行：

如今自己动手做一个文件浏览器并不难，借助 Claude Code 很快就能搭出一个原型，效果如下：

工具里加入了跳转到命令行和访达的操作，同时支持一键复制文件路径。

制作这款小工具的提示词：

制作一个 Mac 系统下的文件浏览器，功能类似 Windows 的资源管理器。需要重点解决访达无法通过绝对路径访问文件或目录的问题，提供便捷的文件路径获取方式，方便在图形界面和命令行之间来回切换，并能在图形界面中快速定位文件或目录。

用 AI 写出来的工具，想怎么改就怎么改，一个窗口不顺手就换成两个、四个。

全文完。