gpt搭配pi agent时使用远程压缩的方法

文成宇 2026-07-21 22:56 1

因为gpt 5.6出来后感觉不需要太多提示词，所以尝试在pi agent中使用。

发现pi的compact不是openai原生的远程压缩，于是找了一下有没有相关的扩展。

尝试了一下@lll9p/pi-better-compaction这个扩展

执行pi install npm:@lll9p/pi-better-compaction安装

扩展有默认的配置参数，也可以自行创建配置文件，在macbook上是创建~/.pi/agent/extensions/pi-better-compaction/config.json

配置如下

{

  "enabled": true,

  "allowCompactionContinuityBreak": false,



  "compactionModel": "openai/gpt-5.6-sol",

  "compactionThinkingLevel": "off",



  "responsesCompactApis": ["openai-responses", "openai-codex-responses"],



  "notifyOnLoad": true,

  "debug": false,

  "logProviderPayloads": false,

  "logCompactResponses": false,

  "redactSensitiveData": true,

  "artifactRoot": "~/.pi/agent/artifacts/pi-better-compaction"

}

然后随便resume一个session，执行/compact

可以看到compact成功了

在sub2api上也能看到对应的请求

注

原生远程压缩有两种形式。

第一种为新版 /responses + context_management，codex使用该形式，所以在中转站上只能看到 /responses请求

第二种为旧版 /responses/compact，这是@lll9p/pi-better-compaction使用的形式

最新回复 (8)

iasi777 07-21 23:16

1楼

原生搜索工具可以调用吗，还有体验如何呢
qaq一个懒人 07-22 08:40

2楼

其他家有远程压缩吗，比如 grok 之类的
文成宇楼主 07-22 10:05

3楼

docs.x.ai

Context Compaction | SpaceXAI Docs

Shrink long conversations into an opaque compaction that can be reused in follow-up calls.

grok也有原生远程压缩
烽火聚诸侯 07-22 10:11

4楼

第一种为新版 /responses + context_management，codex使用该形式，所以在中转站上只能看到 /responses请求

【第一种为新版 /responses + context_management，codex使用该形式，所以在中转站上只能看到 /responses请求】佬，这个是codex目前正在用的远程压缩吗？
文成宇楼主 07-22 10:19

5楼

是的。如果不能确定是不是远程压缩的话，可以在codex上直接问有没有触发远端compact
文成宇楼主 07-22 10:22

6楼

github.com/earendil-works/pi

Add a `ServerTool` abstraction to the AI and Agent packages for provider-native tools

已打开 02:23AM - 03 Mar 26 UTC

已关闭 08:12AM - 03 Mar 26 UTC

juan-altatech

### What do you want to change?

Add a `ServerTool` abstraction to the AI and Ag…ent packages so provider-native tools (web search, code interpreter, etc.) can be requested, streamed, and replayed transparently across all supported providers.

### Why?

Native search is significantly faster and more reliable than client-side alternatives like curl or custom browser tools. Adding this abstraction will allow users to enable other provider-built-in tools like code interpreter as they become available.

### How? (optional)

1. Add `ServerTool`, `ServerToolResult`, and `ServerToolResultContent` types to the AI package, extending `AssistantMessage.content` and Context to carry server-side tool requests and inline results alongside regular content.
2. Implement provider-specific request building and stream parsing for Anthropic (web_search_20250305/server_tool_use/web_search_tool_result), OpenAI Responses (web_search_preview/web_search_call), OpenAI Completions (web_search_options +
url_citation annotations), and Google (googleSearch + groundingMetadata).
3. Update `transformMessages` to pass through `ServerToolResult` for same-model replay and convert to text with citations for cross-model, and fix orphaned tool call detection to exclude server-resolved IDs.
4. Update the agent loop to skip client-side execution for tool calls that already have a matching `ServerToolResult` in the same message, and plumb `serverTools` through `AgentContext`/`AgentState`/proxy.

github.com/earendil-works/pi

feat(ai): Add native web search support for Anthropic, OpenAI, xAI, Google

已打开 12:17AM - 14 Jan 26 UTC

已关闭 12:39AM - 14 Jan 26 UTC

nullswan

possibly-openclaw-clanker

Add native web search support for providers with server-managed tools.

| Provid…er | Tool | Cost |
|----------|------|------|
| Anthropic | `web_search_20250305` | $10/1k |
| OpenAI | `web_search_options` | per call |
| xAI/Grok | `web_search` | **FREE** |
| Google | `google_search` | $14/1k |

## What's needed

1. **Request**: Pass server-managed tools alongside regular tools
2. **Response**: Handle new content blocks (`server_tool_use`, `web_search_tool_result`, `annotations`)
3. **Citations**: Expose citation data (url, title, cited_text)

<details>
<summary>Proposed StreamOptions extension</summary>

```typescript
interface StreamOptions {
webSearch?: {
enabled?: boolean;
maxUses?: number;
allowedDomains?: string[];
blockedDomains?: string[];
userLocation?: { city?: string; country?: string; timezone?: string };
};
}
```
</details>

<details>
<summary>Provider-specific formats</summary>

**Anthropic** — [docs](https://platform.claude.com/docs/en/agents-and-tools/tool-use/web-search-tool)
```json
{ "type": "web_search_20250305", "name": "web_search", "max_uses": 5 }
```
Response blocks: `server_tool_use`, `web_search_tool_result`

**OpenAI** — [docs](https://platform.openai.com/docs/guides/tools-web-search)
```typescript
web_search_options: { user_location: { type: "approximate", approximate: { country: "US" } } }
```
Response: `annotations` array with `url_citation`

**xAI** — [docs](https://docs.x.ai/docs/guides/tools/search-tools)
```json
{ "type": "web_search" }
```
Response: `citations` array

**Google** — [docs](https://ai.google.dev/gemini-api/docs/google-search)
```python
tools=[{"google_search": {}}]
```
Response: `groundingMetadata`
</details>

Related: clawdbot/clawdbot#877

社区讨论过多次，但是作者不愿做，大概是因为各个模型没有统一的接口
烽火聚诸侯 07-22 10:54

7楼

概是因为各个模型没有统一的接口

佬，所以我其实是不是可以理解，任何其他ai，比如deepseek等等都可以利用codex的这个远程压缩来进行长上下文压缩？
文成宇楼主 07-22 11:07

8楼

不可行。openai文档中写的The response stream includes the encrypted compaction item.，也就是远程压缩后的response是加密的，只有openai模型能解析，其他模型应该解析不了

* 帖子来源Linux.do

附近帖子

飞读

文成宇

主题数
1

帖子数
1

注册排名
3

随机推荐