2026-10-18 05:00:41 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

cover_image

从工具调用到任务执行：CyberStrikeAI Agent Runtime 的一次体系化升级

原创

低调学安全
低调学安全

低调学安全

2026年8月15日 02:40
浙江

在小说阅读器读本章

去阅读

如果把安全智能体看成一个产品，而不是一个 Demo，“能调用工具”只是起点。

真正困难的是运行时：工具失败后如何恢复？长命令如何后台执行？上下文变长后如何保留测试范围和用户约束？工具输出过大时如何落盘回读？模型服务抖动时任务能否继续推进？

这次 CyberStrikeAI 升级到底层 Agent 框架 Eino v0.9.14 稳定线，但更核心的变化，是运行时体系的重构与增强。

围绕模型协议、工具调用、上下文压缩、长任务治理、失败恢复和过程展示等关键链路，CyberStrikeAI 对运行时能力做了一次系统化整理，使执行过程更加清晰、可恢复、可观测。

这篇文章讨论一个关键的问题：当安全 Agent 开始承担真实任务时，平台需要补齐哪些能力，才能从“会调用工具”走向“可靠执行任务”。

一、为什么安全 Agent 需要 Runtime 思维

很多 Agent 项目早期都会经历一个阶段：让模型看到工具列表，然后模型决定调用哪个工具。只要模型能调用 ls、read_file、exec、nuclei、search_knowledge_base，看起来就已经像一个 Agent。

但安全任务和普通问答不一样。

安全任务往往有几个特点：

链路长：一次任务可能包含资产识别、指纹判断、漏洞验证、证据整理、风险记录。
工具多：本地工具、MCP 工具、WebShell、C2、知识库、项目资产、漏洞库都会进入候选范围。
输出大：扫描日志、命令输出、目录树、代码片段都可能远超模型上下文。
决策受约束：测试范围、授权边界、用户禁令、人工审批结果都必须被严格保留。
中途会变化：用户可能追加说明、终止某个动作、要求换策略。
失败很常见：模型接口、外部 MCP、目标服务、长命令都有可能出现超时或临时失败。

因此，安全 Agent 不应该只是一个“模型 + 工具列表”的组合。它需要的是一套 Runtime：能承载多轮状态，能治理工具生命周期，能压缩上下文，能恢复中断，能把过程可靠地展示给用户。

这就是本次升级的主线。

判断一个安全 Agent 是否成熟，不能只看它能不能把某个命令跑起来，而要看四件事：

状态是否可靠：长任务、多轮对话、工具结果、用户约束能不能稳定延续。
执行是否可控：慢工具、后台任务、取消、等待、中间产出是否有统一控制面。
上下文是否可治理：信息越来越多时，系统是否知道哪些内容必须保留，哪些内容可以压缩。
过程是否可信：用户看到的时间线是否等于真实发生过的执行过程。

这四件事共同决定了 Agent 能否进入生产场景。

二、消息协议升级：从聊天记录到结构化执行状态

过去很多 Agent 系统的问题，不是模型不会推理，而是消息协议太松散。

传统聊天消息更像一段段文本。工具调用、工具结果、推理内容、流式片段、错误信息、MCP 返回值，往往被塞进 message 字段或扩展字段中。只要任务很短，这种方式还能工作；一旦任务变长，或者触发压缩、重试、续跑，问题就会出现。

最典型的问题是：

压缩后工具调用和工具结果对不上；
续跑时模型看到的历史和真实执行过的历史不一致；
前端过程详情显示了并不存在的工具调用；
某些内部恢复信息被误当成普通工具结果；
reasoning、tool result、assistant reply 混在一起，难以稳定重建。

这次升级把主执行路径迁移到了结构化的 Agentic 消息形态。对用户来说，这不是一个可见 UI 功能；但对系统稳定性来说，这是地基。

升级后的消息不再只是“聊天记录”，而更像“执行状态”：

维度	传统消息思路	当前升级后的思路
用户输入	一条文本消息	带上下文边界的任务输入
工具调用	message 字段/扩展字段	结构化 Function Tool Call
工具结果	普通 tool message	结构化 Function Tool Result
推理内容	文本或私有字段	与模型响应元信息分离
压缩对象	历史聊天记录	Agent 执行状态
续跑依据	重新拼接历史	checkpoint + model-facing trace

这一步的价值在于，后面的上下文压缩、重试、失败恢复、前端展示，都有了更稳的协议基础。

三、上下文压缩：不是“删掉旧消息”，而是保留任务连续性

长任务一定会遇到上下文问题。简单做法是裁剪历史，只保留最近几轮；更进一步是做摘要，把旧内容压成一段 summary。

