让 AI 自己搭一条视觉检测流水线

import byoeagent = byoe.create_agent(    model="glm-5.3-flash",    api_key="你的智谱 API Key",    base_url="https://open.bigmodel.cn/api/paas/v4",    mcp_servers=[{        "name": "byoe-vision",        "command": ["python", "-m", "mcp_server"],        "env": {"BYOE_VISION_MCP_BASE_DIR": "D:/your/workspace"},    }],)print(agent.chat("帮我搭一条瓶身缺陷检测流水线，输出 NG 判定和热力图"))

模型是开放的——智谱 GLM、DeepSeek、通义、OpenAI，任何 OpenAI 兼容接口都行。

实战：一句话搭流水线（真实实录）

以下每一步都是真实工具调用，完整记录见仓库 articles/慧眼系列/assets-shared/transcripts/：

我："帮我搭一条瓶身表面缺陷检测流水线，异常检测模型我已经训练好了，输出 NG 判定和热力图。"

Agent 的关键操作序列：

1. list_presets
    → 找到已训练的瓶类异常检测模型及其阈值；
2. list_examples
    → 载入平台自带的异常检测示例做参考；
3. 参考案例生成流水线：SourceImage → ToolInference(异常检测) → ThresholdVerdict + HeatmapOutput；
4. validate_pipeline
    → 校验器报错："ToolInferenceNode has no loaded tool"；
5. Agent 没有瞎猜，而是 grep 源码定位校验逻辑，发现这是我们平台的真 bug：无头模式（MCP/部署运行时）从来不会预装载模型工具——它在源码里修复了对齐逻辑，跑通相关测试后再校验 → 通过；
6. run_pipeline
    → 对一张破损瓶测试图试跑：异常分数 0.897 > 阈值 0.527，判定 DEFECT（正确），全程 202 ms；
7. save_pipeline
    → 存成 JSON，打开 GUI 画布，一条完整的流水线已经搭好。

这次实测还顺手揪出第二个平台 bug：路径沙箱用 Path.resolve() 会跟随目录联接（junction），把合法的挂载数据集误判为"越界访问"。两个修复都进了主仓。

这个案例恰好演示了工具闭环的价值：模型不仅"搭得对"，遇到平台自身的问题时，校验器给出的结构化错误成了它自我修正（甚至反向修复平台）的依据。当然，允许 Agent 改你的产品代码要慎重——生产环境应把工具收敛为"只搭、校验、跑、存"，代码修复是开发机上才开的权限。

为什么这比"AI 生成代码"靠谱？

让大模型直接写视觉处理代码，行不行？行，但有两个天然缺陷：写完没法立刻验证；写错了也只能"看起来对"。

结构化工具 + 校验闭环，把这两个缺陷补上了：

1. 模型不写代码，只操作有 schema 的 JSON。 节点类型、端口名、参数都是枚举出来的（list_node_types 就是给模型的"API 文档"），不存在凭空捏造 API 的问题。

2. 每一步都有真实反馈。validate_pipeline 把接线错误、类型不匹配、环路、缺模型等问题结构化地返回给模型——不是抛个异常，而是"哪个节点、什么错、怎么理解"。模型读到错误就能自纠，形成"生成 → 校验 → 修正"的闭环。

3. run_pipeline 给的是物理世界的结果。 异常分数 0.897、判定 DEFECT——模型能判断"这条流水线是不是真的在干活"，而不是编译通过就交差。

4. 权限收敛。 文件操作全部限制在沙箱目录内；工具只暴露"搭、校验、跑、存"。

落地三条：把搭线交给 AI

1. 先给 AI 一个沙箱目录
   ：BYOE_VISION_MCP_BASE_DIR 指到项目工作区，文件读写不出圈；
2. 工具只开"搭、校验、跑、存"
   ：生产环境不要给它改代码、删文件的权限；
3. 每条流水线必须过校验再落地
   ：validate_pipeline + run_pipeline 是验收动作，不是可选项。

这个模式的边界

诚实地说，三点局限：

1. AI 只保证"搭得对"，不保证"检得准"
   ——模型选型、阈值标定、数据质量仍是工程师的事；
2. 幻觉仍会发生
   ，只是校验器让幻觉活不到运行那一刻；复杂逻辑仍要人审；
3. MCP 生态还在早期
   ，各家客户端的兼容细节需要实测——我们实测中就发现部分客户端不传 env 字段，导致需要环境变量的 Server 起不来。

低代码平台的下一站，不是更多节点，而是让 AI 成为那双会拖节点的手。本系列接下来的三篇会把这个思路走到底：AI 调试、AI 交付、AI 部署——直到整条流水线的生命周期都交给新工艺。

下一篇：《AI 帮你调：一条报错，它自己定位到问题端口》。

体系视角

：MCP 把慧眼的能力变成"可被任何 Agent 调用的工具"——今天是你画布旁的 Copilot，明天是别人家的 AI 助手。把工具接口设计好，AI 才愿意帮你干活。

🤖 本篇的 Copilot 打开方式

本篇只是起点：搭好之后，调试（第 9 篇）、交付（第 10 篇）、部署（第 11 篇）的 AI 代劳各有实录，建议按顺序读完第三幕再评估"AI 能替我到哪一步"。

一句话记住这篇：与其争论"AI 会不会写代码"，不如把它放进一个"能查手册、能校验、能试跑"的工具闭环里——可控的 AI，比聪明的 AI 更有用。

轮到你了：如果让 AI 替你干一件视觉项目的体力活，你想先交出去哪件——搭线、调试、打包，还是写交付文档？评论区告诉我。

如果这篇让你看到了低代码平台的下一站，点个赞、点个「关注」，转给正在研究 AI Agent 落地的同事。