龙虾类 Agent 上生产：在 loop 之外，安全才是胜负手

前记

最近 loop 突然火了。

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（官方自称 🦞 "the lobster way"）、阿里通义的 QwenPaw、还有把 Claude Code 打包成库的 Claude Agent SDK。龙虾最显眼的就是那对大钳子，这类智能体最显眼的本事，恰恰也是那对能自己动手的"爪子"。

这篇文章就顺着这条线走：先认清龙虾类到底特殊在哪、它和平台型智能体真正的分界是什么（剧透：根本不在 loop），然后把重头戏放在——龙虾类上生产，安全怎么做。

撂一个反直觉的结论在前面：龙虾类不是平台型智能体的"升级版"，而是另一套权衡。 能力越强 = 风险越大 = 合规成本越高。它能上生产，靠的是一把"万能扳手"；能不能在金融这种环境上生产，胜负手就在于——能不能把这把万能扳手收住。

一、先认清龙虾类：能在通用执行环境里自主动手

要谈安全，先得说清它危险（也强大）在哪。

很多人把龙虾类的特殊之处归结为"它能自己写代码"。这个说法不算错，但抓偏了。真正的区别不是"能不能写代码"，而是"agent 能不能在一个通用执行环境里自主动手解决问题"。 写代码并运行，是这种能力最典型、最强的表现形式，但同一种能力也表现为：执行任意命令、读写任意文件、调用脚本、操作一个真实的终端。

对照平台型就清楚了：

• 平台型智能体给 agent 的工具，是一组边界清晰的声明式 API——查个余额、发个工单、调个模型。哪怕其中包含一个"代码执行"工具，那也通常是受限的、沙箱化的、只能干特定事的。
• 龙虾类智能体给的是对真实环境的开放操作权——一个能跑任意命令的 shell、一个能读写任意文件的文件系统、一个真实的沙箱/终端。

所以"能自己写代码"是个好用的识别信号，但别把它当成定义——定义是"通用执行环境的开放程度"。 这把"万能扳手"，就是龙虾类全部能力与全部风险的共同来源，后面整篇都围着它转。

龙虾家族里几个主要成员，正好对应本文两个真实案例：

• Claude Agent SDK：把驱动 Claude Code 的那套内核打包成库，"让你的代码成为驱动者"。案例一就是它——某企业把龙虾类智能体推上生产，底层用的就是它。（旁证：据公开报道，Spotify 用它构建 fleet-wide 代码迁移 agent，省了约 90% 工时、每月 650+ PR 合并入生产。）
• QwenPaw：阿里通义 AgentScope 团队出品、Apache 2.0、内置 ReAct loop，能力栈很全（聊天入口 + 记忆 + 工具 + Skills + MCP + 多 Agent + 安全守卫 + 主动心跳）。案例二就是它——笔者公司拿它做数字员工的基座，部署在生产。
• OpenClaw：Node.js 写的个人 AI 助手、"self-hosted gateway"，官方把信任模型定为"单一可信操作者边界"，不适合敌对多租户。它后面会作为"安全反面教材"出场。

下面这段 Claude Agent SDK 的代码（真实接口，SDK 演进很快、以官方文档为准）值得先看一眼——记住里面那个 guard_bash，它就是第三章"工具调用硬卡点"的雏形：

Python

import anyio
from claude_agent_sdk importquery,ClaudeAgentOptions

# PreToolUse 钩子：高危命令直接拒绝
# （给"万能扳手"装的第一道限位器）
asyncdefguard_bash(input_data,tool_use_id,context):
    ifinput_data["tool_name"]=="Bash":
        cmd=input_data["tool_input"].get("command","")
        bad=("rm -rf","drop table","shutdown")
        ifany(kincmdforkinbad):
            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",
)

