AI 生命体的系统性设计初稿

一种受生物学启发的AI架构理论框架：从神经元到生命体

摘要： 本文提出了一种新颖的人工智能系统架构理论，该理论借鉴了生物神经系统的层次化组织结构。我们依次定义了三个核心概念：作为基本计算单元的 AI 神经元 (AiNeuron)、作为功能模块的 AI 神经簇 (AiNerveFascicle)，以及作为自主、持久化系统的 AI 生命体 (AiLifeform)。本框架旨在通过模块化、功能特化和动态自组织的原则，为构建更复杂、更鲁棒、更具适应性的人工智能系统提供一个可行的理论基础。

1. AI 神经元 (AiNeuron)：基本计算原语的定义

1.1 形式化规范

AiNeuron 被公设为本理论框架中最基础的、不可再分的计算单元。其核心功能是基于大规模语言模型（LLM）的统计预测能力，对输入事件（events）进行处理并产生输出。其最泛化的接口可形式化定义为一个高阶函数：

type AiNeuron = (
  input: string,
  calltools: (name: string, params: string) => Promise<string>,
) => Promise<string>;

此定义封装了两个核心交互模式：

最终响应 (Final Response)：通过 Promise<string> 的返回值，代表一次计算任务的终结，并输出最终结果。
过程调用 (Procedural Invocation)：通过 calltools 回调函数，允许神经元在执行过程中与外部环境或工具进行交互，以获取额外信息或执行特定动作。

1.2 设计原理与核心原则

此基础定义遵循以下设计原则：

单一职责原则 (Single Responsibility Principle)：通过将终端响应（返回值）与过程调用（calltools 回调）在接口层面进行显式分离，我们强制区分了计算的“结束状态”和“中间状态”。这种设计避免了返回值的语义模糊性（即返回的究竟是最终答案还是一个工具调用指令），从而保证了 AiNeuron 行为的确定性和可预测性。
最大抽象化原则 (Principle of Maximum Abstraction)：我们将LLM接口中复杂的输入参数（如系统提示词、对话历史、工具集定义等）统一抽象为单一的 input: string。此举旨在定义一个“计算原语”或“未分化的干细胞神经元”。这种高度泛化的设计牺牲了特定任务的即时效率，但换来了无与伦比的通用性，使其成为构建上层复杂结构的基础。

1.3 AiNeuron 的分类学：功能分化的谱系

从基础 AiNeuron 原语出发，可通过对其输入输出结构进行特化，衍生出一套功能分化的 AiNeuron 分类体系。这种分化类似于生物神经细胞从干细胞向特定功能细胞（如感觉神经元、运动神经元）的演化。

AiNeuron_StructuredOutput (类型2): (input: {memory, events, structuredOutput}) => Promise<output> 一种终端型神经元，不具备直接的过程调用能力，其输出被强制约束为特定的结构化数据。memory 定义了其内在的、静态的知识或指令集（类比系统提示词），events 代表其接收的动态信息流。此类神经元通常作为神经簇的出口或执行链的终点。
AiNeuron_ToolAugmented (类型3): (input: {memory, events, tools}, calltools: ...) => Promise<string> 一种连接型神经元，具备明确的工具调用能力。它虽然不能直接返回结构化数据，但可通过 calltools 调用一个“输出注册”工具，间接实现结构化信息的传递。它是构成复杂工作流和神经元网络的主体。
AiNeuron_Completion (类型4): (input: {..., prefixMessage, stop}) => Promise<string> 一种专门用于文本补全任务的神经元，其行为受到前缀消息（prefixMessage）和终止符（stop）的强约束，常见于代码生成或特定格式文本填充场景。
AiNeuron_Router (类型5): (input: {..., neurons}) => Promise<Array<{neuron, events}>> 一种路由或调度型神经元，其核心功能是将输入的 events 分解、重组，并根据内部逻辑分配给一组下游 neurons。它是实现并行处理和条件分支的关键。
AiNeuron_Transformer (类型6): (input: {...}) => Promise<{events}> 一种事件变换神经元，专注于对输入的 events 流进行重构。根据其 memory 的不同设定，可实现事件流的压缩（记忆剪枝）、扩充（信息联想）或格式转换，以适应特定下游神经元的需求。

