企业官网建设流程全解析

• AI Agent
• 人工智能
• 代码智能体
• 交互助手

本篇文章围绕 OpenChamber 1.13.3 版本（发布日期：2026-06-24）的变更清单展开，核心主题是 Git 身份支持使用 SSH 密钥签署提交、Agent 设置新增 thinking variant / temperature / top-p 采样控制，以及应用端与 VS Code 扩展端共享的一批聊天、会话、设置与移动端体验修复。阅读本文后，你将理解 SSH 提交签名在仓库中的底层配置实现，掌握 Agent 采样参数的作用与清除覆盖的行为，并能对照源码定位每一项修复背后的改动位置。

版本概览

OpenChamber 是基于 OpenCode AI agent 的 Agentic 开发环境。1.13.3 是一个以 Git 提交签名与 Agent 采样控制为核心的功能型版本，同时修复了大量影响日常使用的细节问题。本次变更同时落在两个端上：

• App：桌面 / Web 应用，涵盖 Git、Agent、Settings、Sessions、Chat、Providers、Usage、Files、Startup、CLI、Mobile 等模块；
• VS Code 扩展：与 App 共享了 Agent 采样参数、字体与内边距设置，以及大部分聊天与会话修复。

从变更内容看，1.13.3 的核心工程重点有三个：其一，把 SSH 提交签名正式接入 Git 身份流程；其二，让 Agent 的推理与采样参数（thinking variant、temperature、top-p）在设置中可配置、可清除；其三，集中修复会话切换、代码块渲染、移动端布局等高频体验问题。

Git 身份支持 SSH 提交签名

功能说明

1.13.3 中，"Git identity can sign your commits with SSH"——一个 Git 身份（identity）现在可以使用 SSH 密钥对提交进行签名。这是对原有 Git 身份管理能力的扩展：此前身份主要解决"我是谁"（user.name / user.email）与"如何认证远程"（SSH 私钥路径）的问题，现在进一步解决"如何证明提交出自我手"的签名问题。

源码级实现

服务端在 packages/web/server/lib/git/service.js 的setLocalIdentity函数中实现了完整逻辑，其签名写入分为三步：

await git.addConfig('gpg.format', 'ssh', false, 'local'); await git.addConfig('user.signingkey', profile.signingKey.trim(), false, 'local'); await git.addConfig('commit.gpgsign', 'true', false, 'local');

对应关系如下：

可以看到，签名开关并非无条件生效：源码中显式校验profile.signCommits === true且signingKey是非空字符串，二者同时满足才写入上述三项配置。这保证了用户在设置中未显式开启签名时，不会意外改变仓库的签名行为。

VS Code 扩展侧保留了同构实现，见 packages/vscode/src/gitService.ts 中的setGitIdentity函数：

const shouldSignCommits = signCommits === true && typeof signingKey === 'string' && signingKey.trim().length > 0; // ... if (shouldSignCommits) { await repo.setConfig('gpg.format', 'ssh'); await repo.setConfig('user.signingkey', signingKey.trim()); await repo.setConfig('commit.gpgsign', 'true'); }

函数签名也同步扩展：

export async function setGitIdentity( directory: string, userName: string, userEmail: string, sshKey?: string | null, signCommits?: boolean | null, signingKey?: string | null ): Promise<{ success: boolean }>

其中sshKey（可选）用于构建core.sshCommand完成远程认证，signingKey用于提交签名，两者是不同职责的密钥配置，均可选。

与 SSH 认证配置的关系

需要区分两组易混淆的配置：

