龙虾类Agent安全生产：跳出循环才是胜负手

2026-06-23阅读 0热度 0

机器学习

引言

loop 范式近期在 agent 圈快速升温。

Claude Code 的创造者 Boris Cherny 那句判断被频繁引用——他不再直接对模型发 prompt，"我的职责是写 loop"。数百个 agent 持续读取他的 GitHub 和 Slack，自主决定后续行动。Anthropic 的 Lance Martin 同样发布过实验记录：让模型在 8 张 H100 上自主执行机器学习调优，连续运行 8 小时，自行修改代码、训练迭代、分析日志并规划下一步实验。但中文社区对 loop 的讨论，多数仍停留在工程操作层面：bash 循环编写技巧、hook 配置方法。

换个视角切入更有价值。近期两个事件让我意识到——当这类具备自主行动能力的智能体正式进入生产环境时，比"如何写 loop"更紧迫的问题，是如何有效管控其安全边界。

两个案例的启示如下。某次与一家企业 AI 负责人的交流中，他透露其公司已将该类智能体部署至生产环境，底层引擎正是 Claude Agent SDK。这一信息令我警觉，因为自己的团队正以 QwenPaw 作为数字员工平台的基础组件，同样运行在生产环境中（而非个人 PC 上）。两条实施路径交汇于同一个核心问题：一款能够读写文件、执行命令、在真实环境中自主操作的智能体，一旦上线生产，安全体系应如何构建？

先界定"龙虾类"概念：这是对一组特定智能体框架的戏称——其命名常带有 claw 或 paw 元素（爪或钳）。典型代表包括自称遵循"龙虾之道"的 OpenClaw、阿里通义推出的 QwenPaw，以及将 Claude Code 封装为库的 Claude Agent SDK。龙虾最突出的特征是那对大钳子；与此对应，这类智能体的标志性能力也是那对能自主操作的"爪子"。

本文沿着这条主线展开：首先厘清龙虾类的真正独特之处，它与平台型智能体之间的本质区别究竟是什么（提前剧透：关键不在 loop）；随后聚焦核心议题——龙虾类进入生产环境时，安全体系如何落地。

开篇先抛出反直觉结论：龙虾类并非平台型智能体的"升级迭代"，而是一套不同的权衡体系。 能力越强劲，风险越集中，合规投入也越沉重。 它能部署上线靠的是一把"万能扳手"；而能否在金融级别环境中安全运行，胜负手恰恰在于——能否将这把万能扳手有效约束。

一、认清龙虾类本质：在通用执行环境中自主操作

讨论安全之前，必须明确其危险（以及强大）的根源。

很多人将龙虾类的独特之处归结为"能自行编写代码"。这种表述不算错误，但偏离了本质。真正的区别不在于"能否写代码"，而在于"agent 能否在通用执行环境中自主解决问题"。编写并运行代码，是这种能力最典型且最强大的表现，但同一能力同样体现在：执行任意命令、读取或写入任意文件、调用脚本、操作真实终端。

对比平台型智能体就能清楚：平台型为 agent 提供的工具，是边界清晰的声明式 API——查询余额、提交工单、调用模型。即使包含"代码执行"工具，通常也是受限的、沙箱化的、只能完成特定任务。龙虾类智能体则赋予 agent 对真实环境的开放操作权限——一个能执行任意命令的 shell、一个能读写任意文件的文件系统、一个真实的沙箱或终端。

因此，"能自己写代码"是一个有效的识别标识，但不应作为定义——真正的定义是"通用执行环境的开放程度"。这把"万能扳手"正是龙虾类所有能力与所有风险的共同源头，后续整个讨论都将围绕它展开。

龙虾家族中的主要成员，恰好对应本文的两个真实案例：

