Skip to main content
Huoban 遵循 standard-first、runtime-later：先稳定可验证的对象语言与证据契约，再让不同 agent、tool、MCP server 和 runner 对它做解释与绑定。

对象先于实现

先定义身份、引用、字段和边界，不把某个 runner 的内部结构提升为协议。

证据先于承诺

每项语义都必须落到 schema、example、CLI 输出或可审计状态。

重复先于晋升

私有实践只有在多个真实 workflow 中重复出现，才进入公共标准。

​
标准边界

公共标准负责定义：
  • 对象种类和 schema。
  • 身份、引用、必填字段、可选字段与兼容等级。
  • 验证、解释、导入和导出行为。
  • Trust、Policy 与 Checkpoint 的边界。
  • Requirement 的依赖类型、来源、审阅状态和 freshness。
  • Preflight 的 resolution、readiness、作用域、条件与证据格式。
  • Lifecycle Handler 的有限事件、delivery、binding、超时、重试和状态语义。
  • 能端到端复现真实工作流的 examples。
公共标准不负责定义：
  • 唯一 runner。
  • 唯一 agent。
  • 某一家公司的代码风格。
  • 某一家公司的架构规则。
  • 某一套私有工具链。
  • 适合所有项目的万能 workflow。
公司实践在证明可复用之前，留在私有 Profile、Policy、Adapter、Flow 与 Run 中。
Requirement、Preflight 和 Lifecycle Handler 是跨对象协议结构，不是新的顶层 Kind。只有拥有独立身份、生命周期、引用关系和治理边界的概念，才应该晋升为 Kind。

​
进入核心标准的条件

一个字段、枚举或协议结构进入核心标准前，必须同时满足：
  • 在至少两个真实 workflow 中出现。
  • 不绑定某一家公司、某一个仓库或某一个 agent。
  • 不依赖隐藏 prompt 行为。
  • 可以被 schema 验证。
  • 可以被 CLI 解释。
  • 提升的是互操作性，而不只是方便某一个实现。
如果证据不足，把它留在 extension、example、Adapter 或私有 Profile 中。不要用“以后可能需要”代替重复证据。

​
对象稳定等级

当前 schema 版本是 v1alpha1。它已经是可验证、可实现的协议版本，但仍属于 alpha 兼容阶段；新增语义必须同步更新 schema、examples、CLI、规范参考和迁移说明。

​
验证链

协议对象从“可解析”到“可执行”经过不同层次，任何一层都不能替代下一层。
1

Schema 验证

npm run validate 验证 Kind、字段、引用形状和有限枚举。通过只表示对象结构合法。
2

语义解释

npm run explain 展示 workspace 关系、requirements、lifecycle handlers 和 Run 证据，供人和 agent 审查。
3

锁定执行快照

npm run print:dry-run 把 Flow、Profile、Policy 与实现 binding 固定为 Run。它不执行业务能力。
4

执行前预检

npm run preflight 分开计算 resolution 与 readiness，并写入 Run conditions 和 Preflight Report Artifact。
5

授权与执行

runtime 只有在 Run 级 PreflightReady=True 后，才能考虑 Policy、Trust、Checkpoint 与执行授权。Preflight 本身不是授权。
stage 级 Preflight 只能诊断局部依赖，不能授权整次 Run；省略 Run.spec.mode 时按 execute 处理，同样必须通过 Run 级门禁。

​
发布就绪标准

一次公开发布至少应该满足：
  • npm test 全量通过，生成文件与命令输出一致。
  • 所有公开 schema 能独立编译，完整 examples 全部通过 npm run validate。
  • npm run explain 能给出连贯的 workspace 视图。
  • npm run print:dry-run 能生成有效、可复现的 Run。
  • npm run preflight 能生成有效 conditions 与 Preflight Report Artifact。
  • required 动态依赖在离线检查中保持 Unknown，不会被伪装为可用。
  • execute Run 只有在 Run 级 PreflightReady=True 时才可被 runtime 接受。
  • Lifecycle Handler 只使用固定事件枚举，并有 required 与 best-effort 的可验证示例。
  • README、简介、模型页和规范参考使用同一套术语与字段。
  • llms.txt 能给 AI agent 提供可靠入口。
  • 变更记录说明兼容影响与迁移路径。

​
实践反馈循环

1

捕获私有实践

用私有 Profile、Policy、Adapter 和 Flow 描述公司 workflow，并明确 requirements。
2

锁定并预检

先生成 dry-run Run，再对锁定快照执行 Run 级 Preflight。推断出的 Requirement 必须经过 review。
3

保留事实链

用 Checkpoint 记录决策，用 Artifact 保存产物与 Preflight 报告，用 lifecycle invocation 记录有限事件的投递结果。
4

比较重复证据

比较多个 workflow 中反复出现的字段、事件和失败模式，区分公共语义与公司约定。
5

晋升或保留

只把跨环境可验证的结构提升到公共标准；公司特定判断继续留在私有 Profile 与 Policy。

​
公司项目中要验证什么

真实项目应当回答：
  • Profile 是否能让 agent 比散落的 Markdown 更快理解项目？
  • 风险动作是否能被清楚表达成 Policy？
  • AGENTS.md、CLAUDE.md、Cursor Rules 和 SKILL.md 是否能通过 Adapter 或 Profile 保留原意？
  • Flow 是否能描述真实工作，而不是把逻辑藏进 prompt？
  • Run snapshot 是否能让 AI 工作在事后可审查？
  • Checkpoint 是否能在正确位置形成显式决策？
  • Artifact 是否能记录产物、引用、hash 与审阅状态？
  • Requirement 是否能在执行前发现缺失的 skill、MCP tool、runner capability、上下文源与凭据？
  • Preflight evidence 是否足以解释一个 Run 为什么机械就绪，或被依赖问题阻断？行为是否允许仍由 Policy、Trust、Checkpoint 与平台治理决定。
  • Lifecycle Handler 是否能完成 stage 后上报，而不把业务状态改变藏进 handler？
只有这些问题在真实项目中产生重复证据，标准才应该继续演进。

​
非目标

当前不进入公共标准：
  • 在对象模型验证前做完整 runtime。
  • 在 Lifecycle Handler 契约稳定前做通用事件 dispatcher。
  • 在 trust 语义清楚前做 hosted registry。
  • 在 adapter 质量可衡量前做 marketplace。
  • 在文本对象稳定前做 visual builder。
  • 在真实 workflow 被理解前做万能 flow generator。
Huoban 的第一责任不是覆盖所有执行场景，而是让已经声明的工作在执行前可验证、执行中有边界、执行后可审计。