文章总结： 本文基于ClaudeCode架构分析大模型系统安全边界，指出生产级AIAgent的可靠性不仅依赖模型能力，更取决于围绕模型构建的工程系统（Harness）。文章详细拆解了其高层结构、AgentLoop反馈闭环及七项核心安全机制，包括默认拒绝与人工升级、分级信任、纵深防御等，强调可控AI需从结果审查转向过程控制，为AI系统进入真实生产环境提供了安全设计框架。 综合评分： 88 文章分类： AI安全,应用安全,安全建设,安全开发,解决方案

---

从 Claude Code 架构出发，如何理解大模型的系统安全边界

薄说安全 薄说安全

薄说安全

2026年6月22日 06:00 北京

在小说阅读器读本章

去阅读

最近读了论文《Dive into Claude Code: The Design Space of Today’s and Future AI Agent Systems》

这篇论文很有意思。它不是 Claude Code 使用教程，也不是在讨论“大模型会不会写代码”。它做的是另一件事：基于公开的 Claude Code TypeScript 源码，拆解一个现代生产级 AI Agent 系统到底是怎么运转的。

换句话说，它不是看模型怎么回答，而是看一个 AI 系统怎么行动。

这正是今天最值得关注的变化。

当 AI 只能回答问题时，我们主要关心它说得对不对。 当 AI 可以读文件、改代码、执行命令、调用外部工具、维护会话状态、委派子任务时，它就不再是一个聊天窗口。

它变成了一个会影响真实工作环境的自动化系统。

这时，我们的问题也必须升级：

• 它能做什么？
• 它不能做什么？
• 什么时候必须停下来？
• 哪些动作需要人确认？
• 做错以后能不能发现？
• 过程能不能追溯？
• 结果能不能验证？

这就是可控 AI 的问题。

Claude Code 提供了一个很好的样例。它不是靠一个模型单独完成工作，而是通过一套围绕模型建立的系统 harness，把模型、工具、权限、上下文、状态和执行环境组织起来。

当然，这篇论文的分析基于公开源码，能说明实现结构，但不一定等同于 Anthropic 的官方设计意图。即便如此，它仍然给我们提供了一个观察未来 AI Agent 的窗口。

下面先看论文中的几个核心思想：Claude Code 的高层系统结构、Agent Loop、安全机制和扩展机制。最后，再从功能安全角度谈一谈：当大模型进入轨道交通生产系统，安全评估应该看什么。

一、Claude Code 的高层系统结构：模型只是系统的一部分

图 1：Claude Code 的高层系统结构

这是理解 Claude Code 的入口。它把 Claude Code 分成七个功能组件：User、Interfaces、Agent Loop、Permission System、Tools、State & Persistence、Execution Environment。

看起来是七个模块，背后其实是一条非常清晰的控制链。

User 是用户。用户提出目标，而不是指定每一步操作。比如用户说：“修复 auth.test.ts 中失败的测试。”接下来系统会自己判断要读哪些文件、运行哪些命令、修改哪些内容。

Interfaces 是交互入口。用户可以通过命令行、IDE、SDK 或其他界面进入系统。但不管入口是什么，最终都会汇聚到同一个 Agent Loop。

Agent Loop 是核心循环。它接收任务、组装上下文、调用 Claude 模型、解析模型输出、发现工具调用请求、把请求交给权限系统、接收工具结果，然后再次调用模型，直到任务完成或停止。

Permission System 是权限系统。模型不能直接执行动作，只能提出动作。这个动作是否允许，要由权限系统判断。

Tools 是工具。工具是 Agent 能力的实际来源。模型自己不能读文件、改文件、跑命令、访问 Web 或调用 MCP 服务。它必须通过工具完成这些动作。

State & Persistence 是状态与持久化系统。它负责记录会话历史、工具调用、执行结果、压缩边界和恢复信息。一个可控系统不能只看最后结果，还必须能回答：它为什么这么做？做过什么？谁批准过？结果从哪里来？

