v3.5.0 — 全系列模型感知 max_tokens + prompt caching + thinking 参数清理

新特性

• 模型感知 max_tokens — Anthropic / OpenAI / Gemini 三个 provider 均按模型动态设置输出上限，不再一刀切 115000

  • Claude 4.6 Opus → 32K, Sonnet → 16K, Haiku → 8K; thinking 模式自动加大 budget
  • OpenAI o1/o3/o4 → 100K, GPT-4o → 16K, DeepSeek/GLM/Kimi/Qwen/Mistral/Llama 等全覆盖
  • Gemini 2.5/3 Pro → 65536, Flash → 32768

• Anthropic prompt caching — 原生 Anthropic provider 也注入 cache_control，不再仅限 MiniMax

• Thinking 模式参数清理 — 启用 thinking 时自动 strip temperature/top_p/top_k（Anthropic API 要求），DeepSeek reasoner 同理

• 上下文窗口全覆盖 — getModelContextLimit() 扩充至 Kimi/Qwen/Mistral/Llama/Yi/GLM-4-Long 等模型系列

模型覆盖

Provider	模型	max_tokens	上下文窗口
Anthropic	Claude Opus 4.6	32,000	200K
Anthropic	Claude Sonnet 4.5/4.6	16,384	200K
Anthropic	Claude Haiku 4.5	8,192	200K
OpenAI	o1/o3/o4	100,000	200K
OpenAI	GPT-4o	16,384	128K
OpenAI	GPT-4.1	32,768	~1M
OpenAI	DeepSeek R1	16,384	128K
OpenAI	Qwen3	16,384	128K
OpenAI	Kimi K2	16,384	128K
Google	Gemini 3/2.5 Pro	65,536	1M
Google	Gemini 3/2.5 Flash	32,768	1M

v3.4.1 — GLM tool calling 多轮回放修复

GLM coding 端点不支持标准 OpenAI tool calling 多轮回放格式，continuation 时稳定 400。

• GLM 历史消息折叠：assistant(tool_calls) + tool(results) → 纯文本 assistant + user 消息对
• GLM 工具循环内部同步折叠：拦截工具回传也用纯文本格式
• reasoning_content 只对 DeepSeek/Kimi 注入，GLM/OpenAI 跳过
• 添加 [GLM-DEBUG] 诊断日志

v3.4.0 — Agent 工具系统进化

Agent 工具系统进化

参考 Claude Code Tool<Input,Output> 类型系统架构，将代理插件从 API 转发+工具拦截器进化为完整的 Agent 执行引擎。

🏗️ 架构重构

• Tool 泛型接口 + buildTool() 工厂模式，fail-closed 安全默认值
• ToolRegistry 注册表，统一工具查找/分发/并发分区执行
• 将 tools.ts 中 1427 行 if/else 链拆分为 7 个独立工具模块
• Patch 解析器、路径修正、参数修正提取为 shared/ 可复用模块

🔧 5 个新增 Agent 工具

• bash — Shell 命令执行（120s 超时，10MB 输出缓冲）
• glob — 文件模式搜索（**/*.ts、src/**/*.js）
• grep — 内容搜索（优先 ripgrep，fallback grep）
• file_read — 增强文件读取（行号标注、行范围选择）
• list_directory — 目录列表（文件类型 + 大小标注）

⚡ 三 Provider 统一拦截

• Anthropic / OpenAI / Google 三路转发均集成 ToolRegistry 异步拦截
• 新工具 JSON Schema 自动注入三种格式的 tool_definitions
• 只读工具自动并行执行，写入工具严格串行

📊 统计

• 20 个新文件，1625 行新代码
• 6 个修改文件，486 行变更
• tsc --noEmit 零错误

v3.3.5

Augment Proxy Manager v3.3.5 - Kimi 工具链闭环与标准 API reasoning 修复

核心结论

v3.3.5 集中修 Kimi / Moonshot 相关的两条主链：