Claude Agent SDK：将驱动 Claude Code 的核心内核打包为库，"让你的代码成为驱动者"。案例一就是它——某企业将龙虾类智能体部署至生产环境，底层引擎正是此 SDK。（补充依据：据公开报道，Spotify 利用它构建了 fleet-wide 代码迁移 agent，节省约 90% 工时、每月 650 个 PR 合入生产。）
QwenPaw：阿里通义 AgentScope 团队出品，基于 Apache 2.0 协议，内置 ReAct 循环，能力栈完备（聊天入口、记忆、工具、Skills、MCP、多 Agent、安全守卫、主动心跳）。案例二就是它——笔者公司以其作为数字员工平台的基础组件，已部署于生产环境。
OpenClaw：基于 Node.js 的个人 AI 助手、自托管网关，官方将信任模型定义为"单一可信操作者边界"，不适用于敌对多租户场景。后续将作为"安全反面案例"呈现。

下面这段 Claude Agent SDK 的代码示例（真实接口，SDK 演进较快，请以官方文档为准）值得先留意——记住其中的 guard_bash，它就是第三章"工具调用硬卡点"的原始雏形：

Python

import anyio
from claude_agent_sdk import query, ClaudeAgentOptions

# PreToolUse 钩子：高危命令直接拒绝
# （给"万能扳手"安装的第一道限位器）
async def guard_bash(input_data, tool_use_id, context):
    if input_data["tool_name"] == "Bash":
        cmd = input_data["tool_input"].get("command", "")
        bad = ("rm -rf", "drop table", "shutdown")
        if any(k in cmd for k in bad):
            return {"decision": "deny", "reason": "高危命令，需人工确认"}
    return {}

options = ClaudeAgentOptions(
    system_prompt="你是值班 SRE，按 runbook 排障，只读优先。",
    # Bash 就是那把通用执行的"万能扳手"
    allowed_tools=["Read", "Grep", "Bash"],
    permission_mode="default",  # 高危走审批，不用 bypass
    max_turns=12,  # 防失控循环：迭代上限
    mcp_servers={
        "cmdb": {
            "type": "http",
            "url": "https://gw.internal/mcp/cmdb",
        },
    },
    hooks={"PreToolUse": [guard_bash]},
    model="claude-opus-4-8",
)

async def main():
    async for msg in query(
        prompt="10.2.3.4 告警，定位根因并给修复建议",
        options=options,
    ):
        print(msg)

anyio.run(main)

关于 QwenPaw（笔者公司正在使用的框架），有三个判断与"生产化部署"直接相关，必须明确：

它本质是个人 Agent 工作站，并非企业级平台。 在企业内可以演进为数字员工平台，但必须额外补齐五项：身份权限治理、工具管理、审计合规、Skill 生命周期管控、生产操作审批机制。
它存在真实的安全缺口。 据 GitHub Issue 反馈，早期 Docker 部署模式缺少访问控制（#139，公网暴露后任何人均可使用）、Windows 环境下文件目录防护失效（#3457）——印证了"龙虾类作为个人工作台体验流畅，但企业级治理原语仍不成熟"。
桌面版不等于企业级 runtime。 阿里实际上拥有企业级底座 AgentScope Runtime / 2.0 以及基于此的金融通用智能体阿里云"点金"（包含工具沙箱、Agent-as-a-Service API、K8s/FC 弹性部署、全栈可观测性、断点续传等特性）。若要将"爪类"体验接入生产环境，应优先采用 Runtime 或点金，而非桌面版。这一原则，正是后续所有安全工作的前提基础。

二、本质区别：通用执行能力，而非 loop 控制权

在深入安全之前，必须先消除一个常见误解，否则治理重心会错位。

一个直觉性陷阱：你可能认为龙虾类的特别之处在于"将循环（loop）的控制权交给了你"。事实并非如此。

把事实梳理清楚：loop 的拓扑结构，平台型和龙虾类本质上都由框架固化——平台型通过可视化编排或固定流程定义 loop，龙虾类则利用内置的 ReAct 循环来定义 loop，开发者在两种框架中都不是"从零编写循环"。loop 本身没什么神秘，它基本就是一个大约 20 行的 while 结构：调用模型 → 检查返回中是否有工具调用 → 有则执行后再反馈 → 没有则退出。loop 的实现位置其实可以分三个层次：① 裸手写（无框架）② 编排框架中描述拓扑（如 LangGraph、AgentScope 等）③ 成型 runtime 中"不写"只填空。龙虾类属于第三层：loop 已被框架固化，你只需配置 prompt、挂载工具、插入 hooks，根本不需要重写循环。（顺带说明：LangGraph、AgentScope 属于第二层的"编排底座"，并非龙虾类——使用 AgentScope 搭建出的 QwenPaw 才是龙虾类应用。）

