AI代理安全始于小型软件

Matt Sephton于2026年4月发表了Fits on a Floppy，并提出一个刻意荒诞的约束：有用的软件应尽量装进1.44 MB，也就是标准3.5英寸软盘的容量。¹

真正重要的不是大小限制本身，而是它背后的姿态。Sephton主张快速下载、即时启动、低内存、低CPU、原生代码、支持旧系统，以及只把一件事做好的工具。¹显而易见的解读是：小型软件尊重用户。放到代理时代，还可以再进一步：小型软件让AI编码代理更难隐藏错误。

AI代理安全始于小型软件，因为小而可检查的系统会压缩代理可能误解、改动、授权和漏测的空间。沙箱和权限提示仍然重要。小型软件把安全边界前移到产物本身的形态之中。

摘要

编码代理发挥最好时，往往是在上下文退化之前，就能读完相关文件、运行相关检查，并解释相关代码差异。Anthropic的Claude Code指南指出，上下文会很快填满，且性能会随着上下文填充而下降；同一指南还把验证称为最有价值的实践，并将CLI工具描述为节省上下文的接口。²OpenAI的本地shell文档也提醒，运行shell命令的代理在执行前需要沙箱，或严格的允许列表和拒绝列表。³

小型软件不能取代这些控制措施。但它让这些控制更容易落地。一个小工具需要授权的命令更少，需要检查的文件更少，需要信任的依赖更少，需要运行的测试更少，也更少出现错误假设藏身的分支。古老的Unix经验并未过时：McIlroy把“只做一件事”追溯到早期的大小限制，随后解释了为什么文本流会成为对程序和人都很有用的通用接口。⁴代理系统正在重新发现同一种模式，因为代理需要可检查、可组合的界面。

核心要点

面向代理构建者： - 在添加宽泛的API或大型工具模式之前，优先选择输入明确、输出明确、产物采用普通文件的小工具。 - 把文件路径、代码差异、日志和测试都视为安全界面。代理可以检查，审查者可以检查，自动化也可以把它们设为关口。

面向软件团队： - 小型软件降低审查成本。审查者可以一次看懂一个400行工具及其测试；庞大的框架则会在本应提供证据的地方迫使人依赖信任。 - 让权限范围贴近动作本身。一个小命令可以只读运行、只写一个目录，或拒绝网络访问。通用命令通常会索要超过任务所需的权限。

面向产品负责人： - 小型软件不是怀旧。在机器能过快地产生过多代码的世界里，它是一种治理模式。 - 标准应从“代理能不能把它做出来？”转向“团队能不能验证、拥有并回滚它？”

为什么小型软件再次变得重要

软件臃肿过去常被视为用户体验问题：下载缓慢、内存沉重、启动延迟、电池耗尽，以及旧设备被抛在后面。Fits on a Floppy用一个刻意具象的标准让这种批评变得可见。1.44 MB徽章把克制变成了用户能够理解的测试。¹

AI编码代理改变了克制之所以重要的原因。机器生成文件的速度可以快过人类阅读文件的速度。当周围系统把产量当作进展时，这种速度会削弱质量。一个包含4个新依赖的2000行功能，在记录里可能显得很厉害，却可能比它增加的产品价值更大地扩张缺陷面。

小型软件给代理设下更难糊弄的目标，也给审查者提供更好的对象。提示可以要求一个可执行文件、一种数据格式、一个测试文件和一条回滚路径。结果会留下更少的自由度。模型仍然可能犯错，但错误可伪装的空间变小了。

早在编码代理进入工作流之前，Niklaus Wirth就在1995年发表了题为A Plea for Lean Software的论文。⁵这个标题今天依然有力，因为底层失败仍然存在：团队用硬件、依赖和抽象层来回避艰难的设计决策。代理降低了添加代码的成本，因此拒绝添加代码变得更有价值。

上下文是一种安全预算

代理安全常被描述为权限问题：代理能运行哪些命令、能编辑哪些文件、能看到哪些密钥、能发起哪些网络调用。这些问题当然重要。但它们没有覆盖代理工作时首先遇到的约束：上下文。

Anthropic的Claude Code最佳实践指南指出，上下文窗口包含对话、消息、已读取文件和命令输出；一次调试会话就可能消耗数万token。²该指南还警告，当上下文窗口填满时，Claude可能开始忘记早先指令，或犯更多错误。²

这个警告把大小变成了一项安全属性。小型代码库能让代理读到相关范围，而不会让会话淹没在无关文件里。小工具能让代理同时看见函数、测试、权限模型和边界情况。小改动能让审查者找到真正的变化，而不是在一堆生成出来的动作中扫描。

上下文预算有3个实际限制：

大型系统仍然可以安全。它们需要更强的分解。如果代码库无法变小，那么面向代理的界面应该变小：一个包、一个有边界的子系统、一个公共命令、一个测试目标、一个归属明确的目录。

普通文件胜过隐藏状态

McIlroy的口述历史把旧经验讲得非常实际。他把“只做一件事”描述为一种源于没有空间做更多事的原则，并说团队在原始限制消失后仍然保留了这种模式。⁴他还解释了文本流为何重要：人类可读的数据让调试不那么痛苦，而演进文本字段也比修改固定二进制布局更省事。⁴

代理需要同类界面。文件可以被列出、搜索、比较差异、按范围读取、提交、回滚、检查和审查。隐藏的IDE状态、不透明的本地数据库和宽泛的托管工具可能有用，但它们会迫使代理和审查者信任一个难以检查的界面。