Execution Environment 是执行环境。真实动作发生在这里，包括文件系统、Shell、Web、MCP 服务、本地或远程运行环境。AI 从“生成文本”变成“改变环境”，风险也随之从文本错误变成系统行为错误。

把这条链路连起来，就是 Claude Code 的基本运行方式：

图 2：Claude Code 的任务执行流程

这张图最重要的启发是：Claude Code 并不是模型直接操作真实世界。

模型负责推理和提出动作，但它不直接读取文件、不直接修改代码、不直接执行 shell 命令。真正执行动作的是工具；决定动作能不能发生的是权限系统；承接影响的是执行环境；保存过程证据的是状态与持久化系统。

文中用 harness 来概括这一套运行机制。可以把 harness 理解为围绕大模型的一整套运行支架和控制外壳。它包括工具调用、权限判断、上下文管理、状态记录、错误恢复、沙箱隔离等机制。

如果打个比方：

• 模型像大脑。
• 工具像手脚。
• 执行环境像现实世界。
• harness 像神经系统、操作规程、安全边界和日志系统的组合。

这个理解很关键。今天很多人讨论 AI 系统时，容易把注意力全部放在模型上，仿佛模型越强，系统就越可靠。但从 Claude Code 的架构看，生产级 AI Agent 的可靠性和可控性，很大一部分来自模型之外的工程系统。

二、Agent Loop：AI Agent 的核心是反馈闭环

图 3：Claude Code 的一次 agentic turn 运行流程

这里的 turn，不是普通聊天里的“一问一答”。它是一轮带有上下文组装、模型调用、工具执行、结果反馈和继续判断的任务执行过程。

例如用户输入：

Fix the failing test in auth.test.ts

Claude Code 不会只生成一段建议。

它会先把用户请求、系统提示、项目规则、可用工具、历史对话、文件内容、命令结果等信息组装成上下文，然后调用模型。

模型根据当前上下文判断下一步。可能先读取测试文件,可能搜索相关实现,可能运行测试命令,也可能修改代码。

如果模型提出工具调用，系统会进入权限判断和工具执行。工具执行后，结果返回给 Agent Loop，再进入下一轮模型调用。模型根据新的观察结果继续判断下一步，直到任务完成、发生错误、权限被拒绝、上下文需要压缩，或者用户中断。

所以，Claude Code 的核心不是“一次生成”，而是一个循环。

图 4：Claude Code 的运行循环

这就是 AI Agent 和普通聊天系统的本质区别。普通聊天系统主要给出回答。AI Agent 则围绕目标持续行动。它会把错误、权限拒绝、命令输出、测试失败都当作新的输入，然后修正路径。

这种闭环能力，是 Claude Code 能够处理复杂编码任务的基础。

第 4 节对这个流程做了更细的拆解。每一轮执行包括设置解析、状态初始化、上下文装配、模型调用、工具分发、结果处理、恢复机制和停止条件。

看起来像一个简单的 while-loop。

但真正复杂的，不是循环本身。真正复杂的是循环周围的支撑机制。

Claude Code 没有把大量复杂规划逻辑写死在系统里。它更倾向于让模型基于上下文做判断，而系统提供稳定的工具、权限、状态和恢复机制。

论文把这种思路称为 minimal scaffolding with maximal operational harness。可以理解为：少做显式决策脚手架，多做运行支撑。

为什么这样设计？

如果把所有任务都拆成固定流程，系统会很僵硬，很难适应真实项目的复杂情况。 如果完全依赖模型自由发挥，系统又会失去控制。

Claude Code 的选择，是在两者之间取平衡：模型负责灵活判断，harness 负责确定性约束。

这也给可控 AI 一个重要启发。

当 AI 只是生成一段文字时，我们只需要审查结果。 当 AI 进入闭环执行时，我们必须审查过程。

• 它为什么读这个文件？
• 为什么运行这个命令？
• 为什么修改这段代码？
• 失败以后如何恢复？
• 上下文变长以后如何压缩？

这些都不是模型能力问题，而是系统工程问题。没有过程控制，AI Agent 就会变成一个“看起来很聪明、实际不可解释”的自动化黑箱。