最初认为龙虾类与平台型的分界线是"loop 控制权"，这个观点站不住脚。真正的区别在于另外两点：

工具的性质。 平台型提供的是一组边界清晰的声明式 API；龙虾类在此之外，还提供了通用执行能力（shell、文件系统、代码执行、真实终端），允许 agent 在真实环境中自主"动手"。
由此带来的"确定性 vs. 能力"权衡。 声明式 API 行为可预测、易管控，但无法处理步骤不确定的任务；通用执行能力能够处理那些"边做边想、需要真动手"的场景，但代价是行为不再可预测——这正是龙虾类安全机制成为核心的原因：风险来源于"开放了通用执行能力"，因此必须在工具调用点将其约束回来。

那个常见的比喻——自动售货机 vs. 能动手的实习生——比喻本身正确，但理由需要修正：实习生之所以是实习生，并非因为你让他自行决定工作流程的循环结构，而是因为你把他放在了一间拥有真实电脑、能真实操作命令的办公室里；售货机之所以是售货机，是因为它只有几个预设按钮可供操作。差别在于"工具箱里是否有那把万能扳手"，而非"循环归谁管"。

维度	平台型	龙虾类（Claw）
loop 拓扑	框架固化（可视化/固定流程）	框架固化（内置 ReAct）——两者一致
工具性质	边界清晰的声明式 API	新增通用执行能力（shell/文件/代码）
行为确定性	可预测、易管控	不可预测（能力的代价）
擅长任务	流程固定、低风险	步骤不确定、需自主动手
治理重心	编排逻辑 + 数据权限	工具卡点：约束那把万能扳手

这张表的最后一行，就是全文的转折点：龙虾类的治理重心，不在于"编排逻辑是否正确"，而在于那把万能扳手能否在工具调用的卡点上有效收住。下面进入正题。

三、龙虾类生产化部署的安全（上）：六层纵深防御体系

先看一个反面教材。OpenClaw 是一个全类型 agent（对话、工具、代码、规划全覆盖），但其运行环境极端简单、近乎零隔离：一个 Node.js 进程裸跑在宿主操作系统上，直接读写真实的文件、执行真实的 shell，依赖"本地优先"把安全责任全部转嫁给用户。现实迅速给出了回应（据公开报道）：Gartner 将其评为"默认不安全"；Cisco 称其为"安全噩梦"；卡巴斯基审计发现 512 个漏洞，其中 8 个为严重级；2026 年 3 月中国限制国企和政府机构在办公电脑上运行它；最终 Nvidia 推出 NemoClaw + OpenShell 才为其补上沙箱以及网络/隐私护栏。

结论非常明确：能力越强，隔离需求越迫切。 龙虾类的能力来源于通用执行权限，风险同样来源于此。因此安全工作的本质不是"禁止执行"，而是在保留"能自主动手"的前提下，将"通用"重新约束为"受控"状态——给这把万能扳手加装一层层限位器。下面六层从外到内，任何一个层次单独都不可靠，金融环境需要的是深度叠加。

第一层：执行环境隔离（物理/虚拟边界）

这是基础。agent 的通用执行绝对不能跑在能够直接触及生产系统的宿主上。

具体落地方式：将其放入一次性、强隔离的沙箱中。容器需配置 gVisor 或 Kata 这类增强隔离运行时（而非裸 runc），或采用 microVM（如 Firecracker）。关键属性包括：每个会话或任务启动一个全新实例，用完即销毁（ephemeral），状态不跨任务残留；文件系统限制为最小必要集合，不挂载宿主敏感目录；最关键的是——网络默认全部断开，按需开放。

这一点与一直困扰团队的双机房分区问题直接相关：agent 沙箱应置于一个独立的受控执行区，它对任何机房、任何生产网段的访问，默认都不可达；如需访问某个服务，必须显式加入白名单，并且通过统一的 egress 袋口出口。这个 egress 袋口既是白名单闸口，也是天然的埋点采集点。过去"脚本被安全拦截"的纠结，在这一层可以转化为优势：将拦截从"事后阻断"升级为"出口处的策略闸门"。

