NASDK 设计准则

NASDK 是面向多应用通信与长时任务的通用运行时。

NASDK 期望应用之间可以通信，任务可以被编排，有限资源可以被协调，运行过程可以被观察和介入。

本文暂时只记录已经落实在 NASDK 中的核心设计方向。更细的协议语义、状态转换和可靠性约束将在后续版本中继续补充。

应用身份独立于连接

NASDK 将一个能够独立运行并参与通信的程序称为 NApp。

NApp 使用稳定的 App ID 相互寻址，而不是直接依赖某条 WebSocket、TCP 或 Unix Socket 连接。

连接只是应用之间当前可用的传输路径。连接可以建立、断开和重建，应用身份及其正在进行的请求不应因此被重新定义。

这让业务代码可以面向目标应用发送消息，把连接管理、注册、路由和重连交给运行时处理。

NACP 定义 Request、Response、Subscribe、Notify、Signal 和 Ack 等应用语义，NACT 负责消息编码、分帧与重组以及具体传输承载。

两者保持分离，协议不关心消息经由 TCP、WebSocket 还是 Unix Socket 发送，传输层也不解释消息的业务含义。

这种分层让同一套应用 API 能够运行在不同环境中，也避免可靠性、路由和订阅关系散落到各个传输实现里。

NACP 只负责把请求交给符合 Processor 契约的处理器，不理解请求内部的业务。NASDK 默认提供两类 Processor：

应用可以替换 Processor，而不需要修改通信协议。相应地，NACEB 也不需要知道任务来自本地调用还是远程 NApp。通信解决“消息如何到达”，Processor 解决“工作如何执行”。

长时任务不仅有最终结果，还会产生过程输出，并可能在运行期间接收补充信息、暂停、恢复或终止。NASDK 因此不把所有工作压缩成一次普通 RPC，而是保留一次执行从进入队列到终结的完整身份和生命周期。

Event 表示一次完整任务，Pipeline 决定下一步执行什么，Task 完成一个具体动作。过程消息、Signal、SubEvent 和最终 Response 都围绕同一个执行关系组织，业务方不必额外维护一套相互独立的流式通道和控制通道。

GPU、模型实例和部分外部服务无法无限并发，但具体执行组件不应因此同时承担队列和资源调度职责。Task 可以声明执行所需的 busyKeys，由 NACEB 决定何时放行；TaskHandler 只负责完成一次具体执行。

资源竞争因而与任务生命周期统一管理，同时不侵入 Provider 或业务实现。没有资源冲突的任务仍可并发，等待网络或其他异步结果的步骤也不必占用无关资源。

连接、消息、Event、Pipeline 和 Task 的关键状态转换都应当可以被观察。观察接口不应改变执行结果；观察者失败也不应阻断主流程。

对于确实需要控制运行过程的场景，NASDK 提供显式的 Signal 和生命周期 Hook。观察与介入使用明确的协议和状态边界，而不是让外部代码直接修改运行时内部对象。

NASDK 是通用基础设施，不理解 Agent、Prompt、模型、工具调用或其他上层领域概念。这些语义应由建立在 NASDK 之上的框架或具体应用定义。

运行时只提供完成这些系统所需的通信、编排、资源协调和生命周期能力。保持这一边界，可以让 NASDK 服务于 AI Runtime，也可以用于任何需要多应用协作和长时工作流的系统。