三、安全机制：从设计原则看 Claude Code 如何建立控制边界

Claude Code 最值得学习的，不只是它能做什么，而是它如何限制自己不能乱做。

1. Deny-first with human escalation：默认拒绝，再升级给人

这是 Claude Code 安全机制中最核心的原则。

模型提出工具调用以后，动作不会直接执行，而是进入权限系统。权限系统会结合权限模式、规则评估、hook、分类器、沙箱等机制，判断该动作是允许、拒绝，还是需要询问用户。

图 5：Claude Code 的权限系统

deny-first 的意思很简单：当系统不能确认一个动作安全、被授权、符合当前上下文时，不默认放行，而是拒绝或升级给用户。

这个原则非常关键。

AI Agent 的风险，很多时候不是来自明显恶意的命令，而是来自更隐蔽的情况：

• 模型误解用户目标；
• 上下文混入错误信息；
• 外部文档包含提示注入；
• 工具调用范围被逐步扩大；
• 模型把“建议”理解成“执行”；
• 用户没有明确授权高风险动作。

如果这些情况默认放行，AI 的不确定性就会直接变成真实环境中的动作。

deny-first 的作用，就是在边界不清时让系统停下来。

这和功能安全中的 fail-safe 思想很接近：当状态不确定时，不应继续扩大风险，而应进入更安全的状态。

2. Graduated trust spectrum：信任不是二元，而是分级

Claude Code 并不是简单地把 AI 分成“允许执行”和“禁止执行”两种状态。

Claude Code 有多种权限模式，包括 plan、default、acceptEdits、auto、dontAsk、bypassPermissions、bubble 等。不同模式代表不同的信任等级和控制策略。

plan 模式强调先规划、后执行。 default 模式下许多操作需要用户确认。 acceptEdits 模式允许部分文件编辑自动通过。 auto 模式引入分类器判断动作风险。 bypassPermissions 更宽松，但仍可能保留部分安全检查。 bubble 用于特定子 Agent 场景中的权限升级。

这体现的是分级信任，而不是二元信任。

低风险动作自动执行
中风险动作限定范围
高风险动作询问用户
不可接受动作默认拒绝

真正有效的控制，不是每一步都让人确认，也不是完全放开自动化，而是让权限和风险等级匹配。

否则就会走向两个极端。

一边是系统过于保守，AI 很难真正提高效率。 另一边是系统过于激进，AI 很容易越过用户实际意图。

这也解释了为什么“人在环”不能简单等同于“弹窗确认”。如果系统频繁要求用户确认，用户很容易产生确认疲劳，最后习惯性批准。

此时，人在环只是形式。人的真实控制权反而被削弱了。

3. Defense in depth：纵深防御

Claude Code 的安全，不是靠某一个按钮、某一句提示词或某一次人工确认完成的。

它靠的是多层机制叠加。

• 工具可见性过滤；
• 权限规则；
• 用户确认；
• PreToolUse 和 PostToolUse hooks；
• auto-mode classifier；
• shell sandboxing；
• 子 Agent 工具限制；
• 会话记录和 sidechain transcripts；
• resume 时不恢复临时权限。

这就是纵深防御。

权限门是在工具调用前做判断。上下文构造是在模型判断前控制它能看到什么。沙箱是在工具执行时限制影响范围。持久化系统是在动作发生后保留证据。子 Agent系统是在任务分解时建立隔离边界。

这些层次不是互相替代，而是互相补充。

安全系统有一个基本经验：不能假设某一层永远有效。

• 用户可能疲劳批准。
• 模型可能误判。
• hook 可能配置不当。
• 工具可能被误用。

所以，系统必须让不同层次共同承担风险控制。

4. Externalized programmable policy：安全策略要外部化、可编程

Claude Code 没有把所有安全策略都写死在核心代码里。

它通过 hooks、settings、权限规则、MCP 配置、插件机制等方式，把一部分策略外部化。

这样做的好处是，安全策略可以根据项目、组织和任务类型调整。个人项目，可以允许更多自动编辑。企业代码库，可以限制 shell 命令。安全相关项目，可以要求所有高风险工具调用必须确认。受监管场景，可以增加日志、审计和审批规则。