第二层：身份与权限——使用"最小权限的影子身份"，而非人的凭证

金融环境中这一层是红线：agent 在执行环境内部绝不能持有真实的高权限凭证（数据库 root、生产 API key、运维账号）。

据公开报道，HiClaw 正是这个思路的实践案例——让 Worker agent 只获取消费级 token，真实凭证（API key、PAT）保留在 gateway 中，Worker 看不到具体内容。将其正式化就是：凭证与 agent 解耦。agent 要调用某个系统时，不是自身持有 key 去调用，而是向一个凭证代理（secrets broker）申请一次性、短时效、限定范围的临时凭证（类似 STS 的 assume-role 模式）——具有 TTL、scope、可即时吊销，且永远不进入 agent 的上下文窗口（否则会被日志记录、被 prompt 注入、被压缩记忆泄露出去）。权限模型应采用 ABAC（基于"哪个 agent + 哪个任务 + 哪个数据分级 + 哪个机房 + 什么操作"的组合判定），而非粗粒度的角色定义。

第三层：工具调用硬卡点——这是策略执行的咽喉要地

这是龙虾类安全中最值得深度投入的一层，前面所有的线索都指向这里。

每一次工具调用（尤其是 shell、文件、网络这三类通用工具）在正式执行之前，必须经过一个硬编码的策略检查点——不能仅在系统提示中写"请不要删库"这种软约束。这句话对金融场景是铁律：安全边界必须在代码层面强制实施，不能在 prompt 层面强制实施。 因为依赖 LLM 语义层去解释 SKILL.md、SOUL.md 这类自然语言约束，足够精巧的 prompt 注入就能将其绕过。

这个检查点上的判断逻辑，至少需要涵盖：命令或操作是否在白名单内（白名单优于黑名单——黑名单永远无法穷举）、目标路径是否在允许范围、目标网络是否属于该任务允许触及的机房分区、数据分级是否匹配 agent 权限、参数中是否包含危险模式。判断结果有四个出口：放行、改写（例如强制添加只读标志或限定目录）、拦截拒绝、放行但触发人工审批。

一个具体建议：将高危操作显式归类为"需要人工审批"类别——包括删除操作、写入生产库、对外发送数据、修改权限、跨分区访问等——让 loop 在这些节点停下来等待人工确认。这就是 human-in-the-loop 的硬约束版本，对不可逆操作尤其必要。第一章中提到的 guard_bash 就是这一层的雏形，需要做的将其从"经验拦截"正式化为"白名单 + 四出口 + 高危人工审批"的完整机制。

第四层：能力边界——从"能拦"升级到"压根没有能力"

比"拦截危险操作"更有效的方法，是让危险操作在环境中根本不存在。

能够通过环境层强制实施的，就不应仅依赖调用层判断：沙箱内直接挂载只读文件系统、使用 seccomp 限制可用的系统调用、通过 capability drop 去除危险内核能力、为 CPU/内存/磁盘/执行时长设置配额（防止失控循环消耗资源，也防止 agent 在某个 loop 中卡死）、网络层默认 deny-all egress 且 DNS 走受控解析（杜绝 agent 通过 curl 外传数据）。这一层的核心理念是：能力的缺失，比规则的拦截更可靠——拦截规则可能有遗漏，但不存在的能力根本无法被利用。

（顺带将"止损"机制整合进这一层：loop 不会自动停止，停止条件需要主动设计——迭代次数上限加上预算上限。据公开报道，Uber 今年为每位工程师设定了每人每工具每月 1500 美元的 AI 开支上限，因为年度预算在四个月内就消耗殆尽。没有止损机制的 loop，要么烧钱，要么"规模化地生产自信的错误"。）

第五层：全链路可观测与审计——金融环境的不可妥协项

在监管环境中，"做了什么"必须能够完整追溯——这也是一直以来埋点工作的最终归宿。

