1.1 执行面：单个编码 Agent 的能力边界#

通用编码 Agent 在大型代码库上会暴露出一组相似的问题。模型本身足够聪明，但它拿不到正确的上下文——要么一次读入太多文件导致判断分散，要么模块边界和领域术语只能靠猜测推进，搜索过程中又充满噪音[1]。Coding Agent 的大多数演示是从零搭建一个简单的 Todo 类应用，而真实代码库往往是"有十五年历史、充满未文档化的隐性契约、蔓延到四十个文件的服务层"[2]。Anthropic 提出的方向是让"代码库适配 AI"而不是只靠模型[3]，但在长期迭代、历史包袱重的大型仓库中，我们更需要一种让 AI Agent 主动适应现有代码的方案（这一点在作者博客中有过专门论述 https://zhongye1.github.io/p/f77cee45/）。

生成代码的质量同样堪忧。AI 可能引用不存在的函数、使用想象出来的 API、或者写出语法正确但逻辑错误的代码[4]。业界常见的做法叫"给 AI 制定 coding guidelines"，把团队规范做成 spec 喂给 Agent[5]。我们要做的是把这套方法论内化到 Agent 内核中，而不是外挂一份规范文档了事。

复杂任务的长程执行是另一个难题。Agent 容易出现上下文腐烂（context rot）和跑偏（drift）：前 20 个回合一切正常，到第 40 个回合 Agent 开始改不该改的文件、重复调用失败的工具、甚至忘了最初要解决什么问题[6]。长上下文压缩也可能导致任务链断裂[7]。针对这些问题，需要为长任务 Agent 设计有效的 harness[8]。

最后是质量反馈的缺失。当前阶段仍存在"AI 信任鸿沟"——开发者希望以最少的人工审查将 AI 生成代码部署到生产，但 Agent 的运行过程和最终结果都缺乏科学、客观的质量评估[9]。

1.2 协作面：Agent 高自主性带来的团队可见性缺失#

Agent 的高自主性与不透明推理对传统可观测性方法构成了显著挑战[10]。即便单个 Agent 好用，它本质上只是"某个人在自己机器上跑的一个 loop"——任务不透明，团队其他人无法 review Agent 的执行链路，也无法知道它为什么做了某个决策。业界至今缺少一个正式的过程模型来定义 Agent 之间及其与人类监督者如何贯穿整个研发生命周期协作[11]。这就意味着，Agent 的能力再强，也停留在个人工具的层面，无法升级为团队协作的基础设施。

1.3 链路面：从需求到上线各环节未打通#

Agent 擅长写代码，但它只覆盖了生命周期的一段。现有软件工程 Agent 大多是各自解决孤立子问题的"专才"，缺少一个把整条链路贯通的统一体[12]。然而恰恰是评审、CI、部署这些后期阶段，因其产出可以通过可执行反馈客观评估，才是 Agent 最能落地的地方；工业界的普遍做法是把 Agent 动作限制在可验证、有边界的空间里[13]。但今天这些环节的衔接仍然靠人肉——issue 到代码、代码到 PR、PR 到 CI、CI 到部署，每一步都需要人手动触发，没有一个把 issue、代码、部署串成闭环的编排机制，而这层工作流管理本身就是公认的开放难题[14]。

2.1 功能目标#

这套架构要让团队能做到以下三件事：

第一，团队成员在 IM（飞书）中发起任务时，Agent 自动执行并实时回流状态——从任务创建、指派到运行进展、终态结果，整个团队在群里看得见、可 review。

第二，多个有依赖关系的任务能按 DAG 自动串联执行。一个任务完成并解锁下游后，下游任务自动派发，不需要人手动衔接。

第三，部署环节有发布门拦截。代码推上去之后，Vercel 构建完成、域名分配之前，先由 liskin 跑一轮验证（测试、lint、类型检查），验证通过才放行，不通过就把坏版本卡在门外。

2.2 架构约束#

以下约束贯穿全部设计决策，在任何阶段都不得违反：