AI Agent 不应该只有一套固定的安全姿态。不同组织、不同项目、不同风险等级，需要不同控制策略。但外部化也带来新的风险。hooks、插件、MCP server 本身也可能成为攻击面。因此，外部化策略必须和插件审查、配置管理、权限隔离结合起来。

5. Reversibility-weighted risk assessment：根据可逆性评估风险

不是所有动作的风险都一样。

• 读取文件，通常比修改文件风险低。
• 修改草稿，通常比修改配置风险低。
• 本地测试，通常比部署生产环境风险低。
• 可回滚操作，通常比不可逆操作风险低。
• 生成建议，通常比直接执行动作风险低。

Claude Code 的权限模式和工具控制，本质上就在处理这个问题：哪些动作可以自动执行，哪些动作需要确认，哪些动作必须拒绝。

这对 AI Agent 尤其重要。

因为 Agent 的动作是一连串发生的。低风险动作可能逐步滑向高风险动作。先读取文件,再修改代码,再运行命令,再提交变更。

每一步单看都可能合理，但组合起来就可能产生较大影响。

所以，可控 AI 需要动态判断动作风险，而不能只在任务开始时一次性授权。

6. Isolated subagent boundaries：子 Agent 必须有隔离边界

Claude Code 支持子 Agent 委派。子 Agent 可以负责探索代码、制定计划、执行验证等局部任务。它们可以有独立上下文、独立工具集、独立权限和独立记录。

这个设计的安全意义在于：复杂任务可以拆分，但权限和上下文不应无边界共享。

如果所有子任务都继承主 Agent 的完整上下文和完整权限，那么委派就会扩大风险。

Claude Code 通过隔离子 Agent，减少上下文污染、权限外溢和任务越界。

子 Agent 的 sidechain transcripts 也很重要。父 Agent 可以只接收摘要，但系统仍然保留子 Agent 的详细过程，便于追溯。

7. Append-only durable state：安全需要可追溯的状态记录

Claude Code 的会话持久化采用接近追加式的 transcript 记录。这和安全强相关。如果 AI Agent 做了很多动作，但系统无法回答下面这些问题，就谈不上真正可控：

• AI 读了哪些文件？
• 调用了哪些工具？
• 运行了哪些命令？
• 哪些动作被用户批准？
• 哪些动作被系统拒绝？
• 最终结论依据哪些结果？

追加式记录的价值，不只是“下次可以继续”。

更重要的是审计、复盘、追责和恢复。

还有一个设计特别值得注意：resume 会恢复消息和上下文，但不会自动恢复会话级临时权限。

也就是说，昨天用户临时允许的高风险动作，今天恢复会话时不会默认继续有效。这体现了安全授权的上下文敏感性。恢复工作状态是一回事。恢复安全授权是另一回事。临时许可不能因为会话恢复而变成长期许可。

8. Context as scarce resource：上下文也是安全资源

这个原则看起来像效率问题，其实也是安全问题。

论文中的 Figure 6 展示了 Claude Code 的上下文构造和记忆层级。模型每次被调用时看到的内容，并不只是用户当前输入，而是系统提示、环境信息、CLAUDE.md、自动记忆、路径规则、工具定义、对话历史、文件读取结果、命令输出、子 Agent 摘要和压缩摘要等多种信息的组合。

图 6：Claude Code 的上下文构造和记忆层级

模型基于上下文做判断。所以，上下文本身就是安全边界。

• 上下文缺失，模型可能忘记任务范围；
• 上下文过期，模型可能遵循旧规则；
• 上下文污染，模型可能被提示注入误导；
• 上下文压缩不当，模型可能丢失关键安全约束。

Claude Code 把上下文当成稀缺资源，通过 CLAUDE.md 层级、path-scoped rules、auto memory、skills、compaction pipeline 等机制管理上下文。

可控 AI 不仅要控制 AI 能调用什么工具，还要控制 AI 基于什么信息做判断。