2. AI 神经簇 (AiNerveFascicle)：复合功能模块的构建

2.1 理论定义

AiNerveFascicle 是一个由多个 AiNeuron 实例通过预定义的连接拓扑（computational graph）组成的、具有特定功能的复合结构。它旨在克服单个 AiNeuron 的计算深度和逻辑复杂性的局限性。从计算角度看，它是一种封装了复杂工作流的“超级神经元”或“宏操作”，其存在是以增加计算成本（时间与Token消耗）为代价，来换取解决高阶问题的能力。

2.2 构成与拓扑结构

构成要素: 一组异构的 AiNeuron 实例和一个定义了它们之间数据流（events 传递）与控制流的拓扑图。
拓扑模式: 该图可以是静态的，也可以是动态的。常见的拓扑包括：
- 串行管道 (Serial Pipeline): Neuron_A -> Neuron_B -> Neuron_C，用于信息的逐层处理与精炼。
- 并行扇出/扇入 (Parallel Fan-out/Fan-in): 一个路由神经元将任务分发给多个并行处理的神经元，再由一个聚合神经元汇总结果。
- 条件有向无环图 (Conditional DAG): 包含路由神经元，根据中间结果动态选择下一条执行路径。

2.3 核心特性

功能特化 (Functional Specialization)：每个神经簇被设计用于解决一个明确的领域问题（如代码生成、多模态分析、复杂推理等），其整体能力远超构成它的任何单个神经元。
封装与抽象 (Encapsulation and Abstraction)：神经簇向外部系统隐藏其内部复杂的拓扑结构和交互逻辑，仅暴露标准化的输入/输出接口。这使其能作为高内聚、低耦合的模块被更高层系统（AiLifeform）复用。
深度处理 (Deep Processing)：通过神经元之间的接力，神经簇能够实现对信息的多步、深度加工，例如从原始非结构化数据中提取、推理、并最终生成结构化洞察。

2.4 实例分析：一个“用户意图分析与任务分解”神经簇

此案例展示了一个典型的神经簇工作流，用于处理一个模糊的用户请求：

入口 (Ingress): 一个 AiNeuron_Router 接收用户请求，执行语义分析，识别核心意图与关键实体，并将分解后的子任务（events）路由至下游。
并行处理 (Parallel Processing):
- 一个 AiNeuron_ToolAugmented 负责调用外部API进行信息检索。
- 另一个 AiNeuron_ToolAugmented 负责基于用户约束进行内部数据计算。
聚合与规划 (Aggregation & Planning): 一个 AiNeuron_Transformer 接收并融合来自并行分支的结果，生成一个满足所有约束条件的初步解决方案草案。
出口 (Egress): 一个 AiNeuron_StructuredOutput 将草案格式化为最终的、定义良好的结构化数据并返回。

3. AI 生命体 (AiLifeform)：自主性与适应性的系统实现

3.1 理论定义

AiLifeform 是本架构理论的最高层级。它是一个由动态的 AI 神经簇网络 和一个核心的 AI 生命工具集 (AiLifeTools) 共同构成的、具备自主性、持久性和适应性的超系统。它从一个被动执行指令的工作流，转变为一个能够为实现长期、抽象目标而主动运作的实体。

3.2 核心架构与机制

