pikasTech-unidesk/docs/reference/agentrun.md

AgentRun 开发与运维参考

本文只记录 UniDesk 侧对独立仓库 pikasTech/agentrun 的开发与运维约束。AgentRun 的架构设计、MVP 范围、API 契约、runner/backend 协议和运行时内部规则必须维护在 AgentRun 仓库自身，不能放在 UniDesk 长期参考里作为事实来源。

仓库与 Worktree

AgentRun 唯一长期仓库是：

git@github.com:pikasTech/agentrun.git

AgentRun 当前 v0.1 固定 source worktree 是：

G14:/root/agentrun-v01

该目录必须固定使用 v0.1 分支，origin 必须是 git@github.com:pikasTech/agentrun.git，并保持 clean。任何明确面向 UniDesk/HWLAB 基础 Code Agent 调用服务 v0.1 的开发、文档修改、部署观察或恢复中断后，先通过 UniDesk SSH 透传执行：

tran 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：

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：

G14:k3s namespace agentrun-v01

所有 k3s 操作必须使用 UniDesk route 语法：

tran 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 执行：

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

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。

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、命令名、配置键、日志字段、协议字段和不可避免的外部专有名词可以保留英文，但解释性文字必须使用中文。