总结，Claude Code 的安全机制不是单点功能，而是一套系统性控制：默认拒绝、分级信任、纵深防御、外部化策略、可逆性风险评估、子 Agent 隔离、持久化记录和上下文治理，共同构成了它的安全边界。

四、扩展机制：能力来自工具生态，风险也来自工具生态

Claude Code 的扩展机制，包括 MCP、Plugins、Skills 和 Hooks。扩展不是简单加功能，而是在循环的不同位置影响系统行为。

Agent Loop 中的扩展位置概括为三个点：

• assemble：控制模型看到什么；
• model：控制模型能调用什么；
• execute：控制动作如何执行。

MCP 主要用于外部工具集成。通过 MCP，Claude Code 可以连接数据库、内部服务、企业系统或外部 API。

Plugins 用于打包和分发一组工具、skills、hooks 等能力。

Skills 提供领域特定指令，让模型知道某类任务应遵循什么流程或规则。

Hooks 则可以在工具执行前后进行拦截、校验、记录或修改。

这说明 AI Agent 的能力，不只是来自模型参数，而是来自模型与工具生态的组合。

一个没有工具的模型，主要影响文本。一个拥有文件工具、shell工具、MCP、接入发布工具的 Agent，可以影响真实业务流程。工具生态越强，AI 的行动能力越强。但同时，风险边界也越大。

未来 AI 系统的竞争，不只是模型能力竞争，也是工具组织能力、权限治理能力和上下文工程能力的竞争。

所以，我们不能只问：AI 能不能接更多工具？

还要问：

• 这些工具是否分级？
• 调用参数是否校验？
• 高风险工具是否需要确认？
• 工具执行是否被记录？
• 插件来源是否可信？
• hook 是否可能引入新的风险？
• 外部系统是否允许 AI 直接访问？

Claude Code 的设计空间说明，扩展机制本身有不同的上下文成本和安全成本。

Skills 会进入模型上下文，影响模型判断。 MCP 会增加可调用工具，扩大行动边界。 Hooks 可以改变执行生命周期，增强控制，也可能带来新的攻击面。 Plugins 方便复用和分发，也会带来供应链风险。

因此，可控 AI 不是拒绝扩展，而是让扩展进入治理框架。

对企业来说，未来使用 AI Agent 很可能不是“买一个模型”这么简单，而是要建立一套 AI 工具治理体系。从 Claude Code 看，可控 AI 的真正基础，是把模型能力放进一个可治理的工具生态中。

五、功能安全角度看可控 AI 应用

我从事功能安全相关工作。因此读这篇论文时，思考如果大模型技术进入轨道交通生产系统，如何做到可控？

这里说的生产系统，不是办公场景里的知识助手，而是可能参与列车运行、调度指挥、设备维护、故障处置、乘客服务、应急辅助决策等实际业务流程的系统。

一旦 AI 的输出会影响运营人员判断、系统控制策略、维护处置流程，甚至间接影响行车安全，它就不能再被当作普通信息化工具看待。

功能安全的基本前提是：系统可能失效，人可能误操作，环境可能异常，软件可能存在系统性缺陷。

因此，安全评估不能建立在几个乐观假设上：

“模型足够聪明。” “回答大多数时候正确。” “人会自己判断。” “出了问题再纠正。”

这些都不够。

更合理的评估思路，是把大模型看成一个具有不确定性的功能组件，检查它被放在什么位置，拥有多大权限，错误如何传播，系统如何限制影响。

结合 Claude Code 的架构，轨道交通生产系统引入大模型时，我认为至少要重点检查八个方面。

第一，检查 AI 在系统中的功能定位和安全边界。

大模型到底是只提供信息提示，还是参与决策建议？ 是只做离线分析，还是接入在线生产流程？ 是只读数据，还是可以触发工单、下发指令、调整参数、影响控制策略？

这一步非常关键。

同样叫“大模型应用”，风险等级可能完全不同。

如果 AI 只是对运行日志做离线总结，它更接近信息辅助工具。 如果 AI 在调度界面给出行车调整建议，它已经会影响人的决策。 如果 AI 可以自动触发处置流程或控制命令，它就进入了安全相关功能链条。