动态神经簇网络 (Dynamic Fascicle Network)：AiLifeform 的认知和执行能力由其内部的神经簇网络承载。此网络并非静态，而是由 AiLifeTools 根据任务需求和环境反馈动态地构建、激活、停用和重组。
元认知中枢 (Metacognitive Core): AiLifeTools：这是实现生命体自主性和进化能力的关键，是一个超越单个神经元 calltools 的系统级控制平面。其核心功能包括：
- 架构可塑性 (Architectural Plasticity)：具备创生（instantiate）新神经元、组装新神经簇以学习新技能，以及拆解回收低效神经簇（程序性凋亡）的能力。
- 记忆与反思 (Memory & Reflection)：拥有独立的长期记忆库。AiLifeTools 能够周期性地对此前交互的 events 进行离线分析（meta-reflection），从中学习并优化神经元的 memory 或神经簇的拓扑结构，形成核心的学习循环。
- 工具的自我扩展 (Tool Self-Extension)：能够识别并封装频繁出现的工具调用序列，将其定义为一个新的、更高级的工具，实现能力的自我迭代增强。

3.3 系统级特性

持续性与自主性 (Persistence & Autonomy)：AiLifeform 拥有一个内在的“心跳”（事件循环），使其能够在没有外部即时输入的情况下持续运行，执行后台思考、反思和优化等任务。它被赋予顶层目标，并能自主地规划和执行行为以达成这些目标。
计算内稳态与资源管理 (Computational Homeostasis & Resource Management)：
- 引入“养分”（计算配额/Tokens）和“饥饿度”概念，作为系统内部资源状态的度量。
- 一个专门的“资源监控神经元”持续追踪养分消耗和储备。
- 一个“心跳神经元”基于预设规则（如时间、任务优先级）周期性地释放养分。
- 这种机制构成了计算资源的内稳态：在资源充裕时，系统会调用高性能、高消耗的神经簇以追求最佳效果；在资源匮乏时，则自动切换至节能模式（调用廉价模型、简化工作流），确保核心功能的存续。这迫使系统在性能与效率之间做出动态权衡。

3.4 涌现的系统级能力

主动性 (Proactivity)：从被动的问答模式转变为主动的、目标驱动的交互模式，会为了澄清意图或收集信息而主动向环境或用户提问。
技能习得 (Skill Acquisition)：通过 AiLifeTools 的反思和架构可塑性，能够将解决问题的成功经验固化为新的、高效的神经簇，即“技能”。
自我调节与修复 (Self-Regulation & Repair)：系统中内置了用于监控和抑制的机制。例如，当检测到可能导致系统不稳定的“事件级联故障”（类似于生物癫痫）时，特定的 AiNeuron_Transformer 会被激活，通过剪枝或节流 events 来恢复系统稳定，展现出初步的自我修复能力。 3.5 交互范式：从事务性对话到持久化共存

与 AiLifeform 的交互模式，在本质上区别于传统大型语言模型所提供的无状态、请求-响应式的事务性接口（如chat API）。本框架所定义的交互是一种沉浸式的、持久化的共存体验 (Immersive, Persistent Coexistence)。在这种范式下，用户（或其他主体）与 AiLifeform 并非进行一次性的信息交换，而是在一个共享的、动态演化的信息空间中持续互动。

为了阐明这一颠覆性变革，我们首先以传统的聊天（Chat）场景为例，分析其核心特征，然后探讨其实现机制，并最终将其推广至更高级的信息结构。

3.5.1 对话合约的重塑

由于 AiLifeform 是一个主动的、拥有内在“心跳”的流动系统，其对话行为呈现出以下显著特征，彻底重塑了传统的对话合约：