• 控制面与执行面分离：Dispatcher 只做调度和状态跟踪，不碰代码、不碰密钥、不碰 prompt 内容。
• 编排层保持确定性：OGAS-Flow 不调用 LLM、不含随机数、不介入 Agent 内部推理，节点之间的推进完全确定。
• 高危操作必须人工确认：生产回滚、promote 等动作硬性设为 ask 确认，不允许 Agent 自主完成。
• 自托管，数据不出内网：所有组件自托管部署，不依赖外部 SaaS 托管控制面。

2.3 非目标#

为明确范围，以下事项不在本 RFC 的设计范围内：

• 不自研编码 Agent 内核：执行面使用 liskin，不自行开发 Agent 推理内核。
• Dispatcher 不做模型推理：控制面只做调度，不做任何模型调用。
• 不做云端 runtime：MVP 阶段只支持本地开发机上的 runtime，云端执行暂不涉及。
• 不锁定接口签名和数据表结构：本 RFC 只做架构设计，具体接口、schema、prompt 内容属于后续设计文档。

3.1 执行面：Core_Agent_Runtime#

目前 liskin（作者自建，设计思想参考pi） 是 OGAS 的 Agent 执行内核，后续会考虑通过SDK支持其他SOTA Agent（claude code，codex）liskin 的项目地址：https://github.com/Zhongye1/liskin_code_agent

现有能力。 liskin 的架构已经为"被外部调度"做好了准备。它的 Kernel 与 Client 是解耦的，对外通过 agent exec 提供 headless 的无头执行模式，内部走 InProcessKernelClient，天然适合被守护进程以 stdin/stdout 的方式驱动。liskin 自带 Harness 长任务框架，任务状态落在 .liskin/harness/ 目录里，节点可中断、可恢复、可审计——这正是任务级容错想要的底座。其 Sandbox 用路径白名单加命令黑名单，再叠加 auto/ask/deny 三档确认，给了在自动化链路里插入人工卡点的抓手。liskin 的内核与外壳解耦体现在三个端口上：LLMPort/ToolPort/StorePort，内核只跟抽象契约打交道，换模型、换工具来源、换存储都不动内核[15]。OGAS 正是利用 ToolPort 这一点，把外部能力作为 MCP 工具注入。

在建能力。 liskin 的 MCP client 支持目前处于 Phase-1 进行中，对 GitHub/Vercel 的集成也标注为在建。这两块能力明确会做完，其完整形态对齐 pi agent 的能力边界。也就是说，MCP 接入、GitHub/Vercel 的原生集成不是要不要有的问题，而是时间问题。排期假设是在阶段二、阶段三可以放心地把这些能力算进 liskin 的既定路线，不必自己造完整实现，只需在集成落地前用最小 shim 过渡。

对 OGAS 的意义。 liskin 为 OGAS 提供了执行面的全部基础：headless 模式让 Daemon 可以用进程方式驱动它；Harness 框架让长任务可中断可恢复；Sandbox 三档确认让高危操作可以拦截；三个端口让外部能力可以透明注入。OGAS 不需要修改 liskin 内核，只需在集成层做适配。

3.2 知识面：EagleRAG#

现有能力。 EagleRAG 已经是一个成熟的 MCP Server，提供 streamable HTTP 的 /mcp 端点和 stdio 两种接入方式。核心工具覆盖 ingest/query/retrieve，并用 plugin_namespace 到 Milvus 的映射做多租户隔离。

缺什么。 EagleRAG 当前是面向通用场景的知识检索服务，缺少面向团队协作的权限管理和命名空间封装。在 OGAS 中，不同业务线的 PRD、接口契约、UI 规范需要隔离，团队成员的检索权限需要按 workspace 区分。

对 OGAS 的意义。 将它改造成 OGAS-Arkhiv，主要是围绕权限和命名空间做团队化封装，底层检索能力可以直接复用。改造工作量不大，不需要改动 EagleRAG 的核心检索引擎。

3.3 控制面：Multica#

