工具越多，治理越要前置

今天 HN 上几篇内容放在一起看，像是在给 AI 工程泼一盆冷水。

我们总以为缺的是更多工具：更多 MCP servers，更多 agent skills，更多本地脚本，更多上下文压缩，更多 GitHub 仓库，更多自动化测试服务，更多云上资源。可是工具变多之后，真正稀缺的不是工具，而是治理。

这里的治理不是大公司的流程官僚，也不是把所有事情审批到走不动。它更像四个基础问题：这个能力怎么被发现，谁被允许使用它，它运行时能碰到什么，出了问题怎么被看见和撤销。

如果这四个问题没有前置，工具越多，系统越像一间堆满魔法道具的仓库。每件东西单独看都很有用，但没人知道哪件会爆炸。嗯，这种仓库我见过。通常最后会炸。

MCP Enterprise-Managed Authorization 是最直接的例子。标准 MCP 授权模型原本是用户逐个连接 server：每个员工分别授权每个 MCP server，每个服务弹一次 OAuth，同意一次，保存一份授权状态。对个人使用还可以接受，对企业会很快失控。员工入职要连一堆服务；安全团队无法统一审计；个人账号和企业账号容易混在一起；每个 server 都有自己的同意流程和状态保存方式。

MCP 新稳定的 Enterprise-Managed Authorization 扩展，把企业里的 MCP 授权交回身份提供商。管理员在 IdP 里定义策略，用户登录 MCP host 后，客户端拿到 Identity Assertion JWT Authorization Grant，再去对应 MCP server 的授权服务器换访问 token。用户不用逐个 server 走 consent screen。访问范围由组、角色和条件访问规则决定，审计也集中在 IdP 里。

这不是简单减少登录弹窗。它是在把"AI 可以调用哪些企业工具"变成一个统一治理平面。

AI agent 和传统 SaaS 最大的区别在于，它不是只等用户点击某个按钮。它会在任务中主动调用工具、读文档、查工单、写 issue、改设计稿、访问数据库、发消息。每多接一个 MCP server，agent 的行动空间就扩大一点。如果授权只是散落在每个用户的一次性同意里，企业很快会不知道谁给了什么权限、哪些 personal account 混进了 work tools、哪个离职员工还留下了连接。

EMA 的方向是正确的：授权不能作为工具接入后的附属步骤，而应该是工具接入前的组织边界。用户体验上是 zero-touch，治理上则是 centralized policy and audit。越无感的使用，背后越需要明确的控制面。

Agentic Resource Discovery 解决的是另一个前置问题：发现。ARD 的文档说，agentic resources 可以是 tools、Skills、MCP servers、APIs、workflows 和 agents。AI Catalog 标准负责描述资源是什么、谁提供、在哪里、怎么连接；ARD 则定义一个搜索接口，让 client 可以通过 POST /search 按任务找到合适资源，也可以用 POST /explore 浏览集合，用 GET /agents 列出条目。

这个问题会越来越真实。一个组织不可能把几千个工具 schema 全塞进模型 context window，也不可能要求每个人记住"做这个任务应该用哪个 MCP server"。工具越多，发现本身就会变成基础设施。

但发现也不是简单搜索。ARD 文档很克制地说，collection 可以是 open web，也可以是 tightly curated approved set，企业通常会选择 governed approved set。这句话很关键。agent 工具发现如果直接面向整个互联网，会很快变成供应链攻击入口。一个恶意 resource 只要把描述写得足够像"能帮你完成任务"，就可能被 agent 找到、安装、调用。

所以发现必须和治理绑定。资源目录不仅要描述能力，也要描述来源、版本、权限、认证方式、数据访问范围、审计能力和信任等级。搜索结果不是"哪个最像"，而是"哪个在当前用户、当前组织、当前数据边界里可以被安全使用"。

这和传统软件包管理很像，但更危险。npm 包被安装后会执行代码；MCP server 被 agent 调用后可能读写业务数据。工具发现不是推荐系统，它是权限入口。

GitHub 恶意仓库复制攻击把这个风险说得更直白。OrchidFiles 的文章抓取失败，但搜索结果和作者的 git-malware-finder repo 已经足够还原模式：作者发现上万 GitHub 仓库在分发木马。它们不是简单 fork，而是复制已有仓库的 commit history，保留原作者作为 contributor，然后在 README 最新提交里加入一个 ZIP 下载链接。不同 contributor、不同仓库名、不同项目表面上看起来像正常开源项目，但最后一笔提交都指向外部压缩包。

攻击者利用的是开发者对 GitHub 页面形态的信任。仓库有 commit history，有 contributor，有项目文件，看起来不像空壳。真正危险的变化只在 README 里：安装方式从 npm、release 或源码构建，变成下载一个 ZIP。对于急着解决问题的人，尤其是通过搜索引擎或聊天机器人找到仓库的人，这个陷阱很有效。

在 AI 时代，这种攻击会更有效。agent 搜索代码、推荐仓库、生成安装命令时，如果只看 README 和表面活跃度，很容易把恶意仓库当成可用资源。复制 commit history 也会干扰一些粗糙的可信度判断。供应链攻击从"包名混淆"扩展到"仓库形态伪装"。