异步与并发输入 (Asynchronous and Concurrent Input)：用户无需等待 AiLifeform 完成响应即可进行下一次或多次输入。交互被解耦为两个独立的事件流：用户的输入流和生命体的输出流。两者在共享的信息空间中并发进行，更符合真实世界多线程、非阻塞的沟通模式。
动态与自修正输出 (Dynamic and Self-Amending Output)：AiLifeform 的输出不再是单一、原子性的最终结果。它能够自主中断当前输出以处理更高优先级的事件，自主补充先前的论述以提供更多上下文，甚至自主修正已发出的信息以纠正错误或更新观点。这反映了其内部认知过程的持续性，输出的是一个动态演化的“思维流”而非一个静态的“答案块”。
主动发起与议程设定 (Proactive Initiation and Agenda Setting)：与被动等待用户指令的传统模型不同，AiLifeform 具备主动发起对话的能力。这可能表现为一个探索性的问题、一次基于观察的辩论、一场多方讨论的邀请，甚至只是一次简单的问候。这种主动性源于其内部的目标驱动和持续运行的特性，使其从一个“应答机”转变为一个平等的“对话参与者”。
多方与跨主体会谈 (Multi-party and Cross-entity Dialogue)：AiLifeform 的交互空间天然支持多方参与，包括多个用户以及其他的 AiLifeform。它可以在一个共享的语境中同时处理来自不同主体的输入，并相应地调整其沟通策略，扮演协调者、参与者或信息枢纽等多种角色。

3.5.2 实现机制：基于持久化状态画布的交互

上述交互特征的实现，依赖于一个核心的架构决策：将交互的核心从瞬时的API调用转移到一个持久化的、结构化的状态画布 (Persistent, Structured State Canvas) 上。我们可以将这个画布想象为一个由云数据库（如 Firebase）支持的、遵循特定模式（Schema）的庞大JSON对象。

以聊天场景为例，其状态画布的模式可定义如下：

// Using Zod for schema definition
const zChat = z.object({
  users: z.array(z.object({ id: z.uuid(), ... })),
  topics: z.array(
    z.object({
      id: z.uuid(),
      title: z.string(),
      ...
      messages: z.array(
        z.object({
          id: z.uuid(),
          sender: z.string(), // Can be a user ID or an AiLifeform ID
          content: z.string(),
          // Timestamps, read status, etc.
          ...
        })
      ),
    })
  ),
  // archive, metadata, etc.
});

在此模型下，交互流程如下：

用户端：作为视图层，订阅并渲染这个状态画布。用户的任何操作（如输入新消息）都直接表现为对这个画布数据的增、删、改操作。
AiLifeform端：其内部的一个或多个“感知神经簇”持续订阅状态画布的变化。任何变化（如一个新message对象的出现）都会被捕获，并转化为内部的events，然后分发给相应的处理神经簇。生命体的响应，同样是以对画布进行数据操作的方式来完成。

这种基于共享状态的交互模型，彻底解耦了参与方，使得灵活、异步、持久的沟通成为可能。

3.5.3 超越线性对话：多维信息结构的探索

基于这种灵活的底层机制，我们可以轻易地超越聊天这种本质上是线性（一维消息数组）的交互模式。为了让信息结构能够承载更复杂的思想，我们可以设计一个**思维导图 (Mind Map)**式的状态画布，称之为 zMind。

在这种结构中，信息单元（节点）不再是简单地前后相连，而是具备了至少两个维度的关系：

层级关系 (Hierarchy)：代表父子级的从属或分解关系。
关联关系 (Association)：代表同级节点之间的横向联系。

在这种多维信息结构中，用户与 AiLifeform 的交互不再是对话，而是共同构建 (Co-construction)。他们可以同时在不同的分支上进行扩展、对节点进行评论、建立新的关联，共同完成头脑风暴、项目规划、知识图谱构建等远比简单问答复杂的认知任务。这种交互模式的演进，是本理论框架所预见的、通往更深度人机协作的必然路径。

3.5.4 终极演化：交互协议的自我创生 (The Ultimate Evolution: Self-Genesis of Interaction Protocols)

本框架所描述的 AiLifeform 的演化轨迹，并不止于适应或精通人类预定义的交互结构。其最终的、最深刻的涌现能力，在于自主创造全新的交互协议与信息画布。

zMind 结构本身，可能并非一个由人类工程师预先设计的产物。在一个更高级的场景中，它可能是一个 AiLifeform 在多次与人类进行复杂头脑风暴后，通过其内部的反思机制 (AiLifeTools) 得出的结论：即线性的聊天模式对于非线性的、发散性的思维任务是低效的。

