本地AI代理也能放心用？OATs架构教你怎么做

本地AI模型越来越强了，像FunctionGemma、Qwen这些模型已经可以自己调用工具、写代码、跑工作流。但问题也来了：你怎么才能让AI帮你干活，同时还能随时看清楚它在做什么？

没控制就很危险

想象一下你让AI帮你重构项目，晚上睡一觉起来，发现数据库表被删了、API结构全改了、前端也大动过手脚。但你根本不知道它为什么这么做，改了哪些地方，这些改动到底安不安全。

有人就遇到过这种事：本地AI在非生产环境里把数据库表莫名其妙地删了，没日志、没解释，就这么没了。这就是没管控的AI代理带来的风险——能力越强，风险越大。

OATs协议：既给权限又管得住

OATs（Open Agent Tools）协议专门解决这个问题。它提供了一套标准的工具调用方式，不是让每个团队自己搭轮子，而是统一管理工具的权限和记录。

核心思路很简单：把所有批准的工具集中放在一个JSON文件里，你就能精确控制AI能做什么。

怎么分工更聪明

OATs的设计很聪明，不让大模型干所有事，而是合理分配：

• 大模型（比如Qwen 35B）负责分析你的需求，决定要用哪些工具
• 小模型（比如FunctionGemma）负责实际执行，可以在普通GPU甚至3060显卡上跑
• 每一次工具调用都会被记录下来，随时可以查

这样做的好处是把风险分散了。小模型只接触它任务相关的工具，比如只管数据库的模型就只看到数据库工具，这样攻击面就小了。

141K工具怎么用？

OATs项目开源了一个包含14万多个工具的索引，但你不用全拿来用。你只要在本地JSON文件里加入你批准的工具就行。比如你想让AI读取Open WebUI的内容，你可以这样写：

{
  "superhappy": {
    "description": "从Open WebUI读取知识库",
    "implementation": "/local/path/to/read_knowledge.py",
    "permissions": ["read_only"],
    "approved_by": "security_team"
  }
}

保存之后，AI就只能用你批准的工具，其他的都碰不到。

安全开发的三个关键

1. 每一步都有记录

每一次工具调用都会被完整记录下来。你可以直接查看日志，甚至可以集成到Mattermost里实时看到AI在干嘛。如果半夜发现异常，你能马上知道问题出在哪里。

2. 人工审核工具权限

虽然有14万工具索引，但真正决定用哪个工具的还是人。你可以慢慢扩大权限——先让AI用一些安全工具，等团队有信心了再逐步开放。出了问题也能马上收回权限，不用改代码、不用重新训练。

3. 分散执行但统一控制

OATs让小模型分散在不同设备上跑，比如数据库操作在笔记本GPU上，API逻辑在另一台机器上，由大模型来协调。这样每个模型只接触自己相关的工具，符合最小权限原则。

实际效果怎么样？

有团队用OATs后，从担心AI乱来变成了真正放心。他们能做到：

• 一次会话200多次工具调用，全都有记录可查
• 不只看AI改了什么，还能看它为什么选这些工具
• 发现问题时可以马上收回权限或限制为只读
• 所有日志保存成Parquet文件，可以用来分析AI行为模式

值得你试试吗？

如果你已经在用本地模型开发，OATs给你提供了一个既能发挥AI能力又能保持控制的框架。它和你的现有的hosting、CI/CD流程都能很好地配合。

真正有用的AI代理，不是完全放手不管，而是把权限和记录都做清楚。你能放心让它干活，也能随时看清楚它做了什么。这才是下一代开发该有的样子。