Question 1

如何修复 Bedrock Claude 5 提示缓存不发送 cachePoint 块、并且将每个请求都按全新输入计费的问题？

Accepted Answer

这是 prime-agent `packages/ai` 0.7.x 以及 `main` 分支在 commit `9fb6cde` 处 `packages/ai/src/providers/amazon-bedrock.ts` 中的一个 bug。`supportsPromptCaching()` 仅为包含 `-4-`、`claude-3-7-sonnet` 或 `claude-3-5-haiku` 的模型 ID 启用缓存，因此诸如 `claude-fable-5-1`、`claude-opus-5-5` 和 `claude-sonnet-5` 之类的 Claude 5 ID 会静默省略 `cachePoint` 块。设置 `AWS_BEDROCK_FORCE_CACHE=1` 不起作用，因为该函数在检查该环境变量之前就已从 Claude 模型分支返回。应用上游修复，或为该函数打补丁以识别 Claude 5+ 模型：在现有的 `-4-` 和旧版 Claude 检查旁边添加 `if (candidates.some((s) => /claude-(?:fable|opus|sonnet|haiku)-(?:[5-9]|\d{2,})(?:-|$)/.test(s))) return true;`。更安全的长期修复方案是假设所有 Claude 模型都支持缓存，仅列出一个简短的 3.7 之前模型的拒绝列表。重新构建并重新部署 `packages/ai` 包，然后使用相同的前缀连续发起两次 `ConverseStream` 调用。第二个响应应报告 `cacheReadInputTokens > 0`；在 `us.anthropic.claude-fable-5-1` 上的测试返回了 `cacheReadInputTokens: 21829`。监控缓存读取 token 数与全新输入 token 数的对比，以确认缓存已激活。

Question 2

如何修复由格式错误的非 ASCII CSI 转义序列引起的 pa-tui panic "byte index is not a char boundary"？

Accepted Answer

发生 panic 是因为 `decode_csi_with_modifier` 向 `str::split_at` 传递了 Unicode 字符数，而该方法要求的是 UTF-8 字节偏移量。对于输入（如 `\x1b[;éA`）中的多字节字符（如 `é`），计算出的偏移量可能会落在该字符的内部。

在 `crates/pa-tui/src/input.rs` 中，将：

```rust
let (modifier, final_char) = last.split_at(last.chars().count() - 1);
```

替换为从 `char_indices` 派生的字节边界：

```rust
let final_index = last
    .char_indices()
    .next_back()
    .map_or(0, |(index, _)| index);
let (modifier, final_char) = last.split_at(final_index);
```

这样会在最后一个 UTF-8 字符的起始位置进行分割。随后，现有的 `modifier.parse::<u8>()` 会正常拒绝格式错误的前缀，而不会导致 TUI 崩溃。请使用包含 issue #3175 修复的构建版本；在此之前，请避免向终端发送格式错误的非 ASCII CSI 序列。

Question 3

如何防止 dill 快照恢复在内核重启后将写入模式的文件截断为零字节?

Accepted Answer

失败的原因是 dill 0.4.1 会将文件对象（包括已关闭的句柄）序列化为 `_create_filehandle(name, mode)`。当 `_restore_state` 调用 `dill.loads()` 时，dill 会重新打开保存的路径。如果保存的模式为 `"w"`，重新打开时会使用 `O_TRUNC`，在任何加载后检查来得及关闭句柄之前，就静默地将文件清空。

临时解决方案：

1. 不要在 kernel 命名空间中遗留 `with open(...) as f` 变量。在代码块结束后将其删除：
```python
with open("/path/file.md", "w") as f:
    f.write(data)
del f
```

2. 在重启之前，从命名空间中移除所有文件对象：
```python
import io
for name, value in list(globals().items()):
    if isinstance(value, io.IOBase):
        try:
            value.close()
        except Exception:
            pass
        del globals()[name]
```

3. 必须在 `dill.loads()` 运行之前，丢弃或剥离包含 dill `_create_filehandle` 的现有快照记录。加载后再检查对象已经为时过晚，因为文件在反序列化期间就已经被截断。

在 `prime-agent-runtime/src/rlm/repl.py` 的 `_snapshot_state`（约第 714 行）中进行永久修复：
```python
import io

if isinstance(value, io.IOBase):
    skipped.append({"name": name, "reason": "file handle"})
    continue
```

同时，在反序列化之前，在 `_read_snapshot_records` 中剥离遗留的 `_create_filehandle` 记录。`_restore_state` 中的加载后文件对象检查只是纵深防御性质的清理措施，无法阻止最初的 `O_TRUNC`。如有可用版本，请升级到包含 v0.1.21 恢复安全性修复的版本，并从备份中恢复受影响的文件。

Question 4

为什么即使模型响应在 max_tokens 处被截断，ACP session/prompt 仍返回 end_turn？

Accepted Answer

这是 prime-agent 的 ACP stop-reason 映射中的一个 bug:它只考虑取消标志和自主 token 预算状态,因此带有 `finish_reason: "length"` 的最后一次模型调用会被错误地报告为 `stopReason: "end_turn"`。请升级到包含修复 `acp: report max_tokens when the final model response was truncated` 的版本。如果从源码构建,请更新 `crates/pa-daemon/src/acp/meta.rs` 中的 `acp_stop_reason_for_status` 以及 `acp-stop-reason.ts` 中的 TypeScript `acpStopReason` 映射,使最终助手消息的 `stopReason: "length"` 映射为 ACP 的 `stopReason: "max_tokens"`。作为变通方法,可以检查每次调用的模型跟踪记录,将 `finish_reason=length` 或输出 token 数等于 token 上限的情况视为截断。

Question 5

为什么在 oMLX / OpenAI 兼容的本地模型上，自动压缩会失败并提示 "Prompt is too long: N tokens > M maximum context length" 错误？

Accepted Answer

溢出检测器 `is_context_overflow`(`crates/pa-ai/src/utils_inner/overflow.rs`)无法识别 oMLX 的 400 错误消息,因此不会触发压缩(compaction)、尾部 assistant 消息丢弃或重试,会话中后续的每个提示都会以完全相同的方式失败。这是由两个正则表达式缺口造成的:(1)`prompt is too long` 模式区分大小写,而 oMLX 将 "Prompt" 首字母大写;(2)`maximum context length is \d+ tokens` 模式所期望的语序与 oMLX 的 `N tokens > M maximum context length` 不同。修复方法:将该模式改为 `(?i)prompt is too long`,和/或新增一个模式 `(?i)tokens > \d+ maximum context length`。在补丁发布前的临时解决办法:当将会话切换到上下文窗口更小的模型时(例如从大型 OpenRouter 模型切换到 262k 本地模型),请在溢出发生之前手动运行压缩或开启一个新会话。

prime-agent

项目简介

README 预览

常见问题 (5)

同类型项目

hermes-agent

firecrawl

go

markitdown