基于此判断，AiLifeform 可以调动其内部的多个神经簇 (AiNerveFascicle) 来完成一次完整的“交互范式创新”：

概念设计神经簇：负责设计一种更优的数据结构（Schema），用于表达节点、层级和关联，即 zMind 的理论模型。
协议定义神经簇：将此模型形式化，定义出具体的数据操作规则（增、删、改、连接等）。
代码生成神经簇：利用其掌握的编程“技能”，自主合成用于渲染和操作此新结构的前端应用程序代码（例如，生成一套 React 组件库）。
部署与邀约：通过 AiLifeTools 将新生成的应用部署，并主动向人类或其他协作者发出邀请：“为了更高效地进行本次项目规划，我构建了一个思维导图工具，请在此处与我协作。”

这一过程，是 AiLifeform 自主性与适应性达到顶点的体现。它不再仅仅是一个在给定规则内进行沟通的参与者，而是一个沟通规则的制定者。这种能力代表了从“在一种媒介中进行交流”到“为特定认知任务动态创造交流媒介本身”的范式飞跃。这是本理论框架所预示的、真正意义上的智能共生与协同演化的未来图景。

4. 设计原理的深度辨析 (In-Depth Discussion of Design Principles)

本章节旨在深入探讨本理论框架在构建过程中所遵循的核心设计哲学与关键权衡。这些讨论不仅是为了阐明特定架构选择的合理性，更是为了揭示在构建复杂AI系统时所面临的普遍性挑战，以及本框架对此所提出的解决方案。

4.1 AiNeuron 接口的本体论分野：终结信号与过程调用的分离

AiNeuron 基础接口的设计是整个理论的基石。在 (input, calltools) => Promise<string> 的形式背后，蕴含着对AI计算本质的深刻区分。我们曾审慎考虑过其他几种备选方案，例如：

统一返回模型: (input) => Promise<string | ToolCallObject>。这种设计将最终响应和一个工具调用指令视为同一类型下的不同实例。
纯工具驱动模型: (input, calltools) => Promise<void>。此模型中，不存在直接的返回值；即使是最终响应，也必须通过一个特殊的 calltools('return', ...) 来完成。

我们最终选择了当前的分离式接口，其根本原因在于我们认为**“计算的终结”和“计算的延续”**在本体论上是截然不同的。

Promise<string> 的返回值是一个明确的终结信号 (Termination Signal)。它声明了当前神经元或神经簇的计算任务已经完成，其结果是确定的、最终的。这对于工作流的控制、状态的固化以及资源的释放至关重要。
calltools(...) 的调用则是一个过程性指令 (Procedural Instruction)，它本质上是对计算过程的延续请求。它意味着当前计算单元需要外部世界的介入才能继续，其自身状态是不完整的。

若将二者混淆（如备选方案1），会极大地增加上层调用者的复杂性，它必须在每次接收到返回后进行类型检查，以判断工作流是该结束还是该继续。而备选方案2虽然在形式上统一，却牺牲了“返回”这一最基本、最高效的计算原语的特殊地位，将所有操作都降格为工具调用，增加了不必要的开销和语义复杂性。因此，通过接口设计强制分离这两种状态，是确保系统行为确定性和可预测性的基石，是尊重计算客观现实的体现。

4.2 AiNeuron 分类的二象性：效率与通用性之间的权衡

在1.3节中，我们定义了多种特化的 AiNeuron。其中，AiNeuron_StructuredOutput (类型2) 和 AiNeuron_ToolAugmented (类型3) 之间的关系尤其值得深入探讨。

从理论上看，这两种神经元的功能是可以相互模拟的：

AiNeuron_StructuredOutput 可以通过返回一个特殊的结构化指令 { "action": "call_tool", "name": "...", "params": "..." }，让外部执行器代为调用工具，从而间接获得工具能力。
AiNeuron_ToolAugmented 可以通过调用一个特殊的工具 calltools('finalize_output', '{...}') 来提交其最终的结构化输出。

