BLOG

拓扑

2026/05/14 5 min read BLOG 拓扑

AI-native Runtime System

最小拓扑。

你这个问题其实已经进入：

“系统边界最小化”

层面了。

而且这是你现在最该思考的问题。

因为：

你已经开始：

DataBase
ContentBase
MyBlog

三仓分离。

所以：

你现在最重要的不是：

“加模块”

而是：

“每层最小职责是什么”。

我直接给你一个：

AI-native Runtime System

最小拓扑。

一、API 的最小需求是什么？

API 的本质：

“跨边界能力暴露”。

也就是说：

API 不应该：

泄漏内部实现

API 最小职责：

只有：

1. Capability Exposure

例如：

generateChapter
resolveCreativeContext
recordGenerationOutput

2. Validation

例如：

输入 schema
权限
版本

3. Transport

例如：

HTTP
JSON
stream
SSE

API 不应该知道：

prompt 怎么拼
quality gate 怎么跑

所以：

API = 边界层。

二、SDK 的最小需求是什么？

SDK 的本质：

“把 API 变成人能调用的能力”。

例如：

你现在：

client.generateChapter()

很好。

因为：

SDK 应该：

屏蔽 transport complexity。

SDK 最小职责：

1. Typed Capability

例如：

generateChapter(input)

2. Retry / Auth / Serialization

例如：

token
timeout
retry
pagination

3. Version Shield

例如：

API 变了。

SDK 尽量不让调用方炸。

SDK 不应该：

拥有业务逻辑

所以：

SDK = API 的 ergonomic projection。

三、RPC 的最小需求是什么？

RPC 本质：

“远程函数调用”。

它解决：

跨进程
跨机器

问题。

RPC 最小职责：

1. Request/Response

例如：

invoke capability

2. Serialization

例如：

protobuf
json
msgpack

3. Routing

例如：

service discovery

RPC 不应该：

拥有 domain truth

所以：

RPC = execution transport。

四、DAG 的最小需求是什么？

这是你现在最关键的。

DAG 的本质：

不是：

流程图

而是：

Runtime Dependency Graph。

DAG 最小职责：

1. Node

例如：

ResolveContext
BuildPrompt
InvokeLLM
QualityGate

2. Dependency

例如：

QualityGate
 dependsOn InvokeLLM

3. Execution State

例如：

pending
running
failed
completed
retrying

4. Retry / Resume

这是 DAG 真正的灵魂。

例如：

只重跑失败节点

而不是整个 pipeline。

五、Workflow 的最小需求是什么？

很多人会把：

Workflow = DAG

搞混。

其实：

Workflow > DAG。

DAG：

描述：

依赖关系。

Workflow：

描述：

生命周期。

例如：

draft
review
repair
publish
archive

Workflow 最小职责：

1. Lifecycle State

2. Human Approval

例如：

needs_review
approved
rejected

3. Compensation

例如：

回滚
撤销

六、Projection 的最小需求是什么？

你系统非常关键的一层。

Projection 本质：

“把 truth 变成可消费视图”。

例如：

Canonical Graph
 -> HTML
 -> Reader
 -> Search
 -> EPUB

Projection 最小职责：

1. Read-only

2. Regeneratable

3. Version-bound

例如：

projection belongs to graph v17

七、Annotation 的最小需求是什么？

你已经开始做了。

Annotation 本质：

Overlay Graph。

不是：

改正文

Annotation 最小职责：

1. Anchor

2. Author

3. Visibility

4. Reviewability

八、真正成熟的拓扑

你现在应该逐渐走向：

DataBase
  = Truth / Graph / Contracts
 
ContentBase
  = Runtime DAG / Workflow Engine
 
MyBlog
  = Projection / Reader / Intake Surface
 
OpenList
  = Blob Archive / File Access

九、最关键一句话

真正高级的系统：

不是：

“模块很多”

而是：

“每层只有一个不可替代职责”。

例如：

DataBase

只能拥有：

canonical truth

ContentBase

只能拥有：

runtime execution

MyBlog

只能拥有：

public projection UX

OpenList

只能拥有：

immutable blob archive

这才是：

topology clarity。