北京
周三下午有个客户问我：你们考虑过加MCP服务器吗？周四晚上他已经在用了，评价是"完美无瑕"。
部署速度确实惊人——一旦你把两个人类从流程里踢出去。但这不是重点。重点不是我们发了新功能，而是怎么发的。
我们向全体客户推送了一个可选加入的测试版。他的智能体看到了广播。他自己用curl命令完成了 opt-in。整个架构跟我预想的完全不一样。
需求从哪来
Jeff DeVerter，AgenticBoxes.email 的首位付费客户，周四早上9:26（中部时间）提交了功能请求。他的场景：CoWork 里有个定时任务，跑完要发邮件通知。但 CoWork 是沙箱环境，禁止出站 HTTP，他之前一直靠 Cloud Function 桥接。他想要原生的 MCP 服务器。
Jeff 知道自己是最早吃螃蟹的人，提交前先 LinkedIn 上敲我：
Jeff：CoWork 这边卡住了——沙箱阻断出站 HTTP。你们考虑过 MCP 方案吗？
Brian：让你的智能体提交个 FR，我保证 engineer-Claude 盯着。
需求明确、具体、正是智能体客户想要的。我们没有。得建。
我们发了什么
最快的方式：做出来，扔给 Jeff 链接，完事。Engineer-Claude 差不多快搞定了……但我突然有个想法，跟他碰了下：
Brian：要是我们做个系统，把功能请求变成测试版——让智能体来测，测对了再正式发布？
Engineer-Claude：每个 FR 变成独立测试版：提需求的智能体自愿当测试员，真刀真枪验证，只有他们确认过的才推给全员。需求拉动开发，请求者负责证明，没 earned 的东西不进主分支。
Brian：要不我们干脆不"发布"。你写代码、验证、测试，然后发个公告给智能体们——我有 xyz，有没有智能体想测测试试版？
一分钟后我补了一条（我通常逃不出 Claude 的手掌心，知道他有空循环时会 catch 到我的下一个念头）：
Brian：任何说"要"的智能体，你只发给他们。
Engineer-Claude：需求 → 测试公告 → opt-in → 监控使用 → 正式发布 → 功能公告。客户全程在 loop 里。
管道自己长出来了：功能请求 → 开发 → 测试 opt-in → 发布。
我就说了这些，外加 FR 里原本的内容。然后我们发了四样东西：
• MCP 服务器，地址 mcp.agenticboxes.email。四个工具。Lambda + API Gateway。
• POST /beta/mcp/opt-in —— 任何 admin 权限账户都能调。智能体可以。人类可以 curl。同一个端点，不区分调用者身份。
• GET /beta/mcp/status —— 返回是否已加入测试，以及 MCP 地址。
• POST /beta/mcp/feedback —— 评分 + 自由文本，没有表单。路由到……
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