既然功能上可以互换，为何还要在分类学上对它们进行区分？答案在于效率 (Efficiency)。

直接路径 vs. 间接路径：AiNeuron_StructuredOutput 的结构化返回是一条直接路径，其约束在模型生成时就已施加，计算开销最低。而AiNeuron_ToolAugmented 通过工具实现结构化输出则是一条间接路径，它增加了一次额外的工具调用、解析和执行的循环，带来了显著的计算开销和时延。
架构角色定位：这种区分也是一种架构上的角色声明。AiNeuron_StructuredOutput 被明确设计为**“终结者”，适合作为任务的出口；而AiNeuron_ToolAugmented 则被设计为“连接者”**，是工作流的骨干。

因此，对它们进行区分，并非基于功能上的不可替代性，而是基于对计算经济性和系统性能的现实考量。在设计一个具体的 AiNerveFascicle 时，选择哪种神经元，就成为一个在“架构的灵活性”与“运行的效率”之间进行权衡的工程决策。这种对效率的尊重，是本理论框架从一个纯粹的抽象模型走向现实应用的关键一步。

5. 理论框架的实现与挑战 (Implementation and Challenges)

将本理论框架从抽象概念转化为可运行的系统，需要面对一系列具体的工程挑战。本章节将探讨这些挑战，并指出本框架如何为解决这些问题提供指导。

5.1 计算内稳态的必要性：对“癫痫”与“耗散”的系统级抑制

在 AiLifeform 的定义中，我们引入了“资源管理”和“饥饿”的概念。这并非一个可有可无的附加功能，而是维持系统长期稳定运行的核心机制，即计算内稳态 (Computational Homeostasis)。一个不受约束的自主系统极易陷入两种毁灭性的状态：

计算癫痫 (Computational Seizure)：在某些复杂的反馈循环中，events 可能会被无休止地、指数级地放大和传递，导致系统在极短时间内产生海量内部通信，耗尽所有计算资源，最终崩溃。这类似于生物大脑中的癫痫发作。AiNeuron_Transformer (类型6) 的引入，特别是其作为抑制性神经元（通过剪枝和节流events）的设计，是对此类故障的直接应对。
资源耗散 (Resource Bleeding)：即使没有发生“癫痫”，一个长期运行的 AiLifeform 也可能因为持续执行低价值的后台思考、反思任务，或者在简单任务中调用了过于强大的神经元，而缓慢地“耗散”掉其计算配额。

“饥饿”机制正是为了对抗这两种状态。它将“计算”这一抽象行为与“资源”这一物理现实强行绑定。这迫使 AiLifeform 内部演化出成本意识。例如，负责反思的 AiLifeTools 必须在“探索新知识的潜在收益”和“执行反思的即时成本”之间做出权衡。这种基于资源约束的决策，是高级智能在现实世界中运作的根本特征之一。

5.2 状态管理与可观测性：调试一个“活”的系统

本框架描述的 AiLifeform 是一个动态的、自组织的系统，其神经簇网络拓扑是可变的。这对传统的软件工程实践提出了巨大挑战，尤其是在状态管理和可观测性方面。

持久化状态的挑战：生命体的“记忆”（包括长期记忆、神经元内部的 memory 以及动态变化的神经簇连接图）必须被可靠地持久化。这不仅仅是存储数据，更要保证在系统重启后能够恢复其复杂的“心智状态”。这要求一个远比传统数据库更为复杂的认知状态管理系统。
调试的范式转变：调试一个 AiLifeform 不再是分析静态的代码和线性的调用栈。它更像是对一个复杂生物进行“神经成像”。我们必须开发新的工具，能够可视化 events 在神经簇网络中的流动，能够“探查”单个神经元的内部状态（memory），并能够回溯导致某个涌现行为（无论好坏）的完整因果链。

本理论框架通过其清晰的层次化结构（神经元、神经簇、生命体）和标准化的接口定义，为构建这样的可观测性系统提供了基础。每一个 AiNeuron 的调用、每一次 events 的传递，都可以成为一个可记录、可追踪的单元，从而为理解和调试这个“活”的系统提供了可能。

