AragonTeam 企业 AI 原生人机协同工作站

被收敛的不确定性

运行形态、能力边界与调用点分支随执行体类型扩散；第三方 CLI 运行在伪终端中，界面由对方定义、无程序化协议；十余个消费方各需不同模型档位，换模型时连接参数分散、静默替换偏离预期；程序侧与智能体侧接收能力不同，两套逻辑造成语义漂移。

核心机制

① 声明式注册表：类型清单统一描述身份、运行形态、输入能力与启动约束，注册表作为唯一访问面向调度面提供稳定类型视图。② 协议外投递闸门：唯一输入闸门统一封装、统一提交语义与审计入口。③ 能力槽位解析：消费方只声明用途，模型预设承载自包含连接参数，两层间接。④ 统一事实封装：同一业务事实只在服务端封装一次，再按接收端能力选择投送形态。

关键设计与工程参数

• 严格判等路由（前缀混淆 → 精确匹配）；创建 · 停止 · 重启 · 删除资源闭环
• 括号粘贴边界 + 延迟提交键保证多行一次提交；三级降级：单行直投／短多行折叠／落盘 + 读取指令
• 四级回退链：槽位绑定 → 节点级覆盖 → 兜底主槽位 → 稳定错误码中止
• 程序侧 84+ 消息类型／64 KB 分片／30·60 秒心跳／1 MB 背压；智能体侧 withFileLock 串行写入，重启后仍可读

工程价值

把「按类型补分支」升级为「按声明驱动调度」——异构执行体统一描述、能力边界显式声明、模型与通信集中治理，新类型接入不再改调用路径。

要处理的运行事实

结构化计划若从对话文本里解析随时会解析错；调度语义、外部进程语义与状态机事件各说各话；直线流程无法表达「评审 → 修改 → 再评审」；单一迭代上限要么太粗、要么挡不住多个小循环叠成的失控；无输出不等于失败（正常等待 / 进程挂死 / 虚假完成）；重启后无法判断跑到哪一步、该重跑多少。

核心机制

计划由受限工具调用产出而非文本解析；把调度、进程与状态机三者收束到一次节点执行的闭环（提示词构造 · 工具注入 · 就绪判定 · 伪终端执行 · 状态推进 · 回调收口）；运行期决定后继，一套逻辑统一处理剪枝、正常路径与回边重入；节点上限表达业务边界、全图硬上限提供系统兜底；先登记等待契约再持续探测，由调度器代替智能体探测；恢复建立在 Execution × Node Run 这一唯一事实源之上。

关键设计与工程参数

• 同源合法性校验：依赖存在性、自依赖、环检测、孤立节点、起止节点必备
• 启动预算 3 次／启动确认 8 秒／静默兜底 60 秒／12 个回调端点
• 决策超时 60 秒／最大重试 2 次；软停三阶段：广播 → 排空 30 秒 → 强切
• 默认节点上限 1／全图硬上限 100；重置策略 none · clear · archive
• 软超时 24 小时／硬超时 7 天／探针 60 秒／进度下限 30 秒
• 跨重启 running → interrupted；恢复串行 + 10 秒优雅停机

工程价值

把「提前固定每一步和重复次数」升级为「根据运行结果决定下一步与是否返回」——节点执行有边界、有守卫、有回收，长作业可观测、可唤醒、可追责。