现有能力。 Multica 是一个开源的 Go 平台[24]，其形态可以作为控制平面底座。它的 Server 负责协调、workspace/issue/队列/权限管理和 WebSocket hub，明确不做模型推理也不做 Agent 执行[16]。它的 Daemon 装在开发机上，扫描本地的 AI CLI、注册 runtime、在隔离工作区里调用工具并返回结果。Runtime 是 daemon 与某个 AI 工具的配对，目前只支持本地，云端在等候名单上。任务通过 WebSocket 下发，状态机是 Queued → Dispatched → Running → Completed/Failed/Cancelled，带 dispatch 五分钟、running 两个半小时的超时和可重试的失败处理，而且它原生就支持 pi runtime[17]。它以 Docker Compose、二进制或 K8s 自托管。

缺什么。 唯一缺的是跨任务的 DAG 编排——这恰好是 OGAS-Flow 要自建的那一层。此外，Multica 假设的是全自主执行，没有 human-in-the-loop 的 ask 通道，而 OGAS 要求生产回滚、promote 这类高危动作必须人工确认。

对 OGAS 的意义。 Multica 的 Server/Daemon 双进程结构、任务状态机、WebSocket 枢纽正好是控制面需要的东西。fork Multica 后，改动集中在五处（详见第四节 4.2），不侵入核心调度路径，方便周期性 rebase 上游。但有一个前置合规风险：Multica 的许可证为 NOASSERTION（非标准开源许可），商用和二次开发的合规性需要法务确认，这直接决定 fork 路线是否成立。

3.4 部署面：Vercel#

现有能力。 Vercel 的构建与发布是解耦的。它的 Deployment Checks 能以阻塞式检查的形式，在生产构建完成、域名分配之前把版本卡住，检查可以通过 GitHub Actions 或 Checks API 的 webhook（deployment.created/ready/succeeded/error）来驱动。它的 Instant Rollback（vercel rollback [id|url]）把域名指回上一个部署，不需要重新构建[18]。检查到底阻塞还是不阻塞，以及超时后放行还是拦截，都由开发者按项目自行配置。

缺什么 / 需要注意的坑。 回滚之后自动分配会被关掉——版本被 pin 住，后续想恢复正常发布得走 vercel promote 才能恢复。这一步在流程里必须显式记住，否则部署会莫名其妙不生效。

对 OGAS 的意义。 Vercel 的 Deployment Checks 天然适合做成 OGAS-Flow 里的 GATE 节点：构建完成后触发 liskin 验证，验证结果通过 Checks API 回写，通过则放行上线，不通过则拦截。回滚作为兜底手段，由人工确认后触发。

3.5 编排面：学术与工业参考#

关于编排层怎么工程化实现，近期的学术与工业工作给出了相当一致的方向，以下四条结论共同支撑了 OGAS-Flow 的设计取向：

• Agint 把软件工程任务先编译成图再执行，主张即便 AI 步骤不确定、图的执行也要保持确定，并用 SHIM 节点做"含 AI 组件却仍确定性推进"的混合执行[19]。
• 微软 Conductor 论证了"结构已知的工作流不该让 LLM 动态路由"，而应把编排做成声明式、确定性、消耗零 token 的一层，并把执行、上下文流转、人工监督显式拆开[20]。
• OrchBench 给出了"把编排计划从执行中剥离、用确定性模拟单独评估"的方法，沿结构、覆盖、缺失子任务、依赖正确性、冗余、并行合理性六个维度检验 DAG[21]。
• Temporal / durable execution 的成熟做法是用事件历史确定性重放来替代手搓状态机，实现崩溃恢复[22]。

这四条结论的共识是：编排的确定性部分和 Agent 的非确定性部分要彻底分开，不确定性全部关进节点内部，节点之间的推进保持确定、零推理、可单独验证。OGAS-Flow 逐条落地这四点，具体设计见第四节 4.4。

第一步：任务发起（飞书群 → OGAS-Gate）#

