当 AI 智能体携带自己的凭据并直接向外部服务发起请求时，它的行为与其说像员工软件，不如说像一个拿着公司信用卡且没有主管的承包商。你无法看到它触碰了什么，谁批准了访问，或者为什么一次对话的成本比另一次高出十倍。日志分散在十几个服务中，问题也随之倍增。
智能体到底调用了哪个工具？是谁授予它访问该数据库权限的？为什么周二的运行消耗了四万个 token，而周一只用了五个？我们到底花了多少钱？
如果在用户、模型和服务之间没有一个中央控制层，这些问题将无法得到解答。你需要一个统一的平面，它能对每个连接进行一次性注册，仅暴露智能体真正需要的狭窄功能集，并完整记录每一次执行。本文将通过一个高级实验，演示如何使用 deco Studio 作为该本地控制平面。你将进行设置，连接一个安全的 Model Context Protocol 服务器，仅暴露一个允许的功能，并观察当智能体试图越过其边界时会发生什么。
凭据分散带来的问题
想象一个典型的团队设置。一名开发人员使用个人密钥将智能体连接到搜索 API。另一名开发人员因为演示看起来很安全，就将同一个智能体接入了生产数据库。第三名开发人员添加了一个账单查询工具，以便智能体可以“协助处理发票”。每个连接对其他人来说都是不可见的。智能体现在可以直接访问搜索、生产数据和财务记录，但团队并没有一份关于哪些连接处于活跃状态的统一清单。
当凭据存储在智能体内部时，治理就会失效。你无法集中撤销访问权限，因为密钥位于智能体的内存或其本地环境文件中。你无法审计使用情况，因为外部服务只能看到来自匿名自动化客户端的 API 调用。成本异常会在几天后的云账单中显现，而到那时，已经没人记得是哪个提示词（prompt）触发了费用激增。
在 deco Studio 中构建你的控制平面
deco Studio 通过充当本地枢纽来解决这个问题。你在自己的机器上运行它，它就成为了配置存放的唯一场所。与其将 API 密钥和工具定义分散在各个智能体中，不如在 Studio 中进行一次性连接注册。然后，你可以精确决定每个智能体可以看到哪些功能。
可以把它想象成安装了一个交换机。所有的线路都汇集到一个房间。你选择哪些线路连接到哪些部门，并保留每一次通话的记录。
首先在本地运行 deco Studio。启动后，你就可以集中进行配置。现在，每个想要使用工具的智能体都必须向控制平面请求，而不是直接向外部服务请求。这立即创建了一个你可以进行观察、过滤和记录的集中管控点。
连接安全的 MCP 服务器
在本实验中，你将连接一个 Model Context Protocol 服务器。MCP 是允许模型与外部工具交互的开放标准，但标准并不保证安全性。这里的关键步骤是“选择性”。你不会盲目地暴露服务器提供的每个端点。你在 deco Studio 中注册服务器，然后仅向测试智能体暴露一个允许的功能。
例如，你的 MCP 服务器可能提供十个功能：文件读取、文件写入、数据库查询、网络获取等。你选择一个无害的操作，比如一个沙盒化的计算器，或者针对合成数据的只读查询，并仅暴露这一个。其他九个功能对智能体来说是不可见的。如果智能体请求这些功能，控制平面将直接拒绝。
这就是将“最小权限原则”落地为机制。智能体获得能力不是通过礼貌的指令，而是通过软件边界。
测试边界
创建一个测试智能体，并将其指向你的 deco Studio 控制平面。给它一个需要使用该唯一允许功能的任务。观察它的成功过程。Studio 内部的日志将显示模型请求、通过控制平面的工具调用路由、函数执行以及流回模型的执行结果。你可以在一个连续的追踪（trace）中阅读整个路径。
现在给智能体（agent）第二个任务，该任务需要一个你故意排除掉的函数。智能体可能会试图通过推理来绕过限制，或者可能会幻觉出该工具的存在。无论哪种情况，调用都会到达控制平面，白名单会拒绝它，执行会失败。这种失败证明了边界是软件强制执行的，而非理论上的。
先用合成任务进行测试。构建一个充满生成的用户配置文件的虚假数据库。让智能体对其进行查询。验证白名单和拒绝机制。只有在你信任该边界之后，才考虑让智能体接入生产系统。在验证围墙之前就匆忙处理真实数据，是导致秘密泄露的原因。
查看运行的全路径
deco Studio 让你能够检查执行的每一个层级。你可以看到原始的模型请求：提示词、上下文窗口、格式化内容。你可以看到模型决定进行的工具调用。你可以看到控制平面如何路由该调用、执行函数并返回有效负载（payload）。最后，你可以看到模型如何消耗该结果来形成其回答。
这种可见性回答了基本的审计问题。你知道哪个工具被触发了，因为控制平面记录了它。你知道谁授予了访问权限，因为配置记录存储在一个本地注册表中。你知道为什么运行成本很高，因为你可以计算 token 数量。
统计关键指标
对于每一次运行，请跟踪四个特定的指标。首先，输入和输出 token。这些构成了模型成本的大部分，你需要精确的计数，而不是粗略的估计。其次，将模型延迟与工具延迟分开。提示词与模型响应之间的时间，与外部服务响应工具调用所需的时间是不同的。混淆两者会导致误诊性能下降的原因。第三，根据经过验证的供应商费率计算成本。不要靠猜。检查供应商的价格表，并将其与测量的 token 进行匹配。第四，将成功的调用与被拒绝的未经授权的调用进行比较。高拒绝率意味着你的智能体正在探测边界，或者你的白名单与合法需求不匹配。
这些数字将智能体运营从黑盒订阅转变为可观测系统。你可以进行预算编制、优化和解释。
本地控制与本地执行的区别
这是一个会让即使是细心的构建者也会栽跟头的教训。在你的机器上运行 deco Studio 可以让你对配置进行本地控制，但这并不保证模型本身的本地执行。如果你配置智能体去调用外部供应商（如 OpenAI、Anthropic 或任何托管 API），你的提示词就会离开你的机器。Studio 管理着闸门，但数据仍然会跨越网络。
始终跟踪这些边界。明确流水线的哪些部分留在 localhost 上，哪些部分会传输到他人的服务器。如果你的数据很敏感，仅靠工具层的本地控制是不够的。你还需要知道模型推理发生在哪里。不要将本地仪表盘带来的舒适感与远程模型的现实混为一谈。
指令不等于授权
一个危险的捷径是试图通过提示词来保护智能体。告诉模型“永远不要调用 delete 函数”并不是一种安全控制。这只是一个建议。模型可能会误解指令、遭遇提示词越狱，或者仅仅是产生推理错误。真正的安全存在于软件边界。
在 deco Studio 内部使用白名单来精确定义哪些函数是可调用的。通过控制平面内部的服务器端检查来强制执行这些限制。智能体发现其能力的方式应该像用户发现文件权限一样：通过触碰硬性限制，而不是通过阅读友好的提示。安全属于架构，而非自然语言。
从小处着手，保持怀疑
一步一步构建你的控制平面。一个 MCP server。一个暴露的函数。一个合成任务。验证智能体在应该成功的地方成功，在必须失败的地方失败。阅读追踪记录。确认 token 计数。然后添加下一个工具。
控制不是一个可以随意拨动的开关。它是一种在信任边界之前先去证明边界的习惯。deco Studio 为你提供了练习这种习惯的本地平面。利用它将一群自主智能体转变为一个受管理的、可观测的且有边界限制的系统。
Source: Controlling AI Agents in deco Studio: Tools, Permissions, and Cost
可选的学习社区：GyaanSetu AI Telegram 频道