bigfish的网络博客 - Agent

Jev 到底是什么？一个不聊天、只做判断的模型

bigfish — Wed, 14 Oct 2026 23:12:00 +0800

设想你开了一家店，门口装了闸机。你请来一位文笔极好的编剧，专门负责一件事：判断这个人能不能进店。

每次有人走近，他都认真地写下一段话：

这位顾客穿着整洁，神情平静，手里提的东西大概率不是危险物品。综合判断，我认为可以进店。

你读完，点点头，然后自己伸手按下了开门键。

问题不在于他判断得对不对，而在于——你原本只想要一个「开」或「不开」，他却交给你一段还要你再读一遍、再理解一次的叙述。

在软件里，大语言模型经常就站在这个位置。它很会写、很会解释，但程序真正需要的往往只是一个判断：这笔工单要不要升级？这条评论要不要拦？这个订单要不要转人工？让模型写一段自然语言，程序还得反过来解析、校验，再猜这句话到底是什么意思。

Jev 就是冲着这个问题来的。

TypeSafe AI 把 Jev 称为第一款公开的 System One Model：它不面向人聊天，而面向软件内部的决策。程序给它一段状态和一个结构化的问题，它返回程序可以直接接着处理的类型化结果、概率分布和置信度。

这也是 Jev 最容易被误解的地方：它不是「一个更小的 LLM」，也不是给普通 LLM 的回答套一层 JSON。它改变的是模型在软件系统里的位置。

本文依据 TypeSafe AI 的公开介绍和目前可见的接口资料，回答四个问题：Jev 的输入输出是什么？它和传统分类模型有什么区别？它和 LLM 的结构化输出、ReAct 又差在哪里？以及什么场景适合用它。

说明：Jev 的架构、权重和完整训练细节尚未公开。下面把厂商的公开定位、接口行为和工程推断分开写，不把宣传页上的性能数字当作独立评测结果。

rpi-acp 源码解读：以 Zed 为例，一个 ACP Client 如何启动并驱动 rpi Agent

bigfish — Wed, 14 Oct 2026 00:04:00 +0800

在 rpi-package 的 rpi-acp 中，ACP 指的是 Agent Client Protocol。这个 package 的实际用途很具体：让 Zed 这样的 ACP Client 通过标准输入输出启动 rpi，并把 rpi 当作一个可以发送 prompt、接收流式更新和处理权限请求的外部 Agent。

本文以 Zed 作为具体客户端，因为仓库提供了完整的 Zed 注册、配置和排错路径；但 rpi-acp 并不是 Zed 专用实现。只要其他客户端支持 ACP v1、JSON-RPC 2.0 和 stdio，并能处理本文介绍的会话与更新方法，同样可以通过 rpi-acp-bridge 启动 rpi。

本文对应 rpi-packages 中的 rpi-acp 0.1.3，主要源码如下：

packages/rpi-acp/
├── src/lib.rs       插件生命周期、ownsStdio、启动服务
├── src/main.rs      独立 rpi-acp-bridge 二进制
├── src/protocol.rs  ACP v1 JSON-RPC 服务与请求分发
├── src/session.rs   每个 ACP session 对应的 rpi RPC 子进程
├── src/history.rs   session 历史保存与回放
└── src/zed.rs       Zed settings.json 注册

源码仓库：https://github.com/pi-rust/rpi-package/tree/master/packages/rpi-acp

rpi-mcp-adapter 源码解读：一个 Rust MCP 适配器如何管理工具调用

bigfish — Wed, 14 Oct 2026 00:04:00 +0800

很多 MCP 文章讲的是“Host、Client、Server”三个概念，但真正接入一个 MCP Server 时，代码要处理的事情远不止发一条 JSON-RPC：配置如何解析？本地进程如何启动？远程 HTTP 会话如何保存？超时后能不能安全退出？工具列表变化后是否重新发现？

这篇文章不再从 MCP 规范泛讲，而是直接阅读 rpi-mcp-adapter 的代码，回答一个具体问题：rpi 是如何把外部 MCP Server 接进自己的工具循环的？

本文对应 rpi-packages 中的 rpi-mcp-adapter 0.2.1，源码范围主要是：

packages/rpi-mcp-adapter/
├── src/lib.rs          插件入口和三个宿主工具
├── src/config.rs       mcpServers 配置解析
├── src/connection.rs   MCP 初始化与 tools 请求构造
├── src/runtime.rs      连接缓存、发现、调用和关闭
├── src/transport.rs    stdio 子进程传输
└── src/http.rs         Streamable HTTP 传输

源码仓库：https://github.com/pi-rust/rpi-package/tree/master/packages/rpi-mcp-adapter

如果你想拥有自己的 Agent，为什么值得从 rpi 开始

bigfish — Mon, 12 Oct 2026 23:30:00 +0800

如果你只是想找一个好用的 coding agent，直接安装一个现成产品通常是最省事的选择。

但如果你要把 Agent 放进自己的产品、服务或开发工具里，问题就变了：你需要的可能不是一个只能通过命令行使用的工具，而是一套自己能够拥有和控制的 Agent runtime。

这正是 rpi 的定位。

OpenAI 协议和 Anthropic 协议到底差在哪里？从一条请求走到工具调用

bigfish — Sun, 11 Oct 2026 18:26:29 +0800