团队成员在飞书群里 @机器人，用自然语言下达指令——比如"让 liskin-frontend 实现登录页"。OGAS-Gate 作为 IM 适配服务，接住飞书的事件回调，把群聊指令翻译成 Dispatcher 的 REST API 调用：创建 issue、指派 Agent、设定任务参数。Gate 不直连 Multica 内部数据表，而是走 Dispatcher 的 API facade 层（见 RFC 4.2 第四层改动），这样上游 schema 变化时只影响适配层。

如果任务属于某个 DAG 的一部分，Gate 还会通知 OGAS-Flow 有新节点需要编排。

第二步：DAG 编排（OGAS-Flow → OGAS-Dispatcher）#

OGAS-Flow 拿到 DAG 定义后，调用纯函数 next_ready(dag, completed_set) 计算当前哪些节点的前驱已全部完成、可以派发。这个函数是确定性的——不调用 LLM、不含随机数，给定相同输入永远输出相同结果。

对于刚启动的 DAG，入口节点没有前驱依赖，立刻进入 ready 状态。Flow 把 ready 节点对应的 issue 派发指令发给 Dispatcher："把这个 issue 派给 liskin-frontend runtime"。Flow 自己不执行任何代码，只做图推进。

第三步：任务派发（Dispatcher Server → Daemon）#

Dispatcher Server 收到派发指令后，查到 liskin-frontend runtime 注册在哪台开发机上，通过 WebSocket 通知那台机器上的 Daemon。

任务状态机随之流转：Queued → Dispatched。Dispatcher 有超时规则——派发后 5 分钟内 Daemon 必须接单（拉起进程），否则判超时；进入 Running 后有指定小时的执行窗口。瞬时失败（比如进程崩溃）由 Dispatcher 自己重试，重试耗尽后才向上层发出一个可区分的"重试已耗尽"终态，而不是普通 Failed。

Dispatcher 全程不碰代码、不碰密钥、不碰 prompt 内容。GitHub token、Vercel token、Arkhiv 的 MCP 端点都配在 Agent 级的 custom_env 里，Daemon 在 spawn 进程时原样透传，Dispatcher 只是转发。

第四步：Agent 执行（Daemon → liskin）#

Daemon 收到 WebSocket 通知后，在隔离工作目录里拉起 liskin agent exec 进程。任务描述通过 stdin 写入，结果从 stdout 拿回。Daemon 只管进程生命周期——拉起、喂提示词、收结果，不管 kernel 内部状态。liskin 的 Harness 框架自管内部的任务节点状态（落在 .liskin/harness/ 目录里），这两层状态刻意解耦。

liskin 在执行过程中通过 ToolPort 调用三类 MCP 工具：

• OGAS-Arkhiv：查询 PRD、接口契约、UI 规范等业务知识
• GitHub MCP：领 issue、读代码、开 PR、查 CI 结果
• Vercel MCP：触发部署、查询部署状态

这些工具调用对上层完全透明，Dispatcher 不感知 Agent 在用什么工具，Flow 同理。

第五步：结果回流与下游解锁#

liskin 执行完毕后，结构化结果从 stdout 返回给 Daemon，Daemon 回传给 Server，任务状态流转为 Completed / Failed / Cancelled。

这条终态事件同时推给两个消费者：

• OGAS-Flow：消费 Completed 事件，把该节点加入已完成集合，重新调用 next_ready 计算下游是否有新节点解锁。如果有，立刻把下游节点派发给 Dispatcher——整个链路自动推进，不需要人手动衔接。
• OGAS-Gate：把状态流转翻译成飞书群消息推回给团队。回流粒度可配置（全量模式 / 终态模式 / 混合模式），让团队看得见 Agent 跑到了哪一步。

如果进程崩溃，Dispatcher 重启后，Flow 不需要从 checkpoint 恢复——把 Dispatcher 的终态事件流重放一遍就能重建当前的已完成集合，再调用 next_ready 继续推进。这就是事件溯源的基本思路。

旁路：高危操作的人工确认通道#

当 liskin 的 Sandbox 遇到 ask 档操作（比如生产回滚、promote），原本单向的"派任务—回结果"链路会切换成双向交互子通道：

