Agentic 应用把传统 AI 系统中的一次模型调用，扩展成了持续数分钟甚至更久的任务链：规划、检索、工具调用、模型推理、结果校验和失败重试彼此交织。随之而来的问题不再只是单次推理吞吐量，而是长尾等待、节点间通信、状态驻留和资源调度同时承压。
华为提出基于灵衢架构、面向“超节点+集群”的 Agentic 计算开发方式，试图把优化范围从单台服务器扩大到整个计算系统，并进一步连接算子、运行时和 Agent 开发范式。来源摘要明确提到这一方向被拆为五个维度推进，但没有完整列出五个维度，因此下面不推测具体官方分类，而是从工程落地角度分析这种变化意味着什么。
Agent 工作负载为什么难以沿用传统推理模型
传统在线推理通常容易抽象成“请求进入、模型执行、返回结果”。Agent 的执行图则具有明显的动态性：不同任务经过的步骤不同，同一步骤可能调用不同模型或外部工具，失败后还会回退、重试或重新规划。
这会带来四类直接影响：
- 尾延迟被放大：一个 Agent 任务串联十几个步骤，只要其中一次工具调用或跨节点通信变慢，最终完成时间就会被整体拉长。
- 内存占用时间延长：会话上下文、KV Cache、中间结果和工具返回值需要跨步骤保留。即使单步内存可控，大量并发长任务也会形成持续驻留。
- 通信模式更复杂：除了模型并行产生的高带宽通信，还可能存在模型之间、执行器之间以及 Agent 与工具服务之间的数据交换。
- 负载难以静态预测：一次任务会执行多少步、生成多少 token、是否重试，往往要到运行时才能知道。
因此，只看单卡每秒 token 数很容易得到误导性结论。对 Agentic 系统更有意义的指标还包括任务完成时间、P95/P99 步骤延迟、单位任务通信量、峰值状态内存、重试率和工具等待占比。
“超节点+集群”改变了优化边界
来源所强调的第一项变化，是开发视角从单服务器转向超节点。其核心价值并不等同于简单增加设备数量，而是让计算、内存和互联拓扑成为同一个设计问题。
可以把资源层级理解为三层：
- 设备与算子层：关注算子融合、数据布局、并行策略以及计算与通信重叠。
- 超节点层：把需要频繁同步、共享大量状态的模型组件安排在高带宽、低时延的互联范围内。
- 集群层：承担跨超节点调度、弹性扩缩、故障隔离，以及吞吐型任务的横向扩展。
这种分层对 Agent 工作流尤其重要。高频交换张量的模型并行任务适合尽量留在紧密互联的资源域中；检索、代码执行和远程 API 调用则不一定需要占用昂贵的加速器资源；多个相互独立的 Agent 任务可以在集群层并行展开。
换句话说，调度单位不应只有“一个容器需要几张卡”，还应描述任务的通信强度、状态规模、时延目标和执行阶段。否则，调度器可能拥有足够的总算力，却把强通信任务拆散到较远的节点上，最终让设备等待网络。
从算子优化走向 Agent 开发范式
Agentic 计算并没有让底层优化失去价值，反而要求各层共享更多信息。算子层知道张量形状和通信依赖，运行时知道内存与设备状态，Agent 编排层则知道哪些步骤可并行、哪些结果可以缓存、哪些任务允许降级。
工程上可以这样建立跨层契约：
- Agent 编排器为每个步骤声明
latency_sensitive、state_size、communication_class和超时策略。 - 运行时根据声明选择模型实例、批处理窗口和资源域，而不是让所有请求走同一队列。
- 推理服务暴露排队时间、首 token 延迟、生成速度和缓存命中率。
- 调度系统把步骤级指标回传给 Agent，使其能够减少无效重试或切换较轻量的执行路径。
- 可观测系统使用统一的任务 ID 串起模型、工具、网络和调度事件。
这里的关键是避免“每层各自优化”。例如，推理服务为了提高吞吐量扩大批处理窗口，可能直接损害交互型 Agent 的尾延迟；Agent 为提高答案质量无上限地增加反思步骤，又会让底层容量规划失效。
用一个可运行脚本模拟长程 Agent 压力
下面是一个不依赖第三方库的简化实验。它不代表华为产品接口，只用于在普通 Python 环境中观察并发上限、步骤数、计算延迟和通信延迟如何共同影响任务完成时间。
将代码保存为 agentic_benchmark.py，使用 Python 3.9 或更高版本运行：
import argparse
import asyncio
import random
import statistics
import time
async def run_agent(agent_id, steps, capacity, compute_ms, network_ms):
started = time.perf_counter()
for _ in range(steps):
async with capacity:
compute = random.uniform(0.7, 1.3) * compute_ms / 1000
network = random.uniform(0.5, 1.8) * network_ms / 1000
await asyncio.sleep(compute + network)
return time.perf_counter() - started
async def main(args):
capacity = asyncio.Semaphore(args.slots)
tasks = [
run_agent(i, args.steps, capacity, args.compute_ms, args.network_ms)
for i in range(args.agents)
]
started = time.perf_counter()
durations = sorted(await asyncio.gather(*tasks))
elapsed = time.perf_counter() - started
def percentile(values, p):
index = min(len(values) - 1, int((len(values) - 1) * p))
return values[index]
print(f"agents={args.agents} steps={args.steps} slots={args.slots}")
print(f"wall_time={elapsed:.3f}s throughput={args.agents / elapsed:.2f} tasks/s")
print(f"mean={statistics.mean(durations):.3f}s")
print(f"p50={percentile(durations, 0.50):.3f}s")
print(f"p95={percentile(durations, 0.95):.3f}s")
print(f"p99={percentile(durations, 0.99):.3f}s")
if __name__ == "__main__":
parser = argparse.ArgumentParser()
parser.add_argument("--agents", type=int, default=100)
parser.add_argument("--steps", type=int, default=12)
parser.add_argument("--slots", type=int, default=16)
parser.add_argument("--compute-ms", type=float, default=40)
parser.add_argument("--network-ms", type=float, default=15)
asyncio.run(main(parser.parse_args()))
先运行一组基线：
python agentic_benchmark.py --agents 100 --steps 12 --slots 16 \
--compute-ms 40 --network-ms 15
然后把网络等待从 15 毫秒提高到 60 毫秒：
python agentic_benchmark.py --agents 100 --steps 12 --slots 16 \
--compute-ms 40 --network-ms 60
这个模型有意做了简化：slots 表示可并行执行的计算槽位，compute-ms 表示单步计算时间，network-ms 表示通信或远程工具等待。它不能模拟真实加速器，但可以揭示一个重要现象：当任务包含多个串行步骤时，单步增加几十毫秒会被步骤数和排队效应放大，P95/P99 往往比平均值恶化得更明显。
在真实环境中，可以把 asyncio.sleep 替换为模型服务 HTTP 请求，并记录以下时间戳：排队开始、推理开始、首 token、推理结束、工具调用开始和工具调用结束。这样才能判断瓶颈究竟位于算子、互联、调度还是外部工具。
落地时先回答这六个问题
采用“超节点+集群”思路之前，不宜直接从硬件规模倒推方案。更稳妥的顺序是先描述工作负载，再决定资源布局：
- 一个 Agent 任务通常执行多少步，P95 又是多少步？
- 每个步骤保留多少上下文和中间状态，状态需要驻留多久？
- 哪些通信是高频张量同步，哪些只是低频控制消息？
- 哪些步骤必须低延迟，哪些可以批处理或异步执行？
- 工具调用失败时如何限流、退避和终止，是否存在无限重试风险？
- 超节点故障或模型实例重启后，任务能否从检查点恢复？
Agentic 计算的难点不是把更多 Agent 放进集群，而是让开发框架、运行时、互联和算子对同一个任务目标协同工作。超节点解决紧密协作的计算问题，集群提供规模与故障边界；真正决定用户体验的，则是上层能否理解并利用这些差异。实施时应先建立端到端追踪和步骤级容量模型，再逐步调整拓扑、调度与模型并行策略，避免只优化局部吞吐量。