• Kimi standard API (https://api.moonshot.cn/v1/chat/completions) continuation 历史回放缺失 reasoning_content
• Kimi Coding Anthropic 兼容链上的 tool_call_id / tool_result / thinking 回放不完整

本次修复

1. Standard API reasoning_content 补齐

• assistant + tool_calls 历史消息现在会从 <think>...</think> 中拆出 reasoning_content
• replay assistant tool call 消息时，若只有 reasoning 无正文，会发送 content: null
• 修复 Moonshot/Kimi continuation 第二轮因缺失 reasoning_content 返回 400 invalid_request_error

2. Kimi Coding / Anthropic 工具链闭环

• tool_result 兼容读取 tool_call_id / tool_use_id / id
• tool_result 补带 tool_name
• 增加 tool turn adjacency stabilize，降低 tool_use / tool_result 错位
• 保留带工具调用的空 assistant turn，避免误删合法历史

3. Thinking 历史回放

• kimi-anthropic 历史中的 <think>...</think> 会回放为 Anthropic thinking
• 若存在 thought_signature，会一并回放到 signature

验证结果

• npm run compile 通过
• 针对 splitReasoningContentFromText() 的 smoke 通过
• augmentToOpenAIMessages() / augmentToAnthropicMessages() 的工具链历史重建 smoke 通过

已知问题

• api.kimi.com/coding/v1/messages 需要有效的 Kimi Coding subscription；无效或过期 key 会返回 401 authentication_error
• 标准 API 可能返回 429 engine_overloaded_error；这表示请求结构已通过校验，但上游引擎过载

v3.3.4

Augment Proxy Manager v3.3.4 - Continuity 修复与协议状态承接

核心结论

v3.3.4 的改动集中在代理层的 continuation handling、history projection、state endpoint compatibility 和 per-conversation serialization：

• continuation "..." 仅作为 continuation signal 处理，不再改写用户消息内容
• 原始 chat_history 保留，压缩结果单独写入 compressed_chat_history
• save-chat、record-*、context-canvas/list 新增最小状态写入与读取逻辑
• 同一 conversation_id 的请求通过 state.conversationQueues 串行化处理

本次修复

1. Continuity 主链修复

• continuation "..." 按 continuation signal 处理，不再通过 prompt 改写参与消息编译
• 原始 chat_history 保留为会话原始记录
• 压缩结果单独写入 compressed_chat_history
• provider 统一从 canonical / normalized timeline 编译消息

2. 状态端点最小实现

以下端点已从固定成功响应调整为最小状态实现：

• /save-chat
• /record-session-events
• /record-user-events
• /record-request-events
• /context-canvas/list
• /generate-conversation-title
• /notifications/mark-read（兼容处理）

代理层新增以下内存状态容器，用于保存最小会话状态：

• conversationStates
• canvasStates
• sessionEventStore
• userEventStore
• requestEventStore

3. 会话级请求串行化

• 请求队列统一挂到全局 state.conversationQueues
• 同一 conversation_id 的请求按顺序执行，避免并发交错影响工具调用链

验证结果

已完成本地 runtime smoke：

• save-chat
• record-session-events
• record-user-events
• record-request-events
• context-canvas/list
• generate-conversation-title

以上端点均返回与会话状态相关的结构化结果，而不是固定 success: true 响应。

v3.1.4 — Agent 循环修复 + 任务系统生效

🔴 致命修复

Agent 执行一次操作后就停止

Anthropic/OpenAI provider 的 stop_reason 判断逻辑错误：当 AI 返回工具调用（如 view 读文件）时，因 stopReason === 'end_turn' 被错误判定为对话结束，导致后续任务永远不会执行。

修复: 只检查 toolCalls.length === 0，与 Google provider 保持一致。

任务列表工具不生效

view_tasklist、update_tasks、add_tasks、reorganize_tasklist 四个工具只有 system prompt 文字描述，缺少 JSON Schema 工具定义注入。AI 模型在 API 的 tools 参数中看不到这些工具，无法可靠调用。

修复: 三个 provider 均注入完整 schema。

Viking L0 上下文注入无效

proxy.ts 将 Viking L0 写入 augmentReq.system_prompt，但 buildSystemPrompt() 从不读取该字段，导致上下文被静默丢弃。

修复: buildSystemPrompt 开头合并 req.system_prompt。

---

Full Changelog: v3.1.3...v3.1.4

v3.1.3 - 完整支持自定义 API 端点

Augment Proxy Manager 3.1.3 发布说明

🎉 重大更新：完整支持自定义 API 端点

本版本实现了对自定义 Anthropic 格式 API 端点的完整支持，包括 HTTP/HTTPS 协议、标准 SSE 流式响应解析，以及上下文压缩优化。

---

✨ 新增功能

1. 自定义 API 端点支持

• ✅ 支持 HTTP 和 HTTPS 协议
• ✅ 正确处理完整的 URL 路径（pathname + search）
• ✅ 自动添加 Content-Length 头
• ✅ 支持 Anthropic、OpenAI、Google 三种 API 格式

2. 完整的 SSE 流式响应解析

• ✅ 支持标准 SSE 格式（event: 和 data: 行）
• ✅ 处理所有 Anthropic 事件类型：
  • message_start - 消息开始
  • message_stop - 消息结束
  • message_delta - 消息元数据更新
  • content_block_start - 内容块开始
  • content_block_delta - 内容增量（text/tool/thinking）
  • content_block_stop - 内容块结束
  • ping - 心跳事件

3. 智能上下文压缩优化

• ✅ 降低压缩触发阈值：80% → 60%
• ✅ 新增预压缩机制：在 50% 使用率时主动触发
• ✅ 降低目标使用率：40% → 30%
• ✅ 提升 Token 余量：~20% → ~40% (⬆️ 100%)

4. 流式响应性能提升

• ✅ 禁用 HTTP 缓冲，实现真正的实时流式输出
• ✅ 添加心跳保活机制（30秒间隔），防止连接超时
• ✅ 立即刷新缓冲区，消除延迟
• ✅ 流式延迟：2-5s → <100ms (⬇️ 95%)

5. 工具拦截增强

• ✅ 工具结果大小限制：50KB
• ✅ 过大结果自动截断，避免响应超时
• ✅ 改进错误处理和日志记录

6. 资源管理优化

• ✅ 心跳定时器自动清理
• ✅ 防止内存泄漏
• ✅ 优化连接生命周期管理

v3.1.2 — 修复 HTTP 接口 SSL 错误

修复

• 修复 HTTP 接口 SSL WRONG_VERSION_NUMBER 错误：anthropic.ts 和 openai.ts 硬编码 https.request()，当 baseUrl 使用 http:// 协议时 TLS 握手失败。现在根据 URL 协议自动选择 http/https 模块，与 embeddings.ts 行为一致。

v3.1.1 — Windows 兼容性修复

🪟 Windows 平台兼容性修复

修复内容

1. proxy.localhost DNS 解析失败 (ENOTFOUND)

Windows 不支持 *.localhost 子域名 DNS 解析（仅支持 localhost），导致 Augment 扩展无法连接代理服务器，进入无限重试循环。

• 修复前: http://proxy.localhost:8765 → Windows ENOTFOUND 错误
• 修复后: http://127.0.0.1:8765 → 全平台通用，跳过 DNS 解析
• 影响: macOS/Linux 用户无影响，Windows 用户从 v3.1.0 升级后自动修复

2. ONNX Runtime native DLL 加载失败

Windows 上 onnxruntime-node 的 native binding (onnxruntime_binding.node) 可能因缺少 Visual C++ Redistributable 或 Node ABI 版本不匹配而加载失败，导致本地 Embedding 模型无法使用。

==部分情况也可以手动安装Sharp解决此问题==
npm installforce @img/sharp-win32-x64

• 修复前: DLL 初始化失败 → 直接回退 BM25 纯文本搜索
• 修复后: DLL 失败 → 自动用 WASM backend (device: 'wasm') 重试 → 成功则用 WASM 跑推理
• 性能: WASM backend 比 native 慢约 20-30%，但确保功能可用
• 日志: [RAG] 🧠 Semantic engine ready: MiniLM-L6 (384d, WASM) 表示使用 WASM backend

技术细节

文件	改动
src/proxy.ts:624	proxy.localhost → 127.0.0.1
src/rag/embeddings.ts:loadLocalModel()	新增 _wasmFallback 参数，检测 DLL 失败后用 device: 'wasm' 重试

升级说明

从 v3.1.0 升级的用户：

• 首次启动代理时，alreadyConfigured 检查会检测到 URL 变化（proxy.localhost → 127.0.0.1）
• 自动重写 augment.advanced.completionURL 配置并触发窗口重载
• 无需手动操作，自动修复

📦 安装

下载 augment-proxy-manager-3.1.1.vsix 后在 VS Code 中安装：

扩展 → ⋯ → 从 VSIX 安装

v3.1.0 — 文件编辑引擎重构 + Diff 渲染 + OpenViking 上下文增强

🔧 文件编辑引擎重构（核心改进）

• 修复文件编辑终止 bug — AI 调用 apply_patch / str-replace-editor / save-file 后不再直接断开连接，工具执行结果正确回传给 AI 继续生成
• 三 Provider 循环架构 — OpenAI / Anthropic / Google 三个 Provider 全部重构为循环模式：拦截工具 → 本地执行 → 结果回传 AI → 继续生成，最多 25 轮迭代
• 强制精确编辑 — save-file 对已有文件直接拒绝（REJECTED），强制 AI 使用 str-replace-editor / apply_patch 做精确编辑，杜绝全量覆盖浪费 token
• 新文件本地创建 — save-file 对新文件直接本地执行（含递归建目录），apply_patch 的 Create File 子操作也正确执行
• 系统提示词注入 — 自动注入文件编辑规则块，从提示词层面引导 AI 使用正确的编辑工具

📊 Diff 渲染（流式输出）

拦截的文件编辑操作在聊天中实时渲染 diff，而不是只显示 ✅ apply_patch：

• 行级 diff（≤50 行）：显示删除行 / 新增行，最多各展示 12 行
• 大文件覆盖（>50 行）：显示行数变化摘要
• 新建文件：显示前 15 行预览
• renderDiffText() 统一渲染函数，三个 Provider 共用

🔍 OpenViking 上下文增强

借鉴 OpenViking 文件系统范式：

• Viking 分层上下文 — L0 摘要 (~100 tokens) / L1 结构化 (~2K tokens) / L2 全文，三级按需加载
• 目录聚合 + 递归下钻 — 向量初筛 → 目录级聚合 → Top 目录递归下钻 → 结果合并加权
• 用结构化文件系统信号弥补向量精度不足，对弱模型（GLM-5 等）的代码理解能力提升尤为显著

📦 安装

下载 augment-proxy-manager-3.1.0.vsix 后在 VS Code 中安装：

扩展 → ⋯ → 从 VSIX 安装