liskin 抛出 ask 提示 → Daemon 通过 WebSocket 上报 Server → Server 推给 Gate → Gate 在飞书群里高亮告警。但实际的确认动作不在群消息里完成——成员需要跳转到有更强身份校验的界面（比如飞书内嵌 H5 审批页）。确认后，决策沿原路回灌：Gate → Server → Daemon → liskin 的 stdin，Agent 继续执行或终止。

这条 ask 通道复用现有的 WebSocket 连接基础设施，是原生 Multica 没有、OGAS 必须加的一段设计。

4.0 架构总览#

OGAS 的四层架构如下：

• 入口面（OGAS-Gate）：连接飞书群聊和 Dispatcher，是团队成员发起任务的统一入口。
• 编排面（OGAS-Flow）：维护 DAG 依赖关系，消费 Dispatcher 的任务终态事件，按依赖解锁下游节点。
• 控制面（OGAS-Dispatcher）：中心化任务调度器，把任务派到正确的开发机和 Agent 上，跟踪状态，不做模型推理。
• 执行面（liskin + MCP 工具）：编码 Agent 内核，通过 ToolPort 注入业务知识库、GitHub、Vercel 三类 MCP 能力。

核心设计原则是控制面与执行面分离：Dispatcher 只做调度和状态跟踪，永远不碰代码、不碰密钥、不碰 prompt 内容；编排层保持确定性，不介入 Agent 内部推理。这条原则贯穿所有设计决策，后面每一层的设计都建立在这个前提上。

4.1 执行面：liskin#

liskin 是 OGAS 的编码 Agent 执行内核。它在系统中的角色是"被 Dispatcher 驱动的编码引擎"——收到任务后自主完成代码编写、测试、提交，完成后返回结构化结果。

4.2 控制面：OGAS-Dispatcher#

OGAS-Dispatcher 是中心化任务调度器。它解决的问题是：团队里有多台开发机、多个 Agent 实例，需要一个中心组件把任务派到正确的机器、正确的 Agent 上，并跟踪每个任务跑到了哪一步。Dispatcher 自己不做任何模型推理、不执行任何代码、不接触密钥和 prompt 内容——这条边界是后续所有设计的前提。

输入输出。 Dispatcher 对上给 OGAS-Flow 提供任务状态事件（Completed / Failed / Cancelled），对旁给 OGAS-Gate 提供建/派/查 issue 的 API，对下通过 Daemon 把任务派给 liskin 执行。

4.3 入口面：OGAS-Gate#

OGAS-Gate 是 OGAS-Dispatcher Server 之外的一个适配服务，一头连飞书事件回调，一头连 Dispatcher 的 API 和 WebSocket。它的角色是"IM 到系统的翻译器"——把群聊里的自然语言指令翻译成 Dispatcher 的 API 调用，把 Dispatcher 的状态事件翻译成群消息推回给团队。

4.4 编排面：OGAS-Flow#

OGAS-Flow 是一个 DAG 编排器。它解决的问题是：多个研发任务之间存在先后依赖关系（比如"先实现功能，再写测试，再提交 PR，再部署"），需要一个组件按依赖顺序自动串联执行。OGAS-Flow 坐在 Dispatcher 之上，消费 Dispatcher 的任务终态事件来解锁下游节点。它本身不执行代码、不调用 LLM，只做确定性的图推进。

1
# DAG 示例：从 issue 到上线
2
dag:
3
    - id: implement
4
      type: AGENT
5
      issue: "实现登录页"
6
      agent: liskin-frontend
7
    - id: review-gate
8
      type: GATE
9
      depends_on: [implement]
10
      check: "pr_review_approved"
11
    - id: deploy
12
      type: GATE
13
      depends_on: [review-gate]
14
      check: "vercel_deployment_check"
15
    - id: verify
16
      type: AGENT
17
      issue: "验证线上功能正常"
18
      agent: liskin-frontend
19
      depends_on: [deploy]

4.5 知识面：OGAS-Arkhiv#

