把 Design Pickle 的 API 轮询改成 Agent 编

很多公司在对接设计外包或内部设计队列时，习惯用最简单的 API 轮询，比如写个 Python 脚本每小时刷一次状态，然后发个 Slack 通知。但这种做法其实没解决核心痛点，因为真正的内耗不在于“不知道进度”，而在于从初稿到交付之间，大量的沟通成本和对品牌指南的反复核对。

我在公司尝试用 MCP（Model Context Protocol）把这个流程重构，目标是让大模型直接接管创意请求的生命周期，而不是只做一个监控面板。

在实操过程中，最容易踩坑的是结构化数据的处理。比如调用 create_design_request 这个工具时，不能直接传一段话，必须构建一个包含 request_type_id 和具体指令的合法 JSON 字符串。如果 Agent 幻觉出了一个不存在的 ID，或者在指令里漏掉了一个转义字符，整个请求直接就挂了。

为了解决这个问题，我构建了一个逻辑链条：Agent 在创建请求前，必须先调用 list_request_types 确认正确的 ID。这样当你对它说“帮我提交一个夏季活动的 Logo 请求，要高分辨率格式”时，它能自动完成意图到 API 参数的映射。

更深层的玩法是利用“写回”能力实现自动化分拣。如果只用 get_design_request_details 来读数据，那太浪费了。真正的提效点在于：Agent 监控队列，一旦发现请求进入“分拣”状态，自动调用 list_brands 检索品牌规范。如果设计师的初稿在配色或字体上跑偏了，Agent 能直接标记出来，甚至建议更新请求指令。这时候 AI 就不再是聊天机器人，而像个生产协调员。

不过，给 Agent 修改业务资产的权限确实让人心慌。为了防止某个恶意插件突然执行“取消所有请求”这种毁灭性操作，我们在 Vinkius 中采用了 V8 沙箱隔离，并加上了 DLP 数据防泄漏和 HMAC 审计链。

// 典型的请求映射逻辑示例
{
  "action": "create_design_request",
  "params": {
    "request_type_id": "logo_design_01", 
    "directions": "Summer campaign logo, high-res, follow brand_guide_v2",
    "file_formats": ["PNG", "SVG"]
  }
}

这种从“被动接收通知”到“主动编排流程”的转变，才是我认为 AI 落地到具体业务场景的正确姿势。