华为发布《智能世界2035：从愿景到行动》报告，并配套推出《全球数智化指数（GDII）2026》。与此前描绘长期趋势、归纳技术方向不同，这次报告把重点放在通往智能世界必须回答的十大关键命题上。来源摘要明确点出了 AGI、超节点、Agent OS，以及一个贯穿技术和商业体系的核心变量：Token。
由于摘要没有完整列出十大命题，本文不尝试替报告补全清单，而是从已经披露的关键词出发，分析它们对软件架构、算力基础设施和企业落地意味着什么。
Token 不只是模型计费单位
在大模型应用中，Token 最直观的含义是输入和输出文本经过分词后的计算单位。开发者通常用它估算上下文长度、响应时间和 API 成本。但进入 Agentic 系统后，Token 的工程含义正在扩大。
一个自主 Agent 完成任务，可能需要读取文档、调用搜索、查询数据库、执行代码、检查结果并重新规划。每一步都会产生新的上下文和模型调用。因此，真正需要管理的不再是“一次对话用了多少 Token”，而是“一个业务结果消耗了多少 Token、算力、工具调用和人工复核”。
这会推动企业把 Token 当成一种可观测资源，至少跟踪以下指标：
- 每个任务的输入、输出和缓存 Token 数量；
- 每个 Agent 步骤的延迟、重试次数与工具调用次数；
- 单次成功任务的综合成本，而不是单次模型请求价格；
- 不同模型、提示词和上下文策略带来的质量差异；
- 因权限拒绝、工具故障或模型幻觉造成的无效消耗。
这种变化与云计算早期从“服务器采购”转向“按资源计量”类似。区别在于，Token 消耗还会受到提示词、记忆、规划路径和输出质量影响，不能仅靠基础设施监控解释。
超节点解决吞吐，Agent OS 管理行动
“超节点”与“Agent OS”分别对应智能系统的两个层面。
超节点关注计算侧：如何把大量加速器、内存、网络和存储组织成一个高带宽、低延迟的计算整体。随着模型训练和推理规模增长，单颗芯片的性能并不能决定最终吞吐，通信效率、内存访问和任务调度同样重要。
Agent OS 则更接近应用运行时。这里的“OS”不一定是替代 Linux、Windows 或移动操作系统的新内核，更合理的工程理解是：它为 Agent 提供统一的模型接入、上下文管理、工具调用、身份权限、任务调度、状态持久化和审计能力。
可以把两者放在同一条调用链上理解：
业务请求
-> Agent OS：身份、计划、记忆、权限、审计
-> 模型与工具网关：路由、限流、成本控制
-> 推理平台：批处理、缓存、资源调度
-> 超节点：计算、互联、内存与存储
超节点提升“每秒能生成和处理多少 Token”，Agent OS 则决定“这些 Token 是否被用于正确、有权限且可追踪的行动”。只有算力而缺少治理，Agent 很容易变成不可控的脚本集合；只有编排层而缺少稳定算力，系统又会被延迟和成本拖住。
可以这样实践：实现一个最小 Agent 运行时
下面的 Python 示例不依赖第三方库，模拟一个受 Token 预算和工具权限约束的 Agent。它不代表报告定义的 Agent OS，而是一个可以直接运行、继续改造成真实模型网关的最小工程骨架。
将代码保存为 agent_runtime.py，然后运行 python agent_runtime.py。接入实际系统时，可以把 mock_model 替换为内部模型服务或云端模型 API，并使用供应商返回的真实 Token 用量。
from dataclasses import dataclass, field
from typing import Callable
@dataclass
class TaskContext:
user: str
token_budget: int
allowed_tools: set[str]
tokens_used: int = 0
audit_log: list[dict] = field(default_factory=list)
def charge(self, step: str, tokens: int) -> None:
if self.tokens_used + tokens > self.token_budget:
raise RuntimeError(
f"token budget exceeded: "
f"{self.tokens_used + tokens}/{self.token_budget}"
)
self.tokens_used += tokens
self.audit_log.append(
{"event": "model_call", "step": step, "tokens": tokens}
)
class AgentRuntime:
def __init__(self, tools: dict[str, Callable[[str], str]]) -> None:
self.tools = tools
def call_tool(self, ctx: TaskContext, name: str, argument: str) -> str:
if name not in ctx.allowed_tools:
ctx.audit_log.append({"event": "tool_denied", "tool": name})
raise PermissionError(f"tool is not allowed: {name}")
if name not in self.tools:
raise KeyError(f"unknown tool: {name}")
result = self.tools[name](argument)
ctx.audit_log.append(
{"event": "tool_called", "tool": name, "argument": argument}
)
return result
def run(self, ctx: TaskContext, request: str) -> str:
ctx.charge("plan", 120)
document = self.call_tool(ctx, "knowledge_search", request)
ctx.charge("answer", 260)
return f"根据检索结果生成答复：{document}"
def knowledge_search(query: str) -> str:
return f"已找到与『{query}』相关的内部知识条目"
def main() -> None:
runtime = AgentRuntime({"knowledge_search": knowledge_search})
context = TaskContext(
user="employee-1001",
token_budget=500,
allowed_tools={"knowledge_search"},
)
answer = runtime.run(context, "查询产品交付流程")
print(answer)
print(f"tokens: {context.tokens_used}/{context.token_budget}")
print("audit log:")
for event in context.audit_log:
print(event)
if __name__ == "__main__":
main()
这个示例刻意保留了三个生产系统必须具备的约束：预算在执行前检查，工具调用经过授权，所有关键动作写入审计日志。继续扩展时，还应补充任务超时、并发限制、幂等键、人工审批、敏感数据脱敏和模型降级策略。
从演示到生产，难点是闭环治理
AGI 是长期目标，企业当前更现实的工作是把能力边界明确的 Agent 放入可控流程。例如，让 Agent 整理工单和生成建议，通常比直接授权它修改生产配置更合适。
落地时可以按风险逐级开放权限：
- 只读阶段：Agent 检索资料、汇总信息，不执行外部动作。
- 建议阶段：Agent 生成计划或操作命令，由人确认后执行。
- 受限执行阶段：只允许调用白名单工具，并设置金额、资源和频率上限。
- 闭环阶段：Agent 可以执行、验证和重试，但高风险动作仍需审批。
评价系统时也不能只看模型基准分数。生产环境更应关注任务成功率、人工接管率、端到端延迟、单个成功任务成本、越权调用次数和错误恢复时间。GDII 一类指数可以帮助观察宏观数智化进程，但企业自身仍需要建立细粒度的运行指标。
采用前的检查清单
围绕 Token、超节点和 Agent OS 建设平台时，可以先回答几个具体问题：
- 是否能把成本归因到用户、任务、Agent、模型和工具？
- 是否能为不同任务设置 Token、时间与调用次数预算？
- 工具权限是否基于身份和任务动态授予，而不是共享永久密钥？
- Agent 的计划、输入、工具参数、结果和重试是否可审计？
- 推理平台是否支持缓存、批处理、模型路由和故障降级？
- 高风险动作是否具备人工确认、幂等控制和回滚路径？
- 扩大算力规模后，网络、内存和存储是否成为新瓶颈？
这份路线图最值得关注的地方，不是为 2035 年给出一个确定答案，而是把智能世界拆成需要产业共同解决的工程问题。对开发团队而言，近期行动也很明确：将 Token 纳入成本和可观测性体系，把 Agent 当作受权限约束的运行主体，并让算力扩展与软件治理同步推进。