但对安全任务来说，仅仅“摘要一下”还不够。

安全任务的上下文里往往包含关键约束：

用户指定的目标范围；
哪些动作被允许，哪些动作被禁止；
已确认的资产和漏洞事实；
工具输出中的关键证据；
已经尝试过但失败的方法；
人工审批结果；
中断时用户追加的说明。

如果这些内容在压缩后丢失，Agent 表面上还在继续执行，实际上已经偏离任务。

当前压缩策略强调的是“任务连续性”：

压缩在模型调用前的中间件链路中触发，而不是在外层手写截断。
根据 token 预算触发，不按消息条数粗暴裁剪。
压缩前完整 transcript 落盘，必要时可回看原始历史。
压缩后注入用户意图 ledger，保留原始用户要求和约束。
保留最近 assistant/tool trail，避免刚执行完的工具上下文断层。
压缩后刷新项目 fact index，让项目黑板保持最新。
上下文超限时支持更激进的压缩重试。

换句话说，当前压缩不是为了“让模型输入短一点”这么简单，而是为了让长任务在有限上下文内持续保持方向感。

这对安全 Agent 很关键。因为一次安全分析经常不是一问一答，而是一段持续的工作流。压缩做得不好，Agent 就会“失忆”；压缩做得好，Agent 才能在长链路里保持稳定。

四、工具治理：工具越多，越需要按需暴露

安全平台的工具数量增长很快。

本地文件工具、命令执行、知识库检索、漏洞记录、资产管理、WebShell、C2、外部 MCP、批任务、项目管理、技能系统……这些工具如果全部常驻在模型上下文里，会带来两个问题。

第一是 token 成本。工具 schema 本身会占大量上下文，任务越复杂，越挤占真正的分析空间。

第二是误调用。模型看到的工具越多，越容易在没有完整 schema 的情况下猜参数，也更容易选择一个看似相关但并不适合当前步骤的工具。

这次升级的重点，是把工具搜索、动态工具池、schema 解锁、任务板和输出治理放进同一条工具治理链路中：

一部分高频工具常驻；
低频工具进入动态工具池；
模型需要时先检索工具；
工具 schema 解锁后再执行真实调用；
与任务板、输出压缩、上下文压缩共同工作。

这让工具系统从“工具越多越强”变成“工具越多越需要治理”。对安全平台来说，这是非常现实的能力。

更深一层看，工具治理解决的不是“找工具”这一个问题，而是三个问题：

选择问题：当前任务真正需要哪些工具；
暴露问题：哪些工具 schema 应该进入模型上下文；
执行问题：工具调用、工具结果、后台执行、失败返回如何进入同一套状态机。

只有把这三件事放在一起，工具系统才不会随着能力扩展而变得越来越不可控。

五、大输出治理：完整数据落盘，模型只看必要部分

工具输出过大，是安全 Agent 的常态。

一个目录扫描可能输出几千行，一个漏洞扫描可能输出几十万字符，一个日志分析可能远超模型窗口。直接把这些内容塞进上下文，会造成三个问题：

模型上下文爆炸；
后续推理空间被工具输出挤占；
重试和续跑时成本急剧上升。

当前链路中，大工具输出进入 reduction 治理：

超大输出写入本地文件；
上下文只保留预览、摘要和路径；
后续需要细节时再通过文件读取工具回读；
执行记录、前端展示和模型上下文读取同一份规范化结果。

这是一种更适合生产系统的做法：完整数据不能丢，但模型不应该每一轮都背着完整数据继续推理。

对于安全场景，这尤其重要。因为证据要保留，结果要可追溯，但模型上下文必须保持清爽。

六、长任务不应阻塞 Agent：后台 execution 控制面

很多安全工具不是秒级完成的。

例如：

扫描一个网段；
跑一个较大的 nuclei 模板集；
执行 WebShell 命令等待远端返回；
外部 MCP 工具请求慢；
长时间 grep 或分析大文件。

如果 Agent 一直阻塞等待工具完成，用户体验会很差，模型也无法做其他判断。如果一超时就直接失败，又会浪费已经执行了一半的工作。

CyberStrikeAI 采用的是后台 execution 控制面：

工具提交后进入后台 worker。
本轮等待到达上限后，返回 execution_id。
Agent 可以继续推理。
Agent 可以调用控制工具查看状态、继续等待或取消。

模型可见的控制工具包括：

get_tool_execution：查看当前状态和中间输出；
wait_tool_execution：有界等待一段时间；
cancel_tool_execution：取消后台任务。

这部分不是底层框架原生完整提供的能力，而是 CyberStrikeAI 的平台运行时能力。关键是它没有绕开 Agent 协议，而是把这些控制动作也作为普通工具暴露给模型。