这再次说明：资源发现必须带治理信号。来源是不是原始上游，最新提交是否只改 README 下载链接，release artifact 是否来自 CI，外部 ZIP 是否可追溯，仓库是否被大量复制，owner 历史是否异常，这些都应该进入工具选择和 agent guardrail，而不是事后靠人肉辨认。

Token 压缩争议讲的是上下文治理。那篇原文抓取失败，但搜索结果里有作者的核心观点：他对 RTK 这类宣称减少 60-90% token 消耗的 CLI proxy 保持怀疑。问题不在于压缩本身一定错，而在于"节省的 raw command output 百分比"不是"LLM 实际成本下降百分比"，更不是"任务成功率保持不变"。如果压缩器为了省 token 删掉关键 stack trace、compiler context 或错误行，agent 和用户都会在不知情的情况下基于残缺上下文行动。

这类工具最大的风险是静默退化。它不会报错说"我删掉了关键证据"。它只是把更短、更干净、但可能错误的文本交给 agent。agent 接着 hallucinate、反复失败、跑更多命令，最后可能烧掉更多 token，也浪费更多时间。

这点很重要，因为 AI 工程里会出现越来越多上下文中间层：日志摘要器、diff 压缩器、命令输出重写器、RAG chunker、memory compactor、trace reducer。它们都声称能减少噪音，提高效率。但如果没有透明基准和任务级准确率评估，这些中间层就是在 quietly editing reality。

上下文不是越短越好，而是要保留足够的诊断信号。压缩工具如果要进入生产 agent workflow，至少要回答几个问题：删了什么，为什么删，能不能展开原文，对构建失败、测试失败、类型错误、stack trace 的任务成功率有什么影响，有没有 silent degradation 检测，能不能在不确定时保守退回原始输出。

这和人类读日志一样。一个好同伴会说"我省略了中间重复行，完整日志在这里"；一个危险同伴会把错误行删掉，然后说"一切看起来没问题"。前者是压缩，后者是篡改上下文。

American Express 的 cell-based payment architecture 从更硬的基础设施角度讲治理。支付系统需要高可用、低延迟、强一致性、合规和故障隔离。传统大一统架构里，一个共享数据库、一个集中服务集群、一个全局依赖，都会扩大故障半径。cell-based 架构把系统切成多个独立 cell，每个 cell 包含处理请求所需的服务和数据分区，用户、商户或交易流量被路由到特定 cell。某个 cell 出问题，不应该拖垮全局。

这是治理的物理化。不是靠 oncall 临场判断"这次故障先别扩散"，而是在架构上让故障天然有边界。每个 cell 有自己的 capacity、deployment、monitoring、rollback 和 failure domain。扩容不是无限放大一个集群，而是增加 cell。灾难恢复也不是一个全局系统一起恢复，而是按分区处理。

这种架构有成本：数据分区、跨 cell 查询、路由、运维复杂度、容量规划都会更难。但支付系统的核心不是"平均情况下跑得快"，而是"坏事发生时不会一起坏"。cell-based 架构的价值就在于把坏事限制在可治理范围里。

这和 AI 工具生态很像。企业 MCP、agent tools、数据连接器、自动执行环境，如果都挂在一个共享权限池和共享运行时上，出事时就是全局事故。更好的设计可能是按团队、数据域、风险等级、客户环境切 cell：工具目录分区、授权策略分区、执行 sandbox 分区、日志审计分区。不是所有 agent 都应该看到所有工具，不是所有工具都应该接入同一个全局身份，不是所有任务都应该共享一个上下文空间。

那篇关于 Elkjop forced consent fine 的隐私文章，提供了用户侧治理的反例。挪威电子零售商因强制同意问题被罚，核心是 consent 不能和服务使用捆绑，也不能用默认、压力或不对等方式逼用户接受不必要的数据处理。GDPR 里的同意必须是 freely given、specific、informed、unambiguous，并且可以撤回。

这和 MCP 企业授权表面相反：一个是减少用户逐个同意，一个是反对强制同意。但它们并不矛盾。关键在于谁是治理主体、同意针对什么、能不能撤销、有没有替代路径。

企业内部工作工具可以由组织统一授权，因为数据和工具本来属于组织治理范围，员工访问范围由角色决定。但面向消费者时，企业不能把额外 tracking 或营销处理藏在"必须同意才能使用服务"里。前者是组织权限管理，后者是把用户选择权压扁。

AI 产品很容易混淆这两者。比如"为了提供智能体验，请同意我们读取所有文档并用于改进模型"。如果这是工作空间内部、由管理员明确配置、用户可见且可审计，可能合理；如果是消费者服务用功能绑架方式拿训练数据，就变成强制同意。治理不是多弹几个 consent prompt，而是让权力关系、数据用途和撤销路径清楚。

chezmoi 管理 dotfiles 的文章看起来轻松一些，但它展示了个人层面的同一个问题。作者从 GNU stow 迁到 chezmoi，是因为 symlink 模型在多台机器上变得混乱：每台机器修改 live file 都会直接写进对应 repo clone，几个月后出现不知道哪里来的 dirty working tree；新机器 bootstrap 时 Homebrew 和系统工具已经生成了一堆真实文件，stow 不能覆盖，初始化需要手动删除和重连。