每一次模型决策、每一次工具调用（入参、出参、判定结果、放行或拦截）、每一次凭证申请、每一次跨分区访问，都必须生成不可篡改的审计日志。埋点最应该部署在两个关键位置：第三层那个策略检查点，以及第一层那个 egress 袋口——因为这两处是所有危险动作的必经之地，在此处采集既全面又难以绕过。（据公开报道，QwenPaw 将 loop 作为 Langfuse 的可观测归组单元，OpenClaw 的 gateway hooks 采集生命周期事件，这些都是天然的挂载点。）

关键要求：审计日志必须独立存储（agent 无法访问、无法修改）、必须能够还原完整的决策链（为什么调用这个工具、基于哪一步观察）、必须满足监管规定的留存周期。一旦出现问题，要能够复盘到具体哪一步、哪个判定放行了什么操作——这是金融环境上线生产的前提条件。

第六层：LLM 特有的攻击面——prompt 注入与数据外泄

这是龙虾类比传统系统多出来的、也最反直觉的一层，传统的纵深防御体系不覆盖它。

核心威胁是 prompt 注入：agent 处理的外部内容（一个文件、一个网页、一条工单、一段日志）中可能藏有恶意指令，诱导 agent 执行危险操作。它在金融环境中的可怕之处在于——攻击不一定来自用户，可能来自 agent 在工作过程中读取到的任何数据。

应对思路：将"数据"和"指令"在信任级别上分离开——agent 从工具结果中读取的内容，默认视为不可信数据，不能当作新指令进行权限提升；高危操作即使 agent "想"做，也必须经过第三层那个硬检查点和人工审批，确保注入即使发生也无法直接转化为危险执行；同时对 agent 的输出或外发内容也进行检查，防止其被诱导将敏感数据写入对外请求。这一层正是"硬卡点在 LLM agent 系统中比在传统系统中更不可或缺"的根本原因——因为它的"大脑"本身，可以被外部内容操纵。

四、龙虾类生产化部署的安全（下）：优先推进哪两处、守住哪条底线

将六层体系串联来看，这是一个纵深防御结构：隔离的沙箱（限制其在何处运行、能访问哪些网络）→ 影子身份与临时凭证（限制其以谁的名义、拥有多大权限）→ 工具调用硬卡点（限制其每一个具体动作）→ 能力边界（让危险动作在环境中不存在）→ 全链路审计（让一切可追溯）→ 注入防护（防止其大脑被外部数据劫持）。任何一层都不足以独立支撑，需要的是六层叠加后的整体韧性。

落到执行层面，最应该优先推进的是两个性价比最高的咽喉部位：

第三层那个硬编码策略检查点——将已有的 PreToolUse 和脚本拦截经验，正式化为"白名单 + 四出口判定 + 高危人工审批"的完整机制。
第一层那个统一 egress 袋口——将其同时打造为双机房分区的白名单闸口和埋点采集点，一次性解决网络分区约束与可观测需求。

因为所有危险动作都必须经过这两个咽喉，守住它们，投入产出比最高。

再把那条底线重申一遍，它是整个金融场景安全的根基：所有真正的安全边界，都必须在代码或基础设施层面强制实施，绝不能依赖写在 prompt 或 SKILL.md 中的自然语言约束——后者只是软约束，会被 prompt 注入绕过，只能作为辅助引导，不能作为防线。

五、落实到 AIOps：将自主性留给诊断，将确定性留给处置

讨论了龙虾类的能力与风险，落实到我们 AIOps 团队的选型上，最应该打破的还是那个"二选一"的惯性思维——平台型和龙虾类不是替代关系，而是沿着"故障处理链路"进行分层协同。在运维场景中，划分这两层的那条真正界限，不是"对外还是对内"，而是——这个动作是只读的诊断，还是会改变生产状态的处置。