安全评估首先要把边界问清楚：

• AI 输出是否参与安全相关决策？
• AI 是否位于安全功能链路中？
• AI 输出错误会影响哪些人、哪些设备、哪些流程？
• AI 是否具备直接或间接执行能力？
• AI 与既有信号、调度、通信、维护系统之间的接口边界是什么？

只有先确定功能定位，才能判断后续需要多高等级的控制措施。

第二，检查 AI 输出错误的危害和失效模式。

传统软件的失效模式相对容易枚举，例如计算错误、通信超时、状态机异常、数据丢失等。

大模型不一样。

它的失效模式包括幻觉、遗漏、过度自信、上下文误解、提示注入、知识过期、输出不一致、同一问题多次回答不同等。

在轨道交通场景中，这些失效可能带来实际危害。

AI 错误解释故障原因，可能误导维护人员。 AI 漏掉关键报警，可能延误处置。 AI 给出不适当的调度建议，可能增加运营风险。 AI 把非安全相关信息包装成确定结论，可能影响人员判断。

所以，安全评估不能只看模型准确率。

更要围绕具体场景做危害分析：

• AI 可能给出哪些错误输出？
• 错误输出会通过哪些界面、人员或系统继续传播？
• 人员是否容易识别 AI 错误？
• 错误是否会导致危险侧失效？
• 系统是否有独立校验或防护措施？
• 当 AI 无法判断时，是否会明确表达不确定，而不是强行给结论？

关键不是问“回答准不准”，而是问“错误如何进入运营流程并形成风险”。

第三，检查权限控制和人机责任边界。

Claude Code 给我们的一个重要启发是：模型不能直接操作真实环境，必须通过工具、权限和执行环境。

这个思想放到轨道交通生产系统中更重要。

如果 AI 接入生产系统，评估时必须检查它是否具备操作权限，以及权限如何受控。

重点要看：

• AI 是否只能读取数据，还是可以写入数据？
• AI 是否可以触发工单、告警、流程或控制命令？
• 高风险动作是否必须由授权人员确认？
• 确认界面是否清楚展示 AI 建议的依据和影响？
• 人员是否有足够信息判断 AI 建议是否可采纳？
• AI 建议和人工决策在日志中是否能够区分？
• 最终责任是否明确归属于人、系统还是组织流程？

特别要警惕一种情况：界面上看起来是“人确认”，但人只是点击 AI 推荐按钮，并没有足够证据判断。

这种人在环，只是形式。不能构成真实控制。

在安全相关系统中，人机界面必须支持有效决策，而不是把责任转嫁给操作者。

第四，检查独立验证、约束规则和安全保护层。

大模型输出不能直接作为安全相关动作的唯一依据。

如果 AI 用于生产系统，应检查是否存在独立于模型的规则校验、约束检查和安全保护层。

AI 可以提出建议。 但建议必须经过既有控制条件、调度规则、运维规程、设备状态、权限策略等确定性机制校验。

这类似 Claude Code 中的 permission gate。

模型可以提出动作，但动作必须经过权限系统和工具边界。

在轨道交通场景中，需要重点检查：

• AI 输出是否经过规则引擎或安全逻辑校验？
• AI 建议是否可能绕过既有安全机制？
• AI 是否被禁止直接修改安全相关参数？
• AI 是否能够访问或影响安全完整性等级较高的功能？
• 系统是否对 AI 输出设置保守边界？
• AI 不确定、冲突或超出范围时是否进入安全状态？

从功能安全角度看，大模型不适合作为未经约束的安全功能实现。

更合理的定位，是把它放在受限边界内，作为辅助信息源或建议生成器，并由确定性安全机制进行约束。

第五，检查数据、上下文和提示注入风险。

Claude Code 论文中特别强调上下文管理。

对大模型来说，输入上下文就是判断基础。

轨道交通生产系统中的上下文可能来自运行状态、报警信息、设备日志、规章文本、历史处置记录、维护工单、人员输入等。

