导语：一个真正的 AI 智能体，不是发布即终点，而是每一天都在变得更强。
01 引子：Agent 的价值，在于"持续进化"
上个月，我们发布了庙算42 —— 无需GPU依赖、搭载天旦训练的OpsGPT 大模型的网络排障AI智能体，专注于复杂问题的定界归因与行动指导。
发布只是起点。
一个真正的 AI智能体，其核心竞争力不在于某一刻的能力快照，而在于技能树的持续生长。庙算42的智能体架构天然支持"技能扩展"—— 新的协议理解、新的故障模式识别、新的推理链路，都可以作为独立的 Skill 注入系统。
今天，我们带来两个全新的技能(Skills)：VoIP 通话故障分析与 FTP 传输故障分析。
02. 新技能：VoIP —— 从信令到媒体流的全链路通话诊断
VoIP 排障复杂且隐蔽，一次通话涉及信令、媒体流和编解码等多个层面，问题可能出现在服务器、网关或防火墙等任一环节。传统方式依赖工程师在 Wireshark 中手动分析信令与 RTP 流，往往耗时数小时。
庙算 42的解法
庙算 42 新增的 VoIP Skill实现了 "一键式"通话故障诊断：
协议全覆盖
六大协议（SIP · SDP · Skinny (SCCP) · MGCP · RTP · RTCP）的信令与媒体流统一解析。
拓扑自动发现
AI 自动识别通话中的相关角色，构建完整的通话拓扑图，无需人工标注。
故障场景识别
单向语音（One-Way Audio）：精确定位哪一侧未发送 RTP 媒体包
通话质量劣化：基于 RTCP 的丢包率、抖动、延迟指标进行智能研判
信令异常：注册失败、会话建立超时等控制面故障
诊断视图："单向语音"识破
这是庙算 42 对一例真实 VoIP 故障的分析场景。
在自动生成的拓扑中，AI 发现主叫方发送了 2776 个 RTP 包，而被叫方始终未回包，并据此判断媒体流在被叫方一侧中断，同时给出 26 项证据支撑结论。
痛点：FTP 的"双通道陷阱"
FTP 使用两条独立的 TCP 连接：控制通道负责命令，数据通道负责传输。控制正常不代表数据可达，数据失败却往往只在控制通道报错，再加上防火墙、NAT 及主动/被动模式差异，使排障变得复杂。
庙算 42 的解法
新增的 FTP Skill实现了控制通道与数据通道的联合分析：
控制通道故障
认证失败（530）
服务不可用（421）
NAT 地址不匹配（PORT/PASV 地址与实际连接不一致）
数据通道故障
数据连接被拒/超时（425）
传输中断（426）
慢传输（带宽利用率异常）
双通道关联AI 自动将控制通道的命令序列与数据通道的 TCP 事件进行时序关联，还原故障的完整因果链。
诊断视图：双通道联合研判
这是 FTP 425 错误全链路分析结果。
庙算 42 还原了客户端发起 PORT 后服务端数据通道被阻断的全过程，并明确指出是网络设备 II 阻断了连接。过去需跨多设备排查的问题，如今通过双通道关联推理即可精准定位。
Skill #1 → Skill #N：这就是 Agent 的意义
庙算 42 的 Neuro-Symbolic 架构天然支持技能的热插拔式扩展：
已有技能：TCP/HTTP/HTTPS/DNS/TLS/DHCP... 数十种协议的深度诊断
本次新增：VoIP 全链路通话诊断 + FTP 双通道故障分析
即将到来：更多行业协议与场景的专项技能模块
每一个 Skill 都不是简单的"规则匹配"，而是包含 协议状态机建模 + 拓扑推理 + OpsGPT 语义归因的完整智能体能力单元。
庙算 42 不是发布后就静止的软件产品，它会不断持续进化的智能体。
"夫未战而庙算胜者，得算多也。" —— 《孙子兵法·计篇》
Netis · 庙算 42让 AI Agent 的每一项新技能，都成为你手中的利器。