asyncdefmain():
    asyncformsginquery(
        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：调模型 → 看返回里有没有工具调用 → 有就执行再喂回 → 没有就退出。它能写的位置其实有三层——① 裸手写（无框架）② 编排框架里描述拓扑（LangGraph、AgentScope 这类）③ 成型 runtime 里"不写"只填空。龙虾类属于第三层：loop 早被框死，你只配 prompt、挂工具、插 hooks，根本不重画它。（顺带一提：LangGraph、AgentScope 是第二层的"编排底座"，不是龙虾类——你用 AgentScope 搭出来的 QwenPaw 才是龙虾。）

笔者一开始以为龙虾类与平台型的分界线是"loop 控制权"，是站不住的。真正的分界是另外两点：

1. 工具的性质。 平台型给的是一组边界清晰的声明式 API；龙虾类在此之外，还给了通用执行能力（shell / 文件系统 / 代码执行 / 真实终端），让 agent 能在真实环境里自主"动手"。
2. 由此带来的"确定性 vs 能力"权衡。 声明式 API 行为可预测、易管控，但干不了步骤不确定的活；通用执行能干那些"边做边想、需要真动手"的活，但代价是行为不再可预测——这就是为什么龙虾类的安全机制会成为重点：风险是从"开放了通用执行能力"这里冒出来的，得在工具调用那个卡点把它框回去。

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

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

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

这一章是架构与安全设计层面的讨论，给的是工程上成立的纵深防御范式，不是合规结论。具体到能不能这么落地，得过信息安全、合规和监管报备那一关。

先看一个反面教材。OpenClaw 是个全类型 agent（对话、工具、代码、规划全占），可它的运行环境是极端的 L1、几乎零隔离：一个 Node.js 进程裸跑在宿主操作系统上，读写你真实的文件、执行你真实的 shell，靠"本地优先"把安全责任全甩给用户。现实很快给了答案（据公开报道）：Gartner 称其"默认不安全"；Cisco 称其为"安全噩梦"；卡巴斯基审计出 512 个漏洞、其中 8 个严重；2026 年 3 月中国限制国企和政府机构在办公电脑上运行它；最后 Nvidia 拿出 NemoClaw + OpenShell 才给它补上沙箱与网络/隐私护栏。

结论很硬：能力越强、越要隔离。 龙虾类的能力来自通用执行权，风险也来自它。所以安全工作的本质不是"禁掉执行"，而是在保留"能自主动手"的前提下，把"通用"重新收成"受控"——给这把万能扳手套上一层层限位器。下面六层从外到内，任何一层单独都不够，金融环境要的是纵深叠加。

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

这是地基。agent 的通用执行绝不能跑在能直接碰到生产系统的宿主上。

落地方式是把它放进一个一次性、强隔离的沙箱：容器要配 gVisor / Kata 这类增强隔离运行时（而不是裸 runc），或用 microVM（Firecracker）。关键属性：每个会话/任务起一个全新实例、用完即焚（ephemeral），状态不跨任务残留；文件系统是受限的最小集，不挂载宿主敏感目录；最重要的是——网络默认全断、按需放行。

这一点和笔者一直头疼的双机房分区直接相关：agent 沙箱应待在一个独立的受控执行区，它对任何机房、任何生产网段的访问，默认都进不去；要访问某个服务，必须显式加白名单，且走一个统一的 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、文件、网络这三类通用工具）在真正执行前，必须经过一个硬编码的策略检查点——不是靠系统提示里写"请不要删库"这种软约束。这句话对金融场景是金科玉律：安全边界必须在代码里 enforce，不能在 prompt 里 enforce。 因为靠 LLM 语义层去解释 SKILL.md / SOUL.md 之类的自然语言约束，足够精巧的 prompt 注入就能绕过。

这个检查点上的判定，至少包括：命令/操作是否在白名单内（白名单优于黑名单——黑名单永远列不全）、目标路径是否在允许范围、目标网络是否在该任务允许触达的机房分区、数据分级是否匹配 agent 权限、参数里有没有危险模式。判定结果有四个出口：放行 / 改写（比如强制加只读标志、限定目录）/ 拦截拒绝 / 放行但触发人工审批。

一个具体建议：把高危操作显式枚举成"需要人工审批"类——删除、写生产库、对外发数据、改权限、跨分区访问——让 loop 在这些点上停下来等人。这就是 human-in-the-loop 的硬约束版本，对不可逆操作尤其必要。第一章那个 guard_bash 就是这层的雏形，要做的就是把它从"经验拦截"正式化成"白名单 + 四出口 + 高危人工审批"。

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

比"拦截危险操作"更强的一招，是让危险操作在环境里根本不存在。

能用环境层 enforce 的，就不要只靠调用层判断：沙箱里直接挂只读文件系统、用 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 上比在传统系统上更不可省"的根本原因——因为它的"大脑"本身，是可被外部内容操纵的。

四、龙虾类上生产的安全（下）：先动哪两处、守住哪条底线

把六层串起来看，是一个纵深结构：隔离的沙箱（限制它在哪跑、能碰到什么网络）→ 影子身份 + 临时凭证（限制它以谁的名义、有多大权）→ 工具调用硬卡点（限制它每一个具体动作）→ 能力边界（让危险动作压根不存在）→ 全链路审计（让一切可追溯）→ 注入防护（让它的大脑不被外部数据劫持）。任何一层都不足以独撑，要的是六层叠加后的整体韧性。

落到手上最该先动的两处，是性价比最高的两个咽喉：

1. 第三层那个硬编码策略检查点——把已有的 PreToolUse / 脚本拦截经验，正式化成"白名单 + 四出口判定 + 高危人工审批"。
2. 第一层那个统一 egress 代理——把它同时做成双机房分区的白名单闸口和埋点采集口，一举解决网络分区约束与可观测需求。

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

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

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

讲了半天龙虾类的能力与风险，落到我们 AIOps 团队的选型上，最该破掉的还是那个"二选一"的执念——平台型和龙虾类不是替代关系，而是沿着"故障处理链路"的分层协同。 而在运维场景里，划分这两层的那条真正的线，不是"对外还是对内"，而是——这个动作是只读的诊断，还是会改变生产状态的处置。

平台型，适合压住"确定性链路"和"写操作处置层"。 这话在别的行业可能反直觉——平台型不是能力弱吗，怎么反而管最关键的写操作？恰恰因为它能力"弱"（边界清晰、行为可预测），才配得上碰生产。那些流程已经固化成 SOP、动作集合有限且明确的场景——按预案重启服务、按既定规则扩缩容、执行已审批的标准变更、触发告警分级——就该走平台型那种声明式、可视化、每一步可审计的编排。它的价值就是可预测：你能提前知道它会做哪几个动作，能在编排图上一眼看清合规边界，出了事能精确复盘到哪个节点。对运维来说，凡是会改变生产状态、且步骤确定的处置，确定性比自主性金贵得多。这一层，正是笔者那个故障根因分析 agent 把诊断结论交出去之后、真正"动手"的那一段——动手要稳，要框死。

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

把两层串起来，就是 AIOps 场景里最该采用的协同范式：龙虾类负责"想清楚发生了什么"，平台型负责"按确定的方式把它修好"。 龙虾在严格沙箱、网络分区、只读凭证下自主诊断出根因，产出一个结构化的处置方案；这个方案过人工复核或策略闸门后，交由平台型的确定性编排去执行写操作。诊断要自主、要灵活，所以用龙虾；处置要可控、要可审计，所以用平台型——恰好把两者的长处，放在了各自扛得住的位置上。

所以选型时，先问的不该是"这个场景酷不酷、要不要上自主 agent"，而是连着问三句：

1. 这个任务的步骤是确定的，还是要边做边想？
2. 它是只读诊断，还是会改写生产状态？
3. 如果出错，是可逆的，还是不可逆的？

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

六、结语

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

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

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

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