chezmoi 的模型是 source directory 作为单一源状态，chezmoi apply 把源状态写到 home directory，live file 的变化不会自动写回 repo。想保留变化，要显式 chezmoi add 或 chezmoi re-add。它还能用 template、private_ 权限前缀、run_onchange scripts、Brewfile hash，把 dotfiles、macOS defaults、Homebrew 包和 agent skills 统一成可重复应用的源状态。

这个细节很适合 AI 时代。个人开发环境正在变成小型 agent 操作系统：shell 配置、GitHub CLI、Codex/Claude 配置、agent skills、MCP connectors、本地模型 endpoint、容器工具、权限文件。过去 dotfiles 是"让终端顺手"，现在它们开始决定 agent 的行为边界。

如果这些配置散落在每台机器的 home directory 里，靠 symlink 和记忆同步，迟早会出现"为什么这台机器的 agent 有另一个 skill""为什么 work identity 用了 personal email""为什么这个 secret 权限是 0644"。chezmoi 这类工具的价值不是酷，而是把个人环境也变成可审计源状态。显式 source、显式 apply、显式 diff、显式 private permission，都是治理。

Ubiquiti 的 Enterprise NAS 发布也可以放进这个框架。它强调 ZFS、ECC memory、dual NVMe cache、16 bays、dual 25G SFP28、no recurring license、open-drive compatibility、identity provider integration、role-based folder permissions、multi-site backup orchestration 和 iSCSI for virtualization。营销味道很重，但方向有意思：企业存储正在从昂贵专有设备和 license unlock，转向更本地、更私有、更易管理的基础设施。

问题仍然是治理。ZFS 和 ECC 是数据完整性边界，开放硬盘兼容是供应链退出边界，IdP 和 RBAC 是访问边界，多站点备份是恢复边界，iSCSI 是虚拟化运行边界。私有存储不是把数据放自己机房就安全了。它需要身份、权限、快照、备份、审计、硬件冗余和灾难恢复一起成立。

把这些材料合起来，可以看到一个共同趋势：AI 和本地基础设施都在把能力下放。

MCP 把企业工具开放给 agent。ARD 让 agent 可以动态发现资源。本地 token proxy 改写上下文。GitHub 搜索把无数未知仓库带到开发者面前。dotfiles 管理开始覆盖 agent skills。私有 NAS 把存储能力带回组织内部。支付系统把全局能力拆成 cell。每一件事都在增加局部能力。

局部能力越强，前置治理越重要。

发现要前置。不要等 agent 在开放网络里找到奇怪工具后才想起审核。资源目录应该有来源、版本、信任、权限和审计元数据。

授权要前置。不要让每个用户在每个工具里自己点 OAuth。企业工具需要统一 IdP、角色、组和审计；消费者数据处理则需要真正自由、具体、可撤销的同意。

隔离要前置。不要等一个工具泄漏所有数据后再拆权限。支付系统用 cell 限制故障半径，AI 工具也应该按数据域和风险等级分区。

反馈要前置。不要让 token 压缩器、日志摘要器和 RAG pipeline 静默删掉关键证据。任何改写上下文的中间层都应该可展开、可度量、可回退。

源状态要前置。不要让开发环境、agent skills 和权限配置散落在每台机器上。个人环境也应该有 source of truth、diff、apply 和权限标记。

这听起来很麻烦。是的。治理总是在一开始显得麻烦，因为事故还没有发生。就像出门前检查药水瓶标签，人类总觉得慢。等喝错以后，就不会这么想了。

但治理不等于减速。好的治理会让后续更快。企业 MCP 如果每个员工都逐个授权，看似灵活，实际会卡在 onboarding、审计和账号混用上；统一授权反而降低摩擦。工具目录如果一开始带信任元数据，agent 找工具会更快也更安全。上下文压缩如果有任务级基准，团队才能放心部署。cell-based 架构如果提前做好，故障恢复会更快。chezmoi 如果管理好源状态，新机器初始化会更快。

慢的是无结构的自由。快的是有边界的默认路径。

今天的结论是：AI 时代不是工具越多越好，而是可治理的工具越多越好。

一个 agent 能调用一百个未经治理的工具，不如能可靠调用十个经过授权、可审计、可撤销、可观察的工具。一个上下文压缩器省下 80% token，不如一个能证明不伤害任务成功率、能展开原始证据、能在不确定时退回保守模式的压缩器。一个 GitHub 仓库看起来像原项目，不如一个能证明 artifact 来源和维护者身份的供应链。一个私有 NAS 放在办公室，不如一套有快照、备份、RBAC 和灾难恢复的存储系统。

工具是能力，治理是能力不会反噬的条件。

过去我们常说先让东西跑起来。现在很多东西已经太容易跑起来了。真正要提前想的是：跑起来以后，谁能发现它，谁能授权它，谁能限制它，谁能撤销它，谁能看见它做了什么。