如果上下文错误、过期、不完整或被污染，AI 输出就可能偏离实际。

安全评估应检查：

• AI 使用的数据来源是否可信；
• 数据时效性是否满足生产场景要求；
• 运行状态、报警和设备信息是否有一致性校验；
• 上下文是否区分实时数据、历史数据和推断信息；
• 外部输入是否可能构成提示注入；
• 不同来源的指令优先级是否明确；
• 模型是否可能把普通文本误认为操作指令。

提示注入在轨道交通生产系统中尤其需要关注。

例如，维护记录、外部文档、日志文本中如果包含诱导性内容，模型可能把它当成指令执行。

安全评估不能只检查网络安全边界，还要检查“文本输入如何影响模型行为”。

第六，检查模型变更、知识更新和配置管理。

传统安全相关软件强调配置管理和变更控制。大模型系统同样需要。

一个 AI 应用可能会因为模型版本升级、提示词修改、检索库更新、工具接口变化、权限配置调整而表现不同。

如果这些变化没有纳入变更管理，系统行为就可能在不知不觉中改变。

安全评估应检查：

• 模型版本是否受控；
• 提示词和系统指令是否纳入配置管理；
• 知识库、向量库、规则库更新是否有审批和回归验证；
• 工具接口变化是否进行影响分析；
• 模型升级前后是否进行一致性测试；
• 生产系统是否禁止未经批准的在线自学习或自动更新；
• 变更后是否保留可追溯记录。

对安全相关场景来说，不能接受一个系统今天和昨天表现不同，却没有任何变更记录和验证证据。

第七，检查运行监测、日志审计和事后追溯。

大模型系统进入生产环境后，不能只在上线前评估，还要关注运行期监测。

系统至少应记录：

• 用户输入；
• 模型输出；
• 使用的上下文；
• 调用的数据和工具；
• 权限判断过程；
• 人工确认过程；
• 最终采取的动作；
• 异常、拒绝和回退情况。

这些日志不是为了“存档好看”，而是为了在出现问题时能够回答：

• AI 当时看到了什么？
• 为什么给出这个建议？
• 人是否采纳了建议？
• 系统是否进行了独立校验？
• 危险动作是否被拦截？
• 问题是模型错误、数据错误、接口错误、人员误用，还是流程缺陷？

没有这些证据，就无法进行安全闭环，也无法持续改进。

第八，检查降级、退出和应急处置策略。

AI 系统不能成为生产流程中的单点依赖。当模型服务不可用、输出异常、上下文不足、数据冲突、响应超时、权限校验失败时，系统应有明确的降级策略。

例如：

• 回退到人工流程；
• 只显示原始数据，不显示 AI 建议；
• 禁止自动触发后续动作；
• 提示用户 AI 当前不可用或不可靠；
• 保留既有规则系统作为主通道；
• 进入更保守的运行模式。

这和功能安全中的失效安全原则一致。

AI 不可用时，系统不能因此失去基本安全功能。AI 输出异常时，也不能让异常继续向下游扩散。

大模型技术进入轨道交通生产系统，安全评估的重点不是问“模型准不准”，而是问：

• AI 在系统中处于什么位置？
• 它是否影响安全相关决策？
• 它拥有哪些数据和工具权限？
• 它的错误如何传播？
• 系统如何限制错误影响？
• 人是否拥有真实控制权？
• 变更是否受控？
• 过程是否可追溯？
• 异常时是否能降级到安全状态？

从 Claude Code 看可控 AI，本质上就是一句话：

模型负责推理，工具负责行动，权限负责边界，状态负责证据，人负责最终判断。

如果这套思想进入轨道交通生产系统的安全评估中，我们就不会把大模型简单看成智能功能，而会把它看成一个需要边界、约束、验证、监测和责任划分的新型系统。

《Dive into Claude Code: The Design Space of Today’s and Future AI Agent Systems》论文链接

https://arxiv.org/abs/2604.14228

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：薄说安全 薄说安全 薄说安全《从 Claude Code 架构出发，如何理解大模型的系统安全边界》