OGAS-Arkhiv 是业务知识库 MCP Server。它解决的问题是：编码 Agent 自带的代码侧检索只能理解代码结构，但无法理解 PRD 里写的"为什么要这么做"、接口契约里写的"这个字段代表什么"、UI 规范里写的"这个组件长什么样"、以及历史决策记录里的"为什么选了方案 A 而不是方案 B"。OGAS-Arkhiv 补上这块业务侧知识。

OGAS-Arkhiv 功能实现可参考 EagleRAG ，复用底层检索能力（Milvus 向量检索）。EagleRAG 已经是一个成熟的 MCP Server，提供 streamable HTTP 的 /mcp 端点和 stdio 两种接入方式，核心工具覆盖 ingest/query/retrieve，并用 plugin_namespace 到 Milvus 的映射做多租户隔离。相关工作集中在两方面：

• 权限封装：在 EagleRAG 的 plugin_namespace 机制上叠加团队/workspace 级别的权限控制，确保不同业务线的知识库隔离。
• 命名空间管理：把 PRD、接口契约、UI 规范、历史决策等不同类型的文档组织成结构化的命名空间，方便 Agent 按需检索。

4.6 部署面：Vercel 集成#

阶段一：验证 Agent 懂业务#

目标 先把执行面的核心假设跑通，不碰团队协作和编排。只回答"Agent 懂不懂业务"这一个问题。

做什么 单独部署 OGAS-Arkhiv，把一个真实业务线的 PRD 和接口文档灌进去，用 liskin 的 agent chat 手动验证它能通过 MCP 查到并用上这些业务知识。主要工作量在给 liskin 补 ToolPort 的 MCP client 实现——这是它路线图里"价值最大但尚未交付"的一项[15]。

验收标准 Agent 生成的代码显著贴合业务规范——具体表现为：Agent 在生成代码时能正确引用 PRD 中定义的接口契约，不出现对业务术语的臆测，生成结果经人工 review 确认业务逻辑正确率显著提升。

失败回退 停在这一阶段不影响任何已交付部分。即使 MCP client 未补齐，liskin 仍可独立使用，只是没有业务知识注入。

阶段二：协作可见#

目标 接入控制面和团队入口，让协作可见。

做什么 自托管 OGAS-Dispatcher，把 liskin 接成一个 runtime（即 4.2 节描述的 liskin provider），再接 GitHub MCP 让 Agent 从 issue 领任务、开 PR，同时上 OGAS-Gate 把任务创建和状态回流搬进群。这一阶段不涉及跨任务编排，也不接生产部署。

验收标准 团队在群里能看见并指派 Agent 干活——具体表现为：成员在飞书群 @机器人 指派任务后，Agent 自动执行并实时回流状态，终态结果可见、可 review。

失败回退 如果 Dispatcher 合规受阻（Multica 许可证问题），回退到阶段一的单机 agent chat 模式，不影响已验证的业务知识注入能力。

阶段三：闭合全链路#

目标 打通部署与编排，闭合全链路。

做什么 接 Vercel，把 liskin 的验证接成 Deployment Checks 发布门（GATE 节点）、把回滚设为人工确认的应急手段；同时上线第一版窄范围的 OGAS-Flow（仅线性串联），消费 Dispatcher 的 Completed 事件解锁下游，并在 DAG 上线前先跑一遍 dry-run 模拟校验。

验收标准 一串有依赖的任务能自动跑完并安全上线——具体表现为：从 issue 创建到 Vercel 部署上线的全链路自动执行，发布门拦截坏版本，回滚需人工确认且 pin 状态有告警。

失败回退 如果发布门不稳定，关掉 Check 回人工审批；如果 OGAS-Flow 失控，停编排回逐个手动派单。两者都不影响阶段二已交付的协作可见能力。

DAG状态#

在 Agent core 外自建一层 DAG，一旦分层没守住，整套系统会变成一个难以调试的分布式状态泥潭。具体有两个陷阱：

