autowonder 0.2.164 → 0.3.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +25 -9
- package/package.json +1 -1
- package/vendor/autowonder-daemon-darwin-amd64 +0 -0
- package/vendor/autowonder-daemon-darwin-arm64 +0 -0
- package/vendor/autowonder-daemon-linux-amd64 +0 -0
- package/vendor/autowonder-daemon-linux-arm64 +0 -0
- package/vendor/autowonder-daemon-win32-amd64.exe +0 -0
- package/vendor/autowonder-daemon-win32-arm64.exe +0 -0
package/README.md
CHANGED
|
@@ -6,10 +6,10 @@ AutoWonder 本地 agent runtime。安装后启动 daemon,持续轮询本地 as
|
|
|
6
6
|
|
|
7
7
|
```bash
|
|
8
8
|
# Qoder CLI(模型使用 provider model ID;Context Window 使用固定档位)
|
|
9
|
-
npx -y autowonder@0.
|
|
9
|
+
npx -y autowonder@0.3.1 connect --ws-url <wss-endpoint> --token <executor-token> --executor-id <executor-id> --provider qoder --model qmodel_latest --reasoning-effort medium --context-window 260000
|
|
10
10
|
|
|
11
11
|
# Qoder CLI CN
|
|
12
|
-
npx -y autowonder@0.
|
|
12
|
+
npx -y autowonder@0.3.1 connect --ws-url <wss-endpoint> --token <executor-token> --executor-id <executor-id> --provider qodercn
|
|
13
13
|
```
|
|
14
14
|
|
|
15
15
|
`connect` 会安装当前 npm 包内置的 daemon,并使用页面生成的 WebSocket endpoint、Token 和执行器 ID 建立连接。客户端只支持通过 Qoder 系列 CLI 启动(`qoder` 对应 `qodercli`,`qodercn` 对应 `qodercn`),其他 `--provider` 取值会在启动 daemon 前直接报错拦截并提示 `Unsupported provider`。选择 Qoder CLI 或 Qoder CLI CN 时需要 Node.js 20+;runtime 会在缺少对应 CLI 时自动通过 npm 安装,并在尚未登录时打开浏览器登录。runtime 会继承当前用户的 HOME、环境变量和 CLI 登录状态。
|
|
@@ -41,6 +41,20 @@ daemon 还会响应服务端的 `CONVERSATION_COMMANDS_PROBE` 帧,用独立会
|
|
|
41
41
|
|
|
42
42
|
`connect` 支持 `--workspace-root <path>` 指定 dispatch 仓库与任务工作区所在目录(默认 `~/autowonder_workspaces`)。该参数会转发给 daemon,等价于设置 `AUTOWONDER_WORKSPACE_ROOT` 环境变量,适合把工作区放在非默认路径的执行机上(如 Windows 的 `D:\autowonder`)。
|
|
43
43
|
|
|
44
|
+
## 自主记忆(Qoder 执行器)
|
|
45
|
+
|
|
46
|
+
Qoder 系列执行器的跨派单记忆由平台托管。服务端在派单里下发记忆快照与同步路径,daemon 按该路径拉取快照,把记忆文档投影到本次任务的 capsule(`state/memory/`),并以 `AUTOWONDER_MEMORY_DIR` 注入 provider 子进程;任务执行期间产生的记忆变更经本地 journal 增量回传服务端,索引整理由服务端下发的维护租约驱动。本机历史遗留的 Qoder 记忆(provider 配置根下的 `AGENTS.md`、`MEMORY.md`、`memories.md`,单文件上限 4 MiB)会在派单执行时经脱敏后导入平台,凭据字段与私钥会被替换为 `[REDACTED]`;该导入是机会式的,失败只记调试日志并延后重试,不影响任务本身。
|
|
47
|
+
|
|
48
|
+
记忆写入被服务端校验拒绝时,runtime 只提取已知的校验码与行号(不夹带服务端响应正文)连同修复方法反馈给模型;只有确实存在待修复写入时才允许一次有界修复,普通业务任务不会因此多出反思回合。隔离维护会话开始时会读取当时最新的 `MEMORY.md`(业务回合可能已修正索引),维护只有在同步队列清空且索引整理目标达成后才算完成。
|
|
49
|
+
|
|
50
|
+
`--memory-mode` 控制该能力,取值为 `platform`(默认)、`provider-local`、`none`:
|
|
51
|
+
|
|
52
|
+
- `platform`:使用上面的平台托管记忆。
|
|
53
|
+
- `provider-local`:沿用 provider 自己的本地记忆目录。**Qoder 系列已不再支持该取值**:以 `--memory-mode provider-local` 启动的 Qoder 执行器会在执行任务时直接报错 `qoder provider-local memory is no longer supported; migrate to platform memory`,需要改用 `platform`(或不需要记忆时用 `none`)并重新生成启动命令;其他 provider 不受影响。使用默认值 `platform` 的执行器无需任何改动。
|
|
54
|
+
- `none`:不读写记忆。
|
|
55
|
+
|
|
56
|
+
记忆文件位于任务 capsule 内,随工作区 GC 一并清理;尚未被服务端确认的记忆变更暂存在 `<workspace-root>/.memory-outbox/` 下,进程重启后可续传。`AUTOWONDER_MEMORY_DIR` 由 runtime 注入,执行机用户不需要自行设置。
|
|
57
|
+
|
|
44
58
|
## 工作区保留与 Git 对象复用
|
|
45
59
|
|
|
46
60
|
daemon 默认启用本地工作区 GC:启动 30 秒后开始检查,之后每小时执行有限量的后台清理。非会话任务仅在终态且最后活动时间超过所配置的任务 TTL(默认 72 小时)后才符合清理条件;会话目录仅在最后活动时间超过所配置的会话 TTL(默认 720 小时)后才符合条件。清理的单位是整个 attempt capsule 或整个 conversation capsule,不会只删除其中部分文件。未知或格式异常、非终态(包括 uploading)、仍在运行、由恢复流程持有、结果仍待确认,或结果状态查询失败的 capsule 都会保留。
|
|
@@ -63,6 +77,8 @@ daemon 默认启用本地工作区 GC:启动 30 秒后开始检查,之后每
|
|
|
63
77
|
|
|
64
78
|
`~/autowonder_workspaces`(可由 `--workspace-root` 或 `AUTOWONDER_WORKSPACE_ROOT` 修改)保存每个任务独立的工作文件和 checkout/worktree;`~/.autowonder/git-object-cache/v1` 保存可供多个任务复用 Git 历史对象的本地 bare mirror。每个任务仍会得到所请求准确 commit 的独立工作区。已缓存的固定 commit 可以不查询远端;允许联网时,`HEAD`、branch 或 tag 等可移动 ref 会在每次 materialization 时向远端解析为准确 commit,仅在 mirror 缺少该对象时 fetch。缓存优化失败时,只有其临时目录已经完成可验证的干净回滚才会回退到原有的远端完整 clone 流程;若无法证明干净回滚,则会保留现场并返回错误,不进入回退。任何路径都不会发布不完整的目标目录;已经存在的任务仓库只做校验,不会被 fetch、reset、clean、checkout 或覆盖。本版本不会自动淘汰 Git 对象缓存,工作区 GC 也不会删除该缓存。
|
|
65
79
|
|
|
80
|
+
任务工作区里的 Git 策略(是否允许提交/推送与工作区边界)由 runtime 安装的自包含钩子强制执行:默认策略不依赖 runtime 二进制或任务配置继续存在,因此历史任务残留不会让普通的 `git commit` / `git push` 失败,策略禁止时分别以退出码 `73` / `74` 拒绝提交与推送,提交还要求 HEAD 位于具名分支(detached 时以 `77` 拒绝)。安装是幂等的,只有确实声明了打包触发的仓库才会链式调用 runtime。daemon 启动时会在 15 秒预算内把本执行器历史 capsule 中可核对的旧版包装脚本迁移为这种自包含形式;模板、配置或元数据不完整的历史一律保留现场,不做全机扫描,也不恢复用户原有的 `hooksPath`。
|
|
81
|
+
|
|
66
82
|
## 自动更新
|
|
67
83
|
|
|
68
84
|
安装首个支持自动更新的正式版本后,daemon 会直接查询 npm 的 `autowonder/latest`。首次检查会随机分散在启动后的 30~90 秒,之后约每 5 分钟检查一次并加入随机抖动;npm 临时错误会指数退避,HTTP 429/503 的 `Retry-After` 会被遵循。发现更高的稳定版本时,它会在后台下载 npm tarball,校验 SHA-512 SRI、包版本和平台二进制;只有在没有运行/恢复任务且结果 outbox 已收到服务端确认时,才会暂停接单、原子切换二进制并自动重启。启动失败会恢复上一个二进制。
|
|
@@ -132,7 +148,7 @@ mv "$queue/.assignment.tmp" "$queue/assignment.json"
|
|
|
132
148
|
也可以直接提交到本地 API:
|
|
133
149
|
|
|
134
150
|
```bash
|
|
135
|
-
npx -y autowonder@0.
|
|
151
|
+
npx -y autowonder@0.3.1 dispatch ./assignment.json
|
|
136
152
|
```
|
|
137
153
|
|
|
138
154
|
## 上传工单附件
|
|
@@ -140,7 +156,7 @@ npx -y autowonder@0.2.164 dispatch ./assignment.json
|
|
|
140
156
|
把本地需求/设计文档直接上传到工单,避免在会话里传递大文件:
|
|
141
157
|
|
|
142
158
|
```bash
|
|
143
|
-
npx -y autowonder@0.
|
|
159
|
+
npx -y autowonder@0.3.1 workitem upload --server-url <autowonder-server-url> --workitem-id <id> --file <filepath-1> --file <filepath-2> --json
|
|
144
160
|
```
|
|
145
161
|
|
|
146
162
|
上传令牌通过 MCP 工具 `autowonder.workitem_cli_upload_token` 签发,经 `--token` 或 `AUTOWONDER_UPLOAD_TOKEN` 环境变量传入。`--file` 可重复指定多个文件;`--json` 输出机器可读结果。失败时按错误类型返回不同退出码(401→3、403→4、404→5、409→6、413→7、其他 4xx→8、网络/重定向→9)。
|
|
@@ -150,7 +166,7 @@ npx -y autowonder@0.2.164 workitem upload --server-url <autowonder-server-url> -
|
|
|
150
166
|
把工单上已有的需求/设计文档下载到本地目录,再用本地文件工具阅读,避免把大文件或二进制附件搬进会话上下文:
|
|
151
167
|
|
|
152
168
|
```bash
|
|
153
|
-
npx -y autowonder@0.
|
|
169
|
+
npx -y autowonder@0.3.1 workitem download --server-url <autowonder-server-url> --workitem-id <id> --file <name-or-id> --output-dir <dir> --json
|
|
154
170
|
```
|
|
155
171
|
|
|
156
172
|
下载令牌通过 MCP 工具 `autowonder.workitem_cli_download_token` 签发(与上传令牌相互独立),经 `--token` 或 `AUTOWONDER_DOWNLOAD_TOKEN` 环境变量传入。`--file` 可重复指定文档名或 artifact id,省略则下载该工单的全部附件;`--output-dir` 默认为当前目录;`--json` 输出机器可读结果,含每个文件的 `id`、`name`、`path`、`size`。退出码约定与 `workitem upload` 相同(401→3、403→4、404→5、409→6、413→7、其他 4xx→8、网络/重定向→9)。
|
|
@@ -160,7 +176,7 @@ npx -y autowonder@0.2.164 workitem download --server-url <autowonder-server-url>
|
|
|
160
176
|
把需求/设计文档上传到 7x24 定时任务,用法与工单附件一致(同一套上传令牌与预检规则):
|
|
161
177
|
|
|
162
178
|
```bash
|
|
163
|
-
npx -y autowonder@0.
|
|
179
|
+
npx -y autowonder@0.3.1 scheduled-task upload --server-url <autowonder-server-url> --scheduled-task-id <id> --file <filepath-1> --file <filepath-2> --json
|
|
164
180
|
```
|
|
165
181
|
|
|
166
182
|
上传令牌同样通过 `autowonder.workitem_cli_upload_token` 签发(令牌为用户级,对当前可修改的任意定时任务生效),经 `--token` 或 `AUTOWONDER_UPLOAD_TOKEN` 传入;退出码约定与 `workitem upload` 相同。
|
|
@@ -168,8 +184,8 @@ npx -y autowonder@0.2.164 scheduled-task upload --server-url <autowonder-server-
|
|
|
168
184
|
## 管理 daemon
|
|
169
185
|
|
|
170
186
|
```bash
|
|
171
|
-
npx -y autowonder@0.
|
|
172
|
-
npx -y autowonder@0.
|
|
187
|
+
npx -y autowonder@0.3.1 status
|
|
188
|
+
npx -y autowonder@0.3.1 stop
|
|
173
189
|
```
|
|
174
190
|
|
|
175
191
|
默认 API 是 `http://127.0.0.1:34989`,日志位于 `~/.autowonder/daemon.log`。npm 包不包含任何 agent、MCP 或服务端凭证。
|
|
@@ -177,7 +193,7 @@ npx -y autowonder@0.2.164 stop
|
|
|
177
193
|
## 调试
|
|
178
194
|
|
|
179
195
|
```bash
|
|
180
|
-
npx -y autowonder@0.
|
|
196
|
+
npx -y autowonder@0.3.1 connect ... --debug
|
|
181
197
|
```
|
|
182
198
|
|
|
183
199
|
`--debug` 会让 CLI 以 `AUTOWONDER_DEBUG=1` 启动 daemon,把完整的 daemon 与 agent 活动(runtime 事件流、provider 事件解码、重试退避与会话门等待、空闲时的阻塞点)同时输出到控制台和会话调试日志。调试日志不做脱敏,仅用于本机排障;不传 `--debug` 时该环境变量不会注入。
|
package/package.json
CHANGED
|
Binary file
|
|
Binary file
|
|
Binary file
|
|
Binary file
|
|
Binary file
|
|
Binary file
|