一篇2026年1月的arXiv论文把Unix的文件抽象与代理式AI系统联系起来。论文认为，类文件抽象和基于代码的规范能把多样资源压缩成一致、可组合的接口，并可能帮助代理系统变得更可维护、可审计、运行上更可靠。⁶Oracle关于代理记忆的分析提出了相近区分：文件系统接口之所以有效，是因为模型已经理解repo、文件夹、Markdown、日志和CLI交互这类开发者原生界面；而持久存储仍可能属于数据库。⁷

这个区分很重要。“使用文件”并不意味着“永远把一切都松散地存在文本里”。更安全的模式，是把代理接口和存储底座分开：

代理应该看到最小的有用接口。产品可以在底层保留更强的存储层。

工具越少，权限越少

MCP授权文章把授权教训讲得很明确：验证Bearer token并不能证明用户可以调用服务器背后的每一个工具。⁸小型软件把同一思想提前到了设计阶段。更小的工具会请求更窄的权限。

OpenAI的本地shell文档直截了当地说明了风险：运行任意shell命令可能很危险，构建者在把命令发送给系统shell之前，应使用沙箱，或添加严格的允许列表和拒绝列表。³Anthropic的Claude Code指南给出了规模化场景中的实践示例：跨文件展开任务时，使用允许工具限制，确保无人值守运行不能做超出任务所需的事。²

小命令更容易限制：

宽泛工具往往会积累宽泛权限。一个通用的“发布”命令可能触及内容、翻译、数据库行、缓存清除、部署日志和分析。有时确实需要发布命令。更安全的模式是用更小的命令构成发布流程，并在步骤之间放置明确关口；只有在每一步都有证据之后，才自动化整个序列。

目标不是让工作变慢。目标是让权限可见。

测试应适配工具

Anthropic第一条最佳实践要求用户为Claude提供验证工作的方法：测试、截图、预期输出和命令检查。²小型软件让这条建议具体可行。小工具可以携带一份小型验证契约。

对代理构建的软件来说，这份契约应能放进一屏：

Inputs:
- one source path
- one output path
- one optional flag

Allowed effects:
- read source path
- write output path
- no network unless --verify-sources is present

Evidence:
- unit tests for parsing
- fixture test for output
- dry-run output for the exact file
- git diff limited to owned paths

契约很重要，因为代理太容易满足模糊请求。“改进流水线”会招来架构层面的扰动。“给这个命令添加一个dry-run标志，并证明输出不会写文件”则会形成证据路径。

工具保持小，测试也会更快。快速测试会改变代理行为。代理会更频繁地运行它们，在相关代码仍在上下文中时看到失败，并在记录漂移之前修复根因。慢测试会把模型推向猜测，或只是叙述本来会运行什么。

小不等于不足

小型软件也可能以可预见的方式失败：

软盘徽章衡量的是大小。代理安全需要另一种衡量：审查者能否在批准改动之前理解行为、权限范围和证据路径？

这个问题允许工具超过1.44 MB。它拒绝的是关键部分：意外扩大范围。一个安全、朴素的20 MB原生应用，可能胜过一个会调用未经审查安装器的200 KB脚本。只有当克制触达真实执行路径时，小型软件才服务于安全。

面向代理工作的“小型化”评分卡

在代理构建或修改工具之前，从5个维度为这项工作打分。重点不是惩罚大型系统，而是找出代理开始写代码前需要先分解的界面。

任何红色单元格都不意味着工作应该停止。它意味着代理需要一个更小的工作单元。当任务形态让正确行为更容易证明时，安全性就会提高。

实用模式

我信任的、由代理构建的最安全系统，通常共享同一种形态：

1. 一个狭窄命令只做一件事。
2. 普通文件承载输入、输出、日志、计划和审查包。
3. 权限映射到命令的真实效果。
4. 测试足够快，代理能在会话中使用它们。
5. 代码差异足够小，人类可以审查。
6. 发布路径组合小命令，而不是把宽泛权限藏进一个按钮里。

无构建宣言：不使用Bundler也能发布从Web技术栈侧描述了同一种偏好：更少的构建层、更少的生成产物，以及源代码和执行环境之间更短的距离。⁹代理安全版本只是面向另一类读者讲同一件事。每多一层，机器就多一个生成貌似合理作品的位置，而人类却无法快速验证。

小型软件把克制变成基础设施。更窄的模块改善上下文适配。更普通的文件提升可审计性。更快的测试改善反馈。更小的权限集改善爆炸半径控制。更小的代码差异改善人类判断。

FAQ：小型软件与代理安全

小型软件能让AI编码代理安全吗？

不能。小型软件会缩小代理可能误解或破坏的范围。团队仍然需要沙箱、允许列表和拒绝列表、测试、代码审查、凭据边界和发布关口。小型软件让这些控制更容易应用，也更难被意外绕过。

面向代理的工具应该多小？

有用的限制不是字节数，而是可审查性。好的面向代理工具只有一个职责，输入输出契约很小，权限画像清晰，测试快速，并且代码差异能让审查者一次看懂。

代理记忆应该使用文件还是数据库？

当代理需要检查、搜索、比较差异和写入产物时，用文件作为接口。当产品需要并发、索引、访问控制、持久性或跨用户状态时，用数据库。更安全的架构会把面向代理的接口和存储底座分开。⁷

MCP适合放在哪里？

当代理需要通往外部工具或数据的类型化桥接时，MCP就有用。MCP不会消除对小命令、范围化权限和动作级授权的需要。服务器仍然必须判断特定主体是否可以执行特定动作。⁸

结语

AI让代码变得廉价。廉价代码抬高了拒绝的价值。

小型软件给拒绝一种机器可以遵循的形态：一个命令、一个输出、一个权限边界、一条测试路径、一个代码差异。这种形态不能保证质量。但它会让薄弱工作更容易显形。

软盘不再是约束。可检查性才是。

参考资料