Bohdan Triapitsyn
a5aa32446d
The preview panel worked by proxying a dev server through OpenChamber's own origin and rewriting the HTML that came back. Anything the rewriter did not anticipate broke, and pages that refuse to be embedded never loaded at all. This deletes the proxy (-1604 lines and its tests) and merges the preview and browser panels into one surface backed by a real Chromium view. What the panel is now - A `<webview>` in its own session partition: logins and cookies persist, hot reload works because nothing is rewritten, DevTools are one click away. - Annotation: pick one element, drag a region, or draw freehand, write a note, and it reaches chat with a screenshot of the visible page with the marks on it. - Toolbar: hard reload, page zoom, device sizes, a light/dark switch that applies to the page rather than the app, and cookie/cache clearing scoped to the panel alone. - Several pages at once, each tab showing the page's own favicon, and an address bar that suggests pages already visited in this project. - Dev servers are listed from what is actually listening on the machine, checked against what a project announced, so a server is offered no matter how it was started. One that is still starting is waited for instead of failing. Remote dev servers The desktop app binds a local port and pipes raw bytes to the OpenChamber host over the existing authenticated connection, so the page keeps its own origin at the root of its own host. The reachable set is exactly what discovery reports and is re-checked per connection, so an authenticated client cannot dial arbitrary local services on the host. Links and redirects to another loopback port stay on the machine that served the page. A tunnel that cannot be opened is reported; it is never replaced by the plain loopback URL, which would answer from the user's own machine under a remote address. Agent control Browser actions are a separate `openchamber_web` tool: open, snapshot, click, type, scroll, inspect computed styles, resize between mobile/tablet/desktop, and capture a screenshot into `.openchamber/screenshots/` in the project. The existing `openchamber` tool keeps sessions, worktrees and scheduled tasks. Each has its own setting in the new Settings -> General -> OpenChamber Tools section, and the plugin is not injected at all when both are off. Capability belongs to the connected client, not to configuration: a client declares on its event stream that it can drive a page, which only a Chromium host does. Exactly one client performs each request — it claims the request before acting, and the first claim wins — because deciding by whose result arrives first would be too late for a click that already happened. No client listening is answered immediately with an explanation rather than a timeout. Runtime boundaries Web tabs get a plain iframe that can display a page but not inspect one. The VS Code extension no longer offers the surface at all, since nothing that makes the panel worth having works there. Mobile is unaffected. Native boundary Camera, microphone, location and device-picker requests from panel pages are denied — Electron grants them by default when no handler is set, and the panel loads whatever address the user types. Page capture, appearance emulation and storage clearing verify that their target belongs to the panel's own session instead of trusting a web-contents id from the renderer. Persisted state Stored `preview` tabs migrate to `browser` (v13 -> v14). Context panel tab limits are now per surface, so filling one surface no longer evicts another's tabs. Address history is stored per project and per runtime. Documentation `preview.mdx` and `desktop-browser.mdx` rewritten across all locales, the agent tool settings path corrected, new `DOCUMENTATION.md` for the browser-control broker and the dev tunnel, and the `ui-api-decoupling` skill updated where it still described the deleted proxy.
41 lines
2.5 KiB
Plaintext
41 lines
2.5 KiB
Plaintext
---
|
|
title: 智能体控制工具
|
|
description: 让智能体从聊天中管理 OpenChamber 会话、worktree 和计划任务。
|
|
---
|
|
|
|
# 智能体控制工具
|
|
|
|
使用 `openchamber` 智能体工具直接从聊天中管理应用内的工作。当 OpenChamber 运行自己的本地 OpenCode 服务器时，此工具默认启用；无需安装单独的工具或运行 shell 命令。
|
|
|
|
## 可以提出哪些请求
|
|
|
|
用自然语言告诉智能体即可。例如：
|
|
|
|
- “在此项目中创建一个新的 OpenChamber 会话，使用 `openai/gpt-5.6-sol` 模型，并向它发送此提示：审查身份验证流程。”
|
|
- “在单独的 worktree 中为此任务创建一个新的 OpenChamber 会话，并让它为登录流程添加测试。”
|
|
- “使用 OpenChamber 列出我最近的 10 个会话，并包含它们的当前状态。”
|
|
- “在 OpenChamber 中创建名为‘工作日审查’的计划任务，每个工作日 09:00 发送此提示：审查自上次运行以来的更改。”
|
|
- “立即运行名为‘工作日审查’的 OpenChamber 计划任务。”
|
|
- “检查名为‘身份验证审查’的 OpenChamber 会话，并显示最新的助手回复。”
|
|
|
|
该工具可以列出项目和模型偏好、创建和继续会话、分叉会话、创建隔离的 worktree 会话，以及管理计划任务。以这种方式启动的会话会像普通会话一样显示在 OpenChamber 中，因此你可以打开并自行继续工作。
|
|
|
|
## 注意事项
|
|
|
|
- 新会话提示默认会立即返回。请在 OpenChamber 中跟进会话，或稍后让智能体检查结果。
|
|
- 只有在你明确要求时才会创建单独的 worktree。当前 worktree 中未提交的更改不会复制过去。
|
|
- 该工具不能删除会话或 worktree、注册项目路径、运行任意 shell 命令或访问任意 URL。
|
|
|
|
## 开启或关闭工具
|
|
|
|
打开 **设置 → 常规 → OpenChamber 工具**，更改 **智能体控制工具**。该设置会在托管的 OpenCode 服务器重启后生效，OpenChamber 会以 **Apply & Restart** 的形式提示重启。
|
|
|
|
当 OpenChamber 通过 `OPENCODE_HOST` 或 skip-start 连接外部 OpenCode 服务器时，或在 VS Code 扩展中，此工具不可用。使用 OpenChamber 托管 OpenCode 服务器的桌面端和 Web 安装会自动支持此工具。
|
|
|
|
## 相关内容
|
|
|
|
- [计划任务](/zh-cn/scheduled-tasks/)
|
|
- [Worktree 会话](/zh-cn/worktrees/)
|
|
- [会话目标](/zh-cn/session-goals/)
|
|
- [浏览器面板](/zh-cn/desktop-browser/) — 用于查看并操作页面的 OpenChamber Web 工具
|