131 lines
11 KiB
Markdown
131 lines
11 KiB
Markdown
# AgentRun 开发与运维参考
|
||
|
||
本文只记录 UniDesk 侧对独立仓库 `pikasTech/agentrun` 的开发与运维约束。AgentRun 的架构设计、MVP 范围、API 契约、runner/backend 协议和运行时内部规则必须维护在 AgentRun 仓库自身,不能放在 UniDesk 长期参考里作为事实来源。
|
||
|
||
## 仓库与 Worktree
|
||
|
||
AgentRun 唯一长期仓库是:
|
||
|
||
```text
|
||
git@github.com:pikasTech/agentrun.git
|
||
```
|
||
|
||
AgentRun 当前 `v0.1` 固定 source worktree 是:
|
||
|
||
```text
|
||
G14:/root/agentrun-v01
|
||
```
|
||
|
||
该目录必须固定使用 `v0.1` 分支,`origin` 必须是 `git@github.com:pikasTech/agentrun.git`,并保持 clean。任何明确面向 UniDesk/HWLAB 基础 Code Agent 调用服务 `v0.1` 的开发、文档修改、部署观察或恢复中断后,先通过 UniDesk SSH 透传执行:
|
||
|
||
```bash
|
||
trans G14:/root/agentrun-v01 script -- 'pwd; git status --short --branch; git remote -v'
|
||
```
|
||
|
||
期望状态:
|
||
|
||
- 当前路径是 `/root/agentrun-v01`;
|
||
- 分支是 `v0.1...origin/v0.1`;
|
||
- `origin` 是 `git@github.com:pikasTech/agentrun.git`;
|
||
- 固定 source worktree clean。
|
||
|
||
如果固定 source worktree 缺失、dirty、分支不对或 remote 不对,必须先修正,再继续工作。不得把 `/root/agentrun` 主线历史目录、`/root/unidesk`、`/root/hwlab`、D601 workspace、临时 clone、runner checkout、pod 内副本或 master-server 副本当作 AgentRun `v0.1` source truth。
|
||
|
||
## Worktree 规则
|
||
|
||
固定 source worktree 只用于预检、fetch、worktree 管理和最终同步。常规 AgentRun `v0.1` 功能、文档和部署修改必须使用独立 worktree:
|
||
|
||
```text
|
||
G14:/root/agentrun-v01/.worktree/{pr_branch}
|
||
```
|
||
|
||
`v0.1` worktree 必须从最新 `origin/v0.1` 创建。任务分支只覆盖当前变更,提交时只提交当前任务相关文件。不要把 `/root/agentrun-v01` 根目录当作并行任务 scratch 区。
|
||
|
||
## 文档落库规则
|
||
|
||
AgentRun 的 SPEC 和长期参考文档变更不创建 PR。完成本地审查后,必须直接提交并推送到对应目标分支,例如 `origin/v0.1`。过程计划、阶段证据、验收结果和阻塞点写入对应 GitHub issue 评论区,不能用文档 PR 代替直接落库。
|
||
|
||
## 部署目标
|
||
|
||
AgentRun 废弃旧 `dev/prod` 运行口径。`v0.1` 固定部署目标是 G14 原生 k3s namespace:
|
||
|
||
```text
|
||
G14:k3s namespace agentrun-v01
|
||
```
|
||
|
||
所有 k3s 操作必须使用 UniDesk route 语法:
|
||
|
||
```bash
|
||
trans G14:k3s kubectl get pods -n agentrun-v01
|
||
```
|
||
|
||
不得把临时 NodePort、host port、pod IP、provider-gateway 业务 HTTP proxy 或一次性 port-forward 固化为 AgentRun 部署路径。任何公网入口、UniDesk/HWLAB 集成入口或跨服务访问路径,都必须先通过 AgentRun 仓库内经过审查的变更引入;UniDesk 只在后续记录对应运维入口。
|
||
|
||
## 受控 CI/CD 入口
|
||
|
||
AgentRun `v0.1` 的 Tekton/Argo 控制面写操作必须通过 UniDesk 高层 CLI 执行:
|
||
|
||
```bash
|
||
bun scripts/cli.ts agentrun v01 control-plane status
|
||
bun scripts/cli.ts agentrun v01 control-plane trigger-current --dry-run
|
||
bun scripts/cli.ts agentrun v01 control-plane trigger-current --confirm
|
||
bun scripts/cli.ts agentrun v01 control-plane refresh --dry-run
|
||
bun scripts/cli.ts agentrun v01 control-plane refresh --confirm
|
||
bun scripts/cli.ts agentrun v01 control-plane cleanup-runs --min-age-minutes 30 --limit 200 --dry-run
|
||
bun scripts/cli.ts agentrun v01 control-plane cleanup-runs --min-age-minutes 30 --limit 200 --confirm
|
||
bun scripts/cli.ts agentrun v01 control-plane cleanup-released-pvs --limit 200 --dry-run
|
||
bun scripts/cli.ts agentrun v01 control-plane cleanup-released-pvs --limit 200 --confirm
|
||
```
|
||
|
||
`status` 只读观察 `G14:/root/agentrun-v01` 当前 commit、对应 PipelineRun、GitOps latest、Argo Application、`agentrun-v01` workload、manager source commit 和 git mirror 摘要,并报告 Argo revision 是否对齐 `v0.1-gitops` latest。默认输出是 compact commander 视图,只保留 `summary`、阶段耗时、对齐状态和 drill-down 命令;需要远端 stdout/stderr tail 时显式加 `--full`,需要原始 git mirror cache 输出时显式加 `--raw`。`status` 会向 stderr 输出 `agentrun.control-plane.status.progress` 阶段事件,覆盖 `source`、`runtime` 和 `git-mirror`,避免长时间聚合时无可见进展。`trigger-current` 会先把固定 source worktree 快进到 `origin/v0.1`,再以当前 commit 创建 commit-pinned PipelineRun;同名 PipelineRun 正在运行或已经成功时必须拒绝重复触发,只允许在失败态或不存在时创建。该命令只提交 CI/CD 工作,不等待完整 PipelineRun 或 rollout 完成,后续用 `status` 轮询。`refresh` 只对 `argocd/agentrun-g14-v01` 执行 hard refresh,用于 GitOps promotion 已完成但 Argo 仍停留旧 revision 时的受控同步入口;它不直接 patch runtime workload。
|
||
|
||
`cleanup-runs` 是 AgentRun `v0.1` 完成态 CI workspace retention 入口,只清理 `agentrun-ci` namespace 中超过 `--min-age-minutes` 的 `agentrun-v01-ci-*` PipelineRun,通过 Tekton ownerRef 释放临时 workspace PVC。dry-run 必须披露候选 PipelineRun、owned PVC、active mount 保护、local-path 实际估算 bytes 和 confirm 命令。默认保护最新完成的 PipelineRun,保留当前 CI/CD 状态证据。`cleanup-released-pvs` 是二次回收入口,只处理 `agentrun-ci`、`local-path`、`Delete` reclaim policy 的 `Released` PV;它不触碰 `agentrun-v01` runtime namespace、业务 PVC、Secret、registry storage 或 GitOps desired state。磁盘治理和 G14 safe-stop 规则见 `docs/reference/gc.md`。
|
||
|
||
## UniDesk 边界
|
||
|
||
UniDesk 是 AgentRun 的综合分布式开发和运维中心。UniDesk 可以记录:
|
||
|
||
- AgentRun 的固定仓库、source worktree 和 worktree 规则;
|
||
- G14 预检、route 语法和远程操作入口;
|
||
- `v0.1` 固定 namespace 与后续版本 lane 规则;
|
||
- 部署观察、受控 rollout 和运维入口;
|
||
- AgentRun 仓库定义公共契约后,UniDesk 与 HWLAB 如何接入。
|
||
|
||
UniDesk 不能作为以下内容的事实来源:
|
||
|
||
- AgentRun 服务架构;
|
||
- MVP 阶段规划;
|
||
- RESTful API 契约;
|
||
- runner/backend 协议;
|
||
- 数据库 schema;
|
||
- tenant policy 模型;
|
||
- backend adapter 设计。
|
||
|
||
这些内容必须维护在 AgentRun 仓库自己的 `AGENTS.md` 和 `docs/reference/` 中。
|
||
|
||
## AgentRun / HWLAB 协同职责边界
|
||
|
||
HWLAB 接入 AgentRun 时,必须先按公共契约和运行证据判断问题归属,再进入对应仓库修改。谁拥有缺失能力、错误语义或未修复行为,就改谁;不得为了让当前联调继续推进而在另一侧迁就、伪造语义、补观测替代实现,或把缺失能力包装成已完成。
|
||
|
||
AgentRun 负责共享 Agent 执行基础设施本身,包括 run/command/runner-job 生命周期、bundle 物化、cancel、trace/result 元语、backend adapter 事件语义、runner 环境传递、CLI 结果查询和 SPEC 中已经承诺的能力。若这些能力缺失或行为错误,必须在 `pikasTech/agentrun` 的 SPEC、源码、单元/自测、CI/CD 和 `agentrun-v01` 运行面中补齐,再让 HWLAB 通过 adapter 消费明确契约;HWLAB 不应在渲染层、adapter 层或 prompt 中推断、补造 AgentRun 没有发出的事实。
|
||
|
||
HWLAB 负责自身产品和接入层,包括用户鉴权、Cloud Web/CLI 对外 API、conversation/session 归属、前端展示、device-pod 业务授权、HWLAB 到 AgentRun 的 adapter 映射,以及不改变外部 API 的内部调用切换。若 AgentRun 已按契约输出正确语义,而 HWLAB 消费、映射、渲染或业务路径仍有问题,必须在 `pikasTech/HWLAB` 修复,不能要求 AgentRun 为 HWLAB 私有 UI 或业务模型增加临时兼容。
|
||
|
||
跨仓库 issue 和 PR 必须明确写出责任归属、契约依据和验证入口。需要两边配合时,先在拥有公共契约的一侧补齐能力,再在消费侧做最小适配;不允许用双路径、legacy mode、feature flag、fallback 或额外噪声观测长期绕过真实缺口。
|
||
|
||
直接通过 AgentRun manager、`dispatchHwlabAgentRun()` 或手写 runner job 发起的 canary 只能证明 AgentRun 基础设施和工具凭据本身可用,不能证明 HWLAB Cloud Web/Cloud API 的产品入口已经正确请求这些能力。涉及 Cloud Web Workbench、用户会话、conversation/session/thread、tool alias 或业务授权的 issue,必须用 HWLAB 的 Web dispatcher 原入口,或调用同一 dispatcher 的 CLI 验证。若消费侧 Web dispatcher 没有把 `toolCredentials`、`toolAliases` 或 transient env 传给 AgentRun,应归为 HWLAB 接入层问题;若 dispatcher 已正确请求但 AgentRun runner 没有装配,应归为 AgentRun 执行基础设施问题。
|
||
|
||
## AgentRun / HWLAB 失败归因标准
|
||
|
||
HWLAB 通过 AgentRun 执行 Code Agent turn 时,失败归因必须以 AgentRun backend adapter 的结构化 failure kind 为准。AgentRun 负责把 provider、thread、runner、bundle 和 command lifecycle 的失败分类成稳定语义;HWLAB 负责原样消费并映射到用户可读分类。不得为了让 UI 或 issue 收口看起来更顺,把 AgentRun/provider 错误改写成 device-pod、gateway、Cloud API endpoint 或前端渲染问题。
|
||
|
||
Codex thread 连续性只有一个标准路径:已有 `SessionRef.threadId` 时,AgentRun 必须通过 Codex stdio 原生 `thread/resume` 续接,再对同一 app-server session 执行 `turn/start`。当 `thread/resume` 遇到旧 app-server rollout 缺失、返回 `no rollout found for thread id` 或其他 resume 协议错误时,AgentRun 必须输出 `thread-resume-failed` 并终止当前 turn;不得启动替代 `thread/start`、不得回写新的 `threadId`、不得拼接历史 prompt,也不得要求 HWLAB 通过清会话、隐藏错误或重开路径迁就。HWLAB 收到该 failure kind 时,应显示为 AgentRun/Codex thread resume 层错误,不要把它解释成硬件执行通道或 Cloud API 不可达。
|
||
|
||
Codex app-server/provider 返回 tool-call 参数 JSON 错误时,AgentRun 应输出 `provider-invalid-tool-call`。HWLAB adapter/Web 应映射为 provider/tool-call 层错误,并保留 `providerTrace.failureKind` 与简明 failure message,明确这不是 device-pod、gateway 或 Cloud API endpoint 故障。后续修复应进入 AgentRun provider/backend adapter 或上游 provider 请求构造,不要在 HWLAB 设备侧增加兼容路径。
|
||
|
||
诊断入口只能补足同一路径上的可见性,不能形成第二套执行路径。用于复现 provider failure 的自测、fake app-server mode 或 debug command 必须调用真实 backend adapter 分类逻辑,并在完成修复后作为自测或 SPEC 合同保留;不得保留并行诊断镜像、独立执行镜像或只服务某个 issue 的替代 runtime。
|
||
|
||
## 中文规则
|
||
|
||
AgentRun 仓库内容默认中文。AgentRun 长期文档、过程文档、issue 标题与正文、PR 标题与正文、PR 评论、review 说明和交付总结都必须使用中文。代码标识符、API path、命令名、配置键、日志字段、协议字段和不可避免的外部专有名词可以保留英文,但解释性文字必须使用中文。
|