其一，别把 liskin 的 Harness 状态当成 Dispatcher 的任务状态。 liskin 自带 Harness 长任务框架，状态落在 .liskin/harness/ 里、节点可中断可恢复，那是任务内部的容错；Dispatcher 的状态机是任务粒度的（一个 task = 一次 liskin exec）。这两层必须解耦——Dispatcher 只看到"这个 task 在 running / 完成了"，liskin 内部跑了多少步是它自己的事。

其二，别让 Dispatcher 承担编排。 跨任务 DAG 是 OGAS-Flow 的职责，Dispatcher 只提供"单 issue 状态机"这块原子能力，Flow 坐在其上消费 Completed 事件来解锁下游，Dispatcher 对 DAG 的存在应当是无感的。如果让 Flow 节点去干预 Agent 内部步骤，或把 Harness 状态当 DAG 状态，上下层调度就会撞车，系统退化成分布式状态泥潭。这是自研部分里技术风险最高的一块。

文献给出的解法与我们的取向一致：把编排做成确定性、零推理的一层，不确定性全部关进 AGENT 节点内部，GATE/JOIN 只做确定判定与汇聚[20]。据此，第一版刻意做窄——只做线性串联和简单依赖解锁，不上条件分支、并行汇聚、自动补偿回滚，等任务粒度和失败语义在真实使用中稳定后再扩；同时用提交时校验加 dry-run 模拟，在真跑前把 DAG 的依赖正确性验掉[21]。

部署安全#

让 Agent 有能力触发生产回滚、promote 覆盖线上，本身是高危操作。叠加回滚后"钉住"部署的反直觉状态[18]，如果确认档配置不当或 Agent 误判，可能造成线上服务对象错乱。解决方案是把这类动作硬性设为 ask 人工确认（在 OGAS-Flow 里落成 GATE 节点），并把 pinned 状态显式落盘、在飞书群里高亮告警。高危操作的确认动作不在群消息里完成，而是跳转到有更强身份校验的界面。

端到端可观测性#

OGAS 的链路又长（OGAS-Gate → OGAS-Flow → OGAS-Dispatcher → Daemon → liskin → MCP 工具），一旦某个环节出问题，定位会很痛。这要求我们在自研部分就把结构化日志和 trace 串起来，而不是事后补。每一层都应该在请求入口打上 trace ID，逐层传递，使得一个任务从飞书消息到 Vercel 部署的完整链路可追溯。

执行机形态#

执行机的形态需要拍板：是人手一台常驻开发机各跑守护进程，还是内网集中搭几台专用执行机？后者的资源隔离、多任务抢占、运维归属都要有人认领。这直接影响 Dispatcher 的部署拓扑与 Daemon 注册策略。如果是人手一台，Daemon 注册策略相对简单（每台机器自注册自己的 runtime）；如果是集中执行机，需要设计资源池管理和任务排队策略。这个问题需要在阶段二启动前确定。

语言选型#

OGAS-Flow 的实现取向已基本收敛：不从零手搓、也不上重型编排器，而是走"纯 DAG 库负责图 + Dispatcher 的 Postgres 负责事件溯源 + 纯函数推进器"的轻量组合，第一版窄到只做线性串联与简单依赖解锁，把节点显式分成 AGENT/GATE/JOIN 三类、并在上线前用 dry-run 模拟校验依赖正确性[21]；扩到条件分支、并行汇聚、自动补偿时再升级为 durable execution 引擎[22]。仍待定的是和实际业务场景对齐——线性串联覆盖多少真实场景？是否有早期就需要并行汇聚的链路？

Gate 交互协议#

OGAS-Gate 的交互协议需要定义：哪些操作允许在群里直接触发（建 issue、指派、查状态大概率可以），哪些高危操作（触发生产回滚、promote）必须跳转到有更强身份校验的界面而非群消息一句话搞定。这与第四节 ask 双向通道、以及 OGAS-Flow 的 GATE 节点落点一致。具体的跳转目标界面（飞书内嵌 H5 审批页？独立 Web 审批系统？）和身份校验强度也需要定义。