因此，模型不是被动等待，而是可以基于状态做决策：

工具快完成了，就再等一会儿；
工具明显卡住了，就取消；
已经有足够 partial output，就先基于中间结果推进；
当前路径效率低，就换一个工具或策略。

这让 Agent 更像一个真正的任务执行者，而不是一个同步函数调用器。

七、中断与续跑：让用户补充进入当前任务，而不是另起炉灶

真实使用中，用户经常会在任务中途改变要求。

例如：

“这个目录不要改，只读。”
“这个命令太慢，停掉。”
“继续，但不要执行破坏性动作。”
“补充一下，目标其实是这个子域。”

如果系统只能取消当前任务再重启，续跑就会变得脆弱。模型可能丢掉刚才的工具状态，也可能重复执行已经做过的步骤。

这次升级后，CyberStrikeAI 接入了常驻多轮 runtime 能力。用户补充会优先进入当前运行时，在安全点被当前 Agent 消费；如果当前运行时无法接收，再回退到 cancel + trace 续跑。

这带来两个实际收益：

用户补充更容易进入当前任务上下文；
续跑时模型看到的是更接近真实执行状态的上下文。

对安全场景来说，这不是锦上添花，而是必要能力。因为授权边界和用户限制必须实时生效。

八、模型失败恢复：从外层兜底到模型层治理

模型服务并不总是稳定。兼容 OpenAI 协议的服务、私有部署模型、第三方中转，都可能出现：

临时网络错误；
5xx；
空响应；
限流；
上下文超限；
流式中断。

旧式做法往往是在外层 run loop 做很多兜底。这样能救一些情况，但逻辑容易分散，也容易和工具状态、前端展示、checkpoint 交织在一起。

当前实现中，模型层恢复更强调标准化：

模型临时错误进入 retry 策略；
支持退避；
配置备用模型通道后支持 failover；
retry/failover 事件可观测；
context overflow 进入专门的压缩重启流程；
run-level transient retry 与模型原生 retry 分层处理。

这让失败恢复更清楚：模型层的问题由模型层机制处理，运行时层的问题由运行时恢复处理，工具层的问题通过工具结果返回给模型修正。

恢复不是把任务清空重来。系统会优先基于原始模型输入、压缩后的任务状态、model-facing trace 或 checkpoint 续跑，尽量保持上下文连续性。

九、去掉过度修复：让模型通过工具结果自我纠正

Agent 系统里有一种常见冲动：当模型输出了不合法工具参数时，平台提前拦截、修复、重写，再假装这是一个正常工具结果。

这种做法短期看似“更稳”，长期反而会让系统更复杂。因为模型没有看到标准的工具错误结果，而是看到了平台私有的恢复协议。久而久之，前端展示、历史消息、续跑和压缩都会背上额外负担。

当前默认策略更克制：

真实具名工具调用，即使参数错误，也交给工具层返回错误；
模型看到标准 tool result 后自行修正；
旧的 recovery marker 仅保留历史兼容；
不再默认把模型工具调用预先改写成内部恢复调用。

这更符合 Agent 运行规律：错误不是不能出现，关键是错误要以标准形式返回，让模型在下一步决策中处理。

十、过程展示：用户看到的必须是真实执行

可观测性不是把所有内部事件都展示出来。

真正有价值的过程展示，应该让用户看到：

Agent 为什么这么做；
实际调用了哪些工具；
工具是否完成；
是否进入后台；
是否发生重试；
是否被用户中断；
最终结果来自哪些执行。

这次升级中也修复了一类展示问题：流式工具调用过程中，模型可能先输出半截参数，还没有明确工具名。过去如果把这些匿名片段误显示为工具调用，就会出现用户看到大量并不存在的 task 调用，以及“结果记录缺失”。

现在的处理更严格：

没有明确工具名的流式片段不展示为工具调用；
不再把匿名工具兜底成 task；
内部诊断事件不污染主时间线；
历史噪声也会被前端过滤；
真实工具调用和真实工具结果保持对应。

这不是单纯的 UI 优化，而是信任问题。用户必须相信时间线展示的是实际发生过的事。

十一、升级后的架构边界

经过这轮整理后，CyberStrikeAI 的 Agent 架构边界更清晰：

层级	负责内容	设计原则
Agent 协议层	消息、工具调用、工具结果、模型重试、上下文压缩	尽量使用框架原生能力
平台运行时	execution\_id、后台执行、取消、落库、SSE、监控	保留产品级自研能力
安全能力层	资产、漏洞、WebShell、C2、知识库、批任务	按业务场景持续扩展