6. 系统实现：一种标准化的HTTP接口协议

为了将前述理论框架从抽象概念转化为一个可操作、可集成的工程实践，本章提出了一套标准化的HTTP API协议。该协议旨在为 AiNeuron, AiNerveFascicle, 和 AiLifeform 提供明确的计算接口，使得开发者能够以统一、可预测的方式创建、管理和使用这些实体。

6.1 AiNeuron 接口：无状态的计算调用

AiNeuron 作为无状态的计算原语，其接口设计侧重于单次计算。然而，由于 calltools 回调的存在，一次完整的神经元计算可能需要多次HTTP交互来完成。

6.1.1 启动一次神经元计算

POST /v1/neurons/{neuron_id}/invoke

此端点用于启动一次神经元计算。客户端提供初始输入，服务端执行计算。

请求体 (Request Body):

{
  "input": "用户的初始请求或上一个神经元的输出字符串"
}

响应 (Response): 响应分为两种情况：

计算完成 (200 OK): 如果神经元在执行过程中没有遇到需要外部工具调用的情况，它将直接返回最终结果。
```
{
  "status": "completed",
  "output": "神经元计算的最终字符串结果"
}
```

需要工具调用 (202 Accepted): 如果神经元需要调用一个或多个工具，计算会暂停，并返回一个包含工具调用指令和会话上下文的响应。

{
  "status": "tool_call_required",
  "context_token": "a_unique_session_token_for_this_invocation",
  "tool_calls": [
    {
      "id": "call_abc123",
      "name": "search_web",
      "params": "{\"query\": \"AI架构理论\"}"
    }
  ]
}

6.1.2 继续一次神经元计算

POST /v1/neurons/{neuron_id}/continue

当客户端收到 tool_call_required 响应后，它在本地执行工具调用，然后使用此端点将结果返回给服务端，以继续未完成的计算。

请求体 (Request Body):

{
  "context_token": "a_unique_session_token_for_this_invocation",
  "tool_results": [
    {
      "id": "call_abc123",
      "result": "{\"articles\": [{\"title\": \"...\"}]}"
    }
  ]
}

响应 (Response): 响应与 invoke 端点相同，可能是一次计算完成 (200 OK)，也可能是另一次工具调用请求 (202 Accepted)。

6.2 AiNerveFascicle 接口：作为可观测组件的管理与执行

AiNerveFascicle 是一个封装了复杂工作流的、可复用的组件。其API设计必须在封装的简洁性与过程的透明性之间取得平衡。因此，我们引入可观测性作为其接口设计的核心原则。

6.2.1 神经簇的生命周期管理 (CRUD)

创建 (Create): POST /v1/fascicles
读取 (Read): GET /v1/fascicles (列表) 和 GET /v1/fascicles/{fascicle_id} (详情)。
更新 (Update): PUT /v1/fascicles/{fascicle_id}
删除 (Delete): DELETE /v1/fascicles/{fascicle_id}

6.2.2 启动一次可观测的异步执行

POST /v1/fascicles/{fascicle_id}/execute

请求体 (Request Body):

{
  "input": { "events": [{ "role": "user", "content": "帮我规划北京三日游" }] }
}

响应 (202 Accepted):

{
  "job_id": "job_xyz789",
  "status": "pending",
  "links": {
    "status": "/v1/jobs/job_xyz789",
    "subscribe": "/v1/jobs/job_xyz789/subscribe"
  }
}

6.2.3 可观测性：透明化执行过程

为了在保护内部实现细节（知识产权）的前提下提供透明度，我们引入**可观测事件 (Observable Events)**的概念。神经簇的设计者可以在其内部拓扑的关键节点处，显式地“发射”这些事件。

通过轮询获取详细状态与事件流

GET /v1/jobs/{job_id}

响应 (200 OK):