• 远程认证：core.sshCommand。当身份中提供了sshKey时，服务端会通过buildSshCommand(profile.sshKey)生成ssh -i <path> -o IdentitiesOnly=yes并写入core.sshCommand（本地级）。escapeSshKeyPath会先对路径做平台归一化（Windows 反斜杠转正斜杠，C:/转/c/MSYS 风格），并拒绝包含`$!"';&|<>(){}[]*?#~等危险字符的路径，防止命令注入（见 packages/web/server/lib/git/service.js）。
• 提交签名：gpg.format/user.signingkey/commit.gpgsign。与认证无关，只决定git commit是否携带 SSH 签名。

两者是正交的：用户可以不提供sshKey（例如用 token 认证远程）但仍开启 SSH 提交签名。注意，设置身份时若authType === 'ssh'会写入core.sshCommand并清除credential.helper，若authType === 'token'则相反，二者只会保留其一。

使用建议

1. 在 OpenChamber 的 Git 身份设置中（搜索关键词包括identity、commit signing、ssh signing、gpg，见 packages/ui/src/lib/settings/search.ts），为身份填写signingKey（SSH 公钥路径，通常为~/.ssh/id_ed25519.pub）并开启签名开关；
2. 首次签名提交时，ssh-agent会请求确认私钥（OpenChamber 也会在.gnupg/S.gpg-agent.ssh与gpgconf --list-dirs agent-ssh-socket间探测 SSH agent socket，见 packages/vscode/src/gitService.ts），确认后即可用git log --show-signature验证签名；
3. 签名身份写入的是local级配置，仅影响当前仓库，不会污染全局 Git 配置。

Agent 设置：thinking variant、temperature 与 top-p

新增采样与推理控制

1.13.3 为 Agent 设置新增了三项控制，App 与 VS Code 扩展端同步提供（社区贡献：@bashrusakh）：

• thinking variant：选择模型推理/思考变体，设置搜索关键词为thinking、reasoning、variant；
• temperature：控制输出随机性/创造性，搜索关键词为randomness、creative；
• top-p：核采样（nucleus sampling）阈值，搜索关键词为sampling、nucleus。

这三项在设置注册表中均有独立条目，见 packages/ui/src/lib/settings/search.ts：

{ id: 'agents.variant', page: 'agents', keywords: ['thinking', 'reasoning', 'variant', 'depth'] }, { id: 'agents.temperature', page: 'agents', keywords: ['randomness', 'creative'] }, { id: 'agents.top-p', page: 'agents', keywords: ['sampling', 'nucleus'] },

它们在 UI 上归属于agents设置页（settings.agents.page.field.*系列标题与 tooltip 文案），与agents.model（覆盖模型）、agents.system-prompt、agents.steps、agents.permissions等并列。

清除覆盖的行为

1.13.3 同时改进了覆盖（override）的清理逻辑："clearing temperature or top-p removes the override"。即当用户在设置中把 temperature 或 top-p 清空（回到未设置状态）时，OpenChamber 会真正移除该 agent 的采样覆盖，而不是保留一个空值继续生效。这一行为同样由 @bashrusakh 贡献，App 与 VS Code 扩展端一致。

这一点对实际使用很重要：默认情况下，模型会使用其自身的采样参数；只有当用户显式设置 temperature / top-p 时才会覆盖模型默认值。清空输入框即等于"撤销覆盖、恢复模型默认"，避免出现"设置了 0 却仍然随机"或"空值被意外当作合法参数下发"的歧义。

本次版本其他值得关注的改进与修复

Git：推送前先同步

"pushing from the Git view syncs first"——从 Git 视图发起推送时，OpenChamber 会先执行同步（fetch/merge 等）再推送，显著减少推送因远端领先而被拒绝（rejected）的情况。对于多设备协作或多人共用的仓库，这能明显降低手工 rebase 的频率。

设置与字体

• 字体与内边距应用到 VS Code 扩展：此前在 App 侧配置的字体大小与内边距不会反映到 VS Code 扩展的界面，1.13.3 修复了这一不一致（@Sin991114）。App 与扩展现在共享同一套排版偏好。

聊天（Chat）修复

• Slash 菜单选择自己的技能：从/菜单中选取自己的 skill 时，现在会直接运行该技能，而不再是把技能名当作普通文本插入消息（@IbrahimKhan12）；
• 代码块保留特殊字符：自己消息中的代码块现在会保留<、->等字符，不再被错误转义或丢失（@bashrusakh）；
• Arrow Up 恢复历史：当光标位于输入框最开头时按 Arrow Up，重新能够呼出提示历史（prompt history）；
• @粘贴不再触发文件提及：粘贴包含@的文本时，不再误弹出文件 @-mention 面板（@charpeni）；
• 会话切换不再跳动：切换会话或加载更早消息时，对话不再向后回跳或抖动（@herjarsa），这通常源于消息列表未正确锚定到滚动位置。

会话（Sessions）

• 新会话跟随所选项目/文件夹：新建会话时，会话归属保持为你选择的项目或文件夹，不再漂移到默认位置（@bashrusakh）；
• 固定项在空列表中保留：当会话列表返回为空时，侧边栏中已固定的会话与文件夹仍然显示，避免用户"丢失"固定入口（@bashrusakh）。

设置与模型

• 模型可见性持久化：per-model 可见性与同级模型（sibling model）选择在重启后保持已保存状态（@attilaszasz）；
• 技能目录重新加载：修改 catalog 设置后，技能目录（skills catalog）会立即重新加载，无需重启（@gokulkgm）。

其他模块

• Providers：从设置中断开 provider 现在真正生效；
• Usage：MiniMax M3 与 Token Plan 的用量统计恢复读取 provider 的当前响应（@baruchvitorino），修复了用量面板显示滞后或丢失的问题；
• Files：下载文件名含非拉丁字符（如中文、日文、韩文）时保持原始文件名，不再乱码或被截断（@FanFan4204）；
• Startup：上次崩溃遗留的 managed OpenCode 进程会在下次启动时被清理，防止僵尸进程占用端口或资源；
• CLI：遗留的服务器 PID 文件不再让 CLI 误把无关进程当作 OpenChamber 实例处理，避免误杀或错误接管；
• Mobile：子代理（subagent）展开箭头不再覆盖过长的会话标题（@weixiang1862、@lilyzhaun）；会话按精确文件夹分组，而不是模糊的路径前缀（@weixiang1862、@lilyzhaun）。

版本清单与升级建议

1.13.3 的完整变更清单保存在仓库 changelog/1.13.3.md，更早版本见 changelog 目录（1.0.1 至 2.0.0 均有对应文件），跨版本总览见 CHANGELOG.md。

对于正在使用 OpenChamber 的开发者，本版本值得立即更新的理由：

• 如果你的团队要求提交签名（如开源合规或供应链安全要求），1.13.3 让你在 OpenChamber 界面内直接配置 SSH 提交签名，不必再手工改.git/config；
• 如果你需要精细控制 Agent 的输出风格（例如让编码 agent 更保守、让写作 agent 更发散），新增的 temperature / top-p / thinking variant 覆盖非常实用；
• 一系列会话与聊天体验修复（不跳屏、技能直接运行、@粘贴不弹面板）会直接影响每天的高频操作。

升级后建议重点验证：Git 身份签名配置是否正确写入（可git config --local --list查看gpg.format、user.signingkey、commit.gpgsign）；在 agent 设置中清空 temperature / top-p 后确认覆盖被移除；移动端子代理列表与文件夹分组是否符合预期。

• AI Agent
• 人工智能
• 代码智能体
• 交互助手