平台型，适合掌控"确定性链路"和"写操作处置层"。 这一判断在其他行业可能违背直觉——平台型不是能力较弱吗，怎么反而掌管最关键的写操作？恰恰因为它能力"弱"（边界清晰、行为可预测），才有资格接触生产环境。那些流程已经固化为 SOP、动作集合有限且明确的场景——按预案重启服务、按既定规则扩缩容、执行已审批的标准变更、触发告警分级——应当采用平台型那种声明式、可视化、每一步都可审计的编排方式。它的核心价值在于可预测：你能够提前知道它会执行哪几个动作，能够在编排图上清晰看到合规边界，出现问题后能够精确复盘到哪个节点。对运维来说，凡是会改变生产状态、且步骤确定的处置任务，确定性比自主性更为宝贵。这一层，正是故障根因分析 agent 将诊断结论交出来之后、真正"动手"的阶段——动手要稳，要框定范围。

龙虾类，适合处理"不确定诊断层"和"研发/知识提效层"。 真正需要请出龙虾的，是那些步骤无法事先预案化、必须边排查边思考的任务。故障排查最为典型——一个未曾见过的告警，根因可能在应用、中间件、网络、数据库任意一层，没有哪份 SOP 能够预先罗列所有排查步骤，必须让 agent 自行翻日志、grep 指标、串联多个系统的现象、形成假设并进行验证。这种"走一步看一步"的诊断模式，正是 ReAct loop 加通用执行能力的主场，平台型那种预设按钮根本无法覆盖排查路径的组合爆炸数量。同样适合龙虾的场景还包括：将 SOP 转写为 SKILL.md 这类知识工程处理、研发效率提升、日志知识库构建等。但有一个对于 AIOps 来说被放大的硬前提——龙虾类在生产环境中，默认只能赋予只读权限。 让它自由地查询、自由地诊断、自由地推理，但得出的处置建议，要么交由人工复核，要么交给上面那层确定性的平台型去执行；它那把"万能扳手"在生产网段中，默认只能查看、不能修改。

将两层衔接起来，就是 AIOps 场景中最应该采用的协同范式：龙虾类负责"想清楚发生了什么"，平台型负责"以确定的方式将其修复"。 龙虾在严格沙箱、网络分区、只读凭证的条件下自主诊断出根因，输出结构化的处置方案；该方案经过人工复核或策略闸门后，交由平台型的确定性编排执行写操作。诊断需要自主与灵活，因此用龙虾；处置需要可控与可审计，因此用平台型——正好将两者的长处放在各自能够担当的位置上。

因此选型时，首先应该问的不是"这个场景够不够酷、要不要上自主 agent"，而是连续追问三个问题：

这个任务的步骤是确定的，还是需要边执行边思考？
它是只读诊断，还是会改写生产状态？
如果出现错误，是可逆的，还是不可逆的？

步骤确定、会写入生产、且不可逆的任务——生产库变更、对外数据操作、核心服务的处置动作——即使看起来简单，也应走平台型的确定性链路，宁可牺牲一点灵活性也要换取可预测性；这不是杀鸡用牛刀，而是该用重器的地方就必须用重器。真正值得请出龙虾的任务，是那些没有自主性就根本无法完成（步骤不可预案化的诊断、排查、知识处理）、且你确实能将其关进只读笼子里的任务。

六、结语

回到开头那句"我的工作是写 loop"。

写 loop 当然重要，但这篇文章想传达的是：当龙虾类智能体真正从个人玩具走进企业生产——当它在公司的机房里能够读写文件、执行命令、自主操作——真正的功课不在 loop，而在于能否将那把"万能扳手"收入笼中。龙虾类不是平台型的升级版，而是另一套权衡体系：你获得了"能在真实环境中自主解决问题"的能力，也就同时接管了"行为不可预测"的风险，以及"安全需要自己一层层兜住"的责任。

而对于做金融运维的我们来说，这套权衡最终会收敛成一句话：将自主性留给诊断，将确定性留给处置。 让龙虾在只读的笼子里自由地想清楚"发生了什么"，让平台型以可审计的确定性编排稳稳地"将其修复"——这条线划对了，龙虾类才能既上线生产，又不会变成悬在生产稳定性头顶那把不可预测的剑。

模型还会继续变强，agent 会越来越敢于动手。我的判断是，这反而让安全设计更具价值——引擎越猛，方向和刹车越不能省略。一句话收尾：先将那六层笼子搭建好、划清诊断与处置的边界，再决定是否要将"龙虾"放入生产环境。