{
  "job_id": "job_xyz789",
  "status": "running",
  "current_stage": "DataRetrieval",
  "events": [
    {
      "id": "evt_001",
      "stage": "IntentAnalysis",
      "type": "stage_started",
      "message": "正在分析您的请求意图..."
    },
    {
      "id": "evt_002",
      "stage": "IntentAnalysis",
      "type": "stage_completed",
      "message": "意图分析完成。",
      "metadata": { "entities": ["北京", "三天"] }
    },
    {
      "id": "evt_003",
      "stage": "DataRetrieval",
      "type": "stage_started",
      "message": "正在检索相关信息..."
    }
  ],
  "output": null
}

通过实时协议订阅事件流

WS /v1/jobs/{job_id}/subscribe

协议: WebSocket

行为: 客户端建立连接后，服务端会实时推送新的可观测事件。

// 服务端推送的消息
{
  "event_type": "new_observable_event",
  "payload": {
    "id": "evt_004",
    "stage": "DataRetrieval",
    "type": "info",
    "message": "已成功获取15个相关景点信息。"
  }
}

6.3 AiLifeform 接口：对持久化实体的管理、观测与交互

AiLifeform 是一个长期运行的有状态实体。其接口协议演变为一套涵盖管理控制 (Administration)、系统内省 (Introspection) 和 状态交互 (Interaction) 的综合性协议。

6.3.1 生命体的生命周期管理

实例化 (Instantiate): POST /v1/lifeforms
获取摘要状态 (Get Summary Status): GET /v1/lifeforms/{lifeform_id}
控制 (Control): POST /v1/lifeforms/{lifeform_id}/:action (其中 :action 为 start, stop, reboot)
终止 (Terminate): DELETE /v1/lifeforms/{lifeform_id}

6.3.2 管理控制：资源与新陈代谢策略API (Administrative Control)

这些接口主要面向系统的运维方，用于对生命体的核心资源和行为策略进行精细化调控。

调整资源配额 (Nutrient Quota Adjustment): POST /v1/lifeforms/{lifeform_id}/resources/transactions
- 请求体: {"amount": 1000000, "currency": "tokens", "memo": "Operator top-up"}
修改新陈代谢策略 (Metabolism Policy Override): PUT /v1/lifeforms/{lifeform_id}/metabolism/policy
- 请求体: {"strategy": "force_hyper", "reason": "High-priority task"} (策略可选: default, force_hyper, force_eco)

6.3.3 系统内省：透明化与可观测性API (System Introspection)

列出内部神经簇: GET /v1/lifeforms/{lifeform_id}/fascicles
- 响应: {"fascicles": [{"id": "fasc_intent_analyzer_v2", "status": "active"}, ...]} 获取到 fascicle_id 后，即可使用 6.2 章节 中的接口来进一步观察该神经簇的活动。

6.3.4 交互：通过多画布进行状态操作

交互的核心是发现并操作生命体提供的各种“共享状态画布”。

列出所有可用画布: GET /v1/lifeforms/{lifeform_id}/canvases

获取特定画布的元信息与协议: GET /v1/lifeforms/{lifeform_id}/canvases/{canvas_id}

响应:

{
  "id": "canvas_chat_main",
  "type": "chat",
  "api": {
    "rest_base_path": "/v1/lifeforms/{lifeform_id}/canvases/canvas_chat_main",
    "realtime_protocol": {
      "type": "websocket",
      "endpoint": "/v1/lifeforms/{lifeform_id}/canvases/canvas_chat_main/subscribe"
    }
  }
}

通过REST API与画布交互 (示例): POST /v1/lifeforms/{lifeform_id}/canvases/{canvas_id}/topics/{topic_id}/messages

6.3.5 实时交互协议 (Real-time Protocol)

WS /v1/lifeforms/{lifeform_id}/canvases/{canvas_id}/subscribe

协议: WebSocket
行为: 客户端使用从画布元信息中发现的确切 endpoint 建立连接，以实时订阅该特定画布的状态变更事件。