你把模型供应商从 OpenAI 换成 Anthropic，最初通常只改一个 base_url 和一个 model。真正接入工具调用、流式输出和多模态之后，问题就出现了：同样叫 messages 的字段，为什么内容结构不一样？OpenAI 返回 tool_calls，Anthropic 返回 tool_use，它们能不能直接互换？

答案是：它们解决的是同一个问题，但不是同一个协议。 本文真正比较的主线，是 OpenAI Responses API、OpenAI Chat Completions 和 Anthropic Messages API；这里的“OpenAI 协议”不是一套统一标准。Embeddings 只在后文作为向量接口边界说明，不参与工具调用闭环。

更准确地说，OpenAI 和 Anthropic 都提供了基于 HTTP、JSON 和流式事件的模型 API；社区常说的“OpenAI 协议”“Anthropic 协议”，通常是对各自 API 请求、响应和事件约定的简称，而不是一个由双方共同维护的网络标准。

本文用一条任务贯穿对比：

用户问：“帮我查询北京今天的天气，如果需要调用天气工具就调用它，然后给我一句简短建议。”

文章不只比较 OpenAI Responses API 和 Anthropic Messages API。OpenAI 至少要分清三类接口：Responses、Chat Completions 和 Embeddings。本文按新项目优先使用 Responses 来组织示例；Chat Completions 主要用于维护已有代码、兼容现有网关，或明确依赖其 messages / choices 结构的场景。Embeddings 则负责把文本转换成向量，不能因为它们都使用 JSON 就把它们当成同一种“聊天协议”。

本文的主线仍然是一次工具调用，但会以 OpenAI Responses 与 Anthropic Messages 为主对照，再解释 Chat Completions 的兼容差异和 Embeddings 的独立边界。OpenAI Responses API 使用自己的 input、output item、response event 和工具模型，不能把 Chat Completions 的字段机械套过去。官方入口：

OpenAI Responses：https://platform.openai.com/docs/api-reference/responses
OpenAI Chat Completions：https://platform.openai.com/docs/api-reference/chat
OpenAI Embeddings：https://platform.openai.com/docs/api-reference/embeddings
Anthropic Messages：https://docs.anthropic.com/en/api/messages

rpi 这些扩展到底怎么选？一张工具地图看懂 16 个 Rust 插件

bigfish — Sun, 11 Oct 2026 09:03:00 +0800

rpi 已经有一批常见的原生 Rust 插件。数量上还没有成熟生态那么多，但任务规划、代码分析、网络访问、运行观测、消息渠道和语音交互等日常场景，基本都已经有对应能力可以使用。

如果只看包名，rpi-packages 很容易变成一张“功能名词表”：todo、goal、lens、MCP、Langfuse、voice……每个词都认识，真正要装哪个却不容易判断。

这篇文章先把目前已有的扩展整体展示出来，再按使用场景说明它们分别解决什么问题。你可以把它当成一张选型地图：先从任务找到需要的能力，再决定安装哪些包，而不是把整个扩展目录全部装上。后续如果你正在使用其他原生 Rust 插件，也欢迎补充。

我用 100 行核心代码，做了一个能接入飞书的 Hermes 式智能体

bigfish — Thu, 08 Oct 2026 00:00:00 +0000

很多人看到 Hermes Agent 的体验，第一反应是：

我也要把自己的 Agent 接进飞书。

然后就开始设计 Webhook、消息签名、事件回调、会话表、流式输出和重试队列。还没让 Agent 回第一句话，网关已经先写了一半。

其实，最简单的方式不是再造一个飞书机器人服务，而是直接让 rpi 接管这条长连接。

rpi 的 rpi-im-message 扩展已经把飞书接入层包起来：飞书消息通过官方 Rust SDK 的 WebSocket 长连接进入 rpi，rpi 负责调用 Agent，模型的最终回复再发回原来的会话。你需要配置飞书应用和模型，不需要从零实现一套消息网关。

这篇文章会分成两层：先用约 100 行代码把 Hermes 式 Agent 的核心循环讲清楚，再告诉你真正接入飞书时为什么不必自己写网关。代码用来理解原理，扩展用来减少接入成本。

【RPI源码拆解】Agent 源码看不懂？先跟着一条消息走一遍

bigfish — Tue, 06 Oct 2026 21:47:09 +0800

你在编码 Agent 里输入“读一下配置文件，告诉我超时时间是多少”，按下 Enter。过了一会儿，它打开文件，把结果告诉你。

看起来只是一次问答。但谁把文字交给模型？文件是谁读的？工具读完以后，模型又怎么知道文件内容？

读 Agent 源码最容易卡在这里：函数一个个都认识，连起来却不知道消息走到了哪一步。有些函数叫 prompt_text，有些叫 run_core，还有一个叫 run_agent_loop。到底哪一个真的请求了模型？

先不背名字。我们就拿上面这条消息做例子，跟着它从输入框走到模型，再从工具返回到界面。这个例子用于解释流程，不是一次实测记录。

Pi 的 Rust 实现来了：rpi，不止一个终端 Agent

bigfish — Thu, 01 Oct 2026 23:11:04 +0800

如果你熟悉 Pi，rpi 可以理解为它的 Rust 实现：同样能在终端里读文件、改代码、执行命令，也能作为库嵌入自己的程序。

rpi 用 Rust 重新实现 Pi SDK，并在这套运行时之上提供终端 CLI 和原生扩展。 想直接使用编码助手，可以安装后运行；想构建自己的 Agent，则可以选择需要的模型接入、工具循环和会话管理组件。