做 Agent 平台的人，很容易一上来就想做成”多租户、云上、带鉴权”的大系统。但很多场景其实只需要一个本地控制面：在一台机器上，把工作区、运行时、MCP 面做扎实。

我在做一个本地优先的企业 Agent 平台（agent-hub），第一版故意做得很小：Python 控制面 + 浏览器界面 + SQLite 存储 + 原生 MCP 面。这一版的目的不是”功能多”，而是把边界和连接方式先验证清楚。这篇讲两个我在意的边界：该不该上多租户，以及 MCP 工具该暴露多细。

先定边界：本地、单机、无鉴权

第一版默认只绑定 127.0.0.1，没有鉴权，也不是生产多租户服务。听起来是不是”太简陋”？其实这是故意的。

在没有明确多租户需求之前，硬上鉴权、租户隔离、云部署，会带来一堆和核心价值无关的复杂度。而一个本地控制面的核心价值是：让 Agent 能在一个真实、可运行的本地环境里组织工作区、有 MCP 可接入。先把这条链路跑通，比先做隔离重要得多。

所以我用一个显式开关来控制边界：默认拒绝远程绑定，只有显式设置 AGENT_HUB_ALLOW_REMOTE=1 才允许远程。这等于把”要不要对外开放”这个决定，从代码层面逼着你去主动表态，而不是默认就对所有人开放。

MCP 工具：太多没用，太少不够

MCP 面是给 Agent 运行时接入用的 http://127.0.0.1:8765/mcp。第一版我只放了三个工具：

  • agenthub_status —— 查整体状态；
  • workspace_list —— 列工作区；
  • workspace_create —— 创建工作区。

看着是不是”太少了”？但这是有意控制的。

工具太细，Agent 会被细节淹没：一堆零碎的工具，调用成本高、参数难对齐、Agent 容易选错。工具太少又会不够用，连基本操作都要绕。

判断粒度对不对，我有个朴素标准：这个工具是不是对应一个 Agent 能理解、能直接完成的”业务动作”。

  • “列工作区” —— 是一个完整动作，Agent 一看就懂；
  • “创建工作区” —— 是一个动作，给了明确的输入（名称等）就能做；
  • 而不应该把它拆成”获取连接”“设置名称”“触发生成”这种更底层的碎片。

换句话说，工具应该对应”意图”，而不是对应”内部函数”。内部实现怎么拆，是控制面自己的事；对外暴露的，是 Agent 能直接用的动作。

边界清晰的代价与收获

  • 代价：第一版做不了多租户、云部署、细粒度权限；要多加功能就得重新设计。
  • 收获：核心链路简单稳定，MCP 面小而清晰，Agent 不会在一堆工具里迷路；边界用显式开关控制，风险可控。

等真实的”多租户 / 远程”需求出现，再往上叠加，而不是提前为想象的需求买单。很多系统是被”万一以后用得上”拖垮的。

最后几条

  • 先验证部署形态和连接边界，再叠加编排；第一版故意小。
  • 默认只绑本地、无鉴权，用显式开关（AGENT_HUB_ALLOW_REMOTE）决定是否对外。
  • MCP 工具对应业务动作，别对应内部函数；少而清晰 > 多而杂。
  • 别急着上多租户：没有真实需求，复杂度就是纯粹的负担。
  • 数据默认本地（SQLite），可运行、可验证，比堆功能更能说明问题。

一个”边界清楚、能跑起来”的本地控制面，比一个”什么都想装、却处处没做实”的大平台有用得多。