用OpenCode与博途MCP服务器分析TIA Portal AF框架案例

这次我们来看一个很具体的玩法：用 AI 编程助手 OpenCode，配合一个博途 MCP 服务器，把西门子 TIA Portal 项目里的 AF 框架官方案例程序直接交给 AI 去分析。连接好之后，你只需要在终端里问一句“这个案例的主程序是怎么调度的”，AI 会自动去读取项目里的程序块、变量和调用关系，然后给出中文导读。整个过程不需要手动复制粘贴源码，也不需要在博途界面里翻来翻去找 FB 和 FC。

这套方案比较适合三类人：刚开始学 AF 框架的自动化工程师；需要快速阅读大量官方示例程序的开发人员；以及要给团队做内部培训、想整理程序讲解材料的人。它的核心价值不是“AI 生成的代码百分之百准确”，而是把找程序、导源码、理解调用关系这些机械工作压缩到几分钟。配置好以后，真正分析一个案例确实可以在 5 分钟级别完成，前提是 MCP 服务器和项目路径已经就绪。

下面直接从部署开始，完整过一遍如何让 OpenCode 通过博途 MCP 服务器读取 AF 框架案例程序，以及验证、批量分析、排错和合规边界。

1. 核心能力速览

先给一张总表，快速判断这个组合适不适合你：

这套链路里，OpenCode 负责跟大模型对话，博途 MCP 服务器负责把博途项目暴露成可查询的工具接口。两者通过 MCP 协议连接，大模型不需要理解.ap文件内部格式，只需要调用 MCP 工具，就能拿到程序块源码和结构信息。

2. 适用场景与使用边界

2.1 适合谁

• PLC 开发工程师：接手陌生项目时，让 AI 先做一个整体结构梳理，节省人工翻代码的时间。
• 自动化学习者：想学西门子 AF 框架但不知道从哪里入手，可以让 AI 逐模块解释官方案例。
• 技术培训讲师：需要把官方案例整理成培训文档，用 AI 批量生成初稿，再人工校对。
• 项目维护人员：程序不是自己写的，维护时需要快速了解 OB、FB、FC 之间的关系。

2.2 能解决什么问题

博途项目不是纯文本文件，直接打开 IDE 逐个找块很耗时。通过 MCP 服务器，AI 可以按需读取项目里的 SCL 源码、变量表和块列表，回答类似这些问题：

• 这个案例程序实现的是什么控制逻辑？
• OB1 调用了哪些 FB/FC？
• AF 框架里的某个类实例是怎么创建的？
• 这个 FB 的输入输出参数分别是什么含义？

2.3 不适合什么

• 不适合直接把 AI 分析结果当最终结论，尤其是涉及设备安全运行的逻辑。
• 不适合让 AI 直接修改博途项目文件然后写回，容易破坏工程结构。
• 不适合把公司大型商业项目整体交给不受信任的第三方云端 API。

2.4 合规提醒

使用这套工具时要注意几个边界：

• 确认 AF 框架案例程序的来源合法，优先使用西门子官方示例或公司授权项目。
• 如果项目包含工艺参数、工序数据、客户信息，不要外发到第三方云端 API。建议使用本地模型，或先做一个脱敏裁剪版案例。
• AI 生成的分析文档只用于学习和内部参考，二次分发时注意版权。
• 关键控制逻辑要由有经验的工程师复核，不能只看 AI 的结论。

3. 环境准备与前置条件

3.1 操作系统与基础软件

如果你只想验证“AI 读取源码”这一条链路，暂时不装 TIA Portal 也可以先把 MCP 服务器跑通，但完整读取.ap项目通常还是需要博途环境。

3.2 硬件门槛

• 纯 API 方案：CPU 4 核以上，内存 8G 以上足够。OpenCode 本身是轻量级 CLI，MCP 服务器解析项目时会占用一定 CPU。
• 本地大模型方案：显存占用完全取决于模型参数。如果跑 7B 到 14B 的量化模型，建议准备 8G 以上显存；如果模型更大，需要按你的推理框架实际测试。

3.3 博途项目准备

• 获取 AF 框架官方案例程序的.ap或.ap18文件。
• 用博途打开一次项目，确认项目版本和结构完整。
• 如果项目很大，建议在 MCP 服务器里配置只读模式，或者先用博途把关键程序块导出成 SCL 文件作为备选输入。

3.4 网络与密钥

• 如果使用云端大模型，准备好 API Key，把它配置到环境变量中。
• 如果使用本地 Ollama 这类推理服务，确认服务已启动，端口可以被访问。

4. 安装部署与启动方式

4.1 安装 OpenCode

先确认 Node.js 环境：

node -v npm -v

如果两个命令都能正常输出版本号，说明 Node.js 环境可用。然后用 npm 全局安装 OpenCode：

# 具体包名以 OpenCode 项目 README 为准，这里给出 npm 通用写法 npm install -g opencode

如果你用的是不同的包名，把opencode替换成实际名称即可。安装完成后执行：

opencode --version

如果提示“无法将‘opencode’项识别为 cmdlet、函数、脚本文件或可运行程序”，说明 npm 全局目录没有加入 PATH。排查方法在第八章会讲。

4.2 获取博途 MCP 服务器

博途 MCP 服务器目前没有统一标准实现，常见方式是使用社区开源项目或团队内部自建。它的核心职责是：输入博途项目路径，输出程序块列表、SCL 源码和变量表。

获取方式通常是克隆仓库后安装依赖：

# 示例：克隆到本地目录，地址需要替换成实际仓库 git clone https://github.com/your-fork/tia-mcp-server.git cd tia-mcp-server # 如果项目是 Node.js 实现 npm install # 如果项目是 Python 实现 pip install -r requirements.txt

这里只是一个通用流程，仓库地址、依赖安装命令都要以你实际拿到的项目为准。

4.3 配置 OpenCode 的 MCP 服务器

OpenCode 通过配置文件加载 MCP 服务器。在项目目录或用户配置目录下创建opencode.json或opencode.jsonc，具体文件名以 OpenCode 文档为准。参考配置如下：

{ "model": "gpt-4o", "mcpServers": { "tia-mcp": { "command": "node", "args": [ "D:/tools/tia-mcp-server/index.js", "--project", "D:/Projects/AF_Pump_Example.ap18" ], "env": { "TIA_OPENNESS_PATH": "C:/Program Files/Siemens/Automation/Portal V18" } } } }

说明：

• model字段按你实际使用的模型名称填写。
• command和args是 MCP 服务器的启动命令和参数，必须替换成真实路径。
• TIA_OPENNESS_PATH指向本机博途安装目录，用于 MCP 服务器调用 Openness 接口导出源码。
• 不同版本的博途路径可能不同，V16、V18、V21 的安装目录结构会有差异。

如果 MCP 服务器是 HTTP 方式运行，配置会变成 URL 形式：

{ "mcpServers": { "tia-mcp": { "url": "http://127.0.0.1:8931/mcp" } } }

端口以你启动 MCP 服务时实际输出的端口为准，不要照抄。

4.4 启动 OpenCode 并验证连接

配置完成后，在终端启动 OpenCode：

opencode

进入交互界面后，先查看 MCP 工具是否加载成功：

/mcp

如果看到类似tia-mcp的工具列表，说明 MCP 服务器连接成功。如果列表为空，说明配置有问题，需要继续排查。

5. 功能测试与效果验证

5.1 验证 MCP 工具列表

测试目的：确认 OpenCode 能正常调用博途 MCP 服务器。

操作步骤：

1. 启动 OpenCode。
2. 输入/mcp。
3. 观察工具列表。

预期结果：能看到tia-mcp下的工具，例如list_blocks、get_block_code、list_tags等。

判断标准：工具名能显示出来，并且调用时不报错。

常见失败原因：

• opencode.json中的路径写错。
• Node.js 版本过低。
• MCP 服务器依赖未安装完整。
• TIA Openness 没有安装或版本不匹配。

5.2 基础提问测试

测试目的：验证 AI 能否通过 MCP 读取项目并给出可理解的回答。

输入示例：

请分析这个 AF 框架案例程序，说明它的功能、主要模块和程序执行流程。

操作步骤：在 OpenCode 中直接输入这个问题。

预期结果：AI 返回一段中文说明，里面包含项目中的具体块名和变量名，而不是泛泛而谈。

判断标准：回答中出现了实际程序块名称，例如OB1、FB_ValveControl、DB_Device等，说明 AI 确实拿到了项目内容。

失败排查：

• 如果回答全是通用话术，说明 MCP 工具没有被调用，需要检查工具列表。
• 如果回答超时，说明项目解析太慢，可以缩小分析范围。

5.3 调用关系分析

输入示例：

请找出这个案例里 OB1 调用了哪些 FB/FC，列出调用层级。

预期结果：AI 返回一个调用层级列表，例如：

• OB1
  • FB_ValveControl
    • FC_Compute
  • FB_MotorControl

判断标准：层级关系是否清晰，是否包含具体块名。

常见问题：如果 MCP 服务器只提供源码读取，不提供专门的调用关系检索，AI 需要从源码中推断。遇到这种情况，可以要求它“先读取 OB1 的源码，再根据调用语句整理层级”。

5.4 变量与数据结构分析

输入示例：

解释这个案例中 PLC 变量的用途，重点看 AF 框架的数据结构。

预期结果：AI 返回变量表的结构说明，识别出 AF 框架中的类实例、结构体、UDT 等。

判断标准：回答中是否明确指出了几个关键数据块或结构体及其用途。

技巧：如果变量表太大，可以让 AI 先只看全局变量，再看某个背景数据块，避免一次请求塞入过多内容。

5.5 生成程序导读文档

输入示例：

基于以上分析，为这个案例生成一份 Markdown 导读文档，包含功能概述、硬件 IO 列表、程序块说明和启动步骤。

这个测试最贴近真实使用场景。AI 会先通过 MCP 读取项目信息，然后整理成结构化文档。

操作建议：不要一次让 AI 完成所有事情。先问整体结构，再逐个模块追问，等每部分回答都准确之后，再让它汇总成文档。

6. 接口 API 与批量任务

6.1 OpenCode 非交互模式

OpenCode 支持交互式对话，也支持非交互式运行。如果版本支持，可以用类似这样的命令直接提问：

opencode run "分析 AF 案例程序，输出主程序流程" --model gpt-4o

实际参数名可能不同，需要以安装版本为准。这种模式的好处是可以被脚本调用，适合批量任务。

6.2 批量分析多个案例

下面给一个 Python 脚本模板。它遍历多个博途项目路径，对每个项目提出相同的问题，并把输出保存成 Markdown 文件：

import subprocess import pathlib projects = [ "D:/Projects/AF_Pump_Example.ap18", "D:/Projects/AF_Conveyor_Example.ap18", ] questions = [ "请总结这个案例的功能和整体结构，不超过 300 字。", "请列出主要的 FB/FC 和调用关系。", ] output_dir = pathlib.Path("D:/analysis_output") output_dir.mkdir(exist_ok=True) for proj in projects: project_name = pathlib.Path(proj).stem for idx, question in enumerate(questions, 1): cmd = [ "opencode", "run", "--model", "gpt-4o", question ] result = subprocess.run( cmd, capture_output=True, text=True, encoding="utf-8" ) out_file = output_dir / f"{project_name}_q{idx}.md" out_file.write_text(result.stdout, encoding="utf-8") print(f"written: {out_file}")

注意：如果 MCP 服务器在启动时固定绑定一个项目路径，那么批量分析多个项目时，需要修改 MCP 启动参数或为每个项目启动不同的 MCP 实例。更简单的做法是提前把每个项目的 SCL 源码导出到独立目录，让 AI 按目录读取。

6.3 MCP 服务接口的一般调用方式

如果博途 MCP 服务器以 HTTP 方式运行，可以直接用 curl 查看它暴露的工具列表：

curl -X POST http://127.0.0.1:8931/mcp \ -H "Content-Type: application/json" \ -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

这里的端口号要替换成实际启动时的端口。MCP 协议本身是 JSON-RPC 格式，所以调用工具也遵循同样的消息结构。具体请求体需要参考你使用的 MCP 服务器实现。

7. 资源占用与性能观察

7.1 观察哪些指标

启动 OpenCode 和博途 MCP 服务器后，建议打开任务管理器，观察以下进程：

• opencode主进程：占用内存一般不高。
• node或python类型的 MCP 服务进程：解析项目时 CPU 和内存会有明显波动。
• 本地大模型推理进程：如果走 Ollama 这类本地服务，需要观察 GPU 显存占用。

7.2 影响性能的关键因素

• 博途项目文件大小：项目里块越多、注释越复杂，MCP 服务器解析时间越长。
• 每次请求携带的上下文：提问越长，模型处理越慢，API 费用也越高。
• MCP 服务器是否重复解析项目：有些实现每次启动都重新解析.ap文件，这会拖慢首次响应。
• 本地模型还是云端 API：本地模型响应速度和显存占用取决于模型参数量；云端 API 主要开销在网络延迟和 token 数量。

7.3 降低资源占用的方法

• 先用博途把项目导出成 SCL 文本文件，再让 MCP 服务器读取文本文件，不直接解析.ap。
• 一次提问只聚焦一个模块，不要把所有源码一次性塞给模型。
• 在 OpenCode 中配置合理的上下文限制，避免长对话导致 token 爆炸。
• 批量任务时控制并发数，避免短时间内同时发起大量请求。

8. 常见问题与排查方法

8.1 没有可用的博途 MCP 服务器怎么办

如果你暂时找不到可用的博途 MCP 服务器，可以先用备选方案：直接在博途中把程序块导出为.scl文件，放到项目目录下，然后让 OpenCode 直接读取这些文本文件。虽然少了“动态读取项目”的能力，但分析 AF 框架案例的结构和逻辑也够用。

导出 SCL 的方式在博途里很直接：选中程序块，右键选择“从块生成源”，或者通过 Openness 脚本批量导出。

9. 最佳实践与使用建议

9.1 先用最小案例跑通

不要一上来就分析整个官方 AF 框架大案例。先创建一个只有一个 OB、两个 FB 的测试项目，把 MCP 链路跑通，确认 AI 能读到代码、能回答正确，再切换到真实案例。

9.2 项目文件与导出文件分开管理

• 原始.ap文件只读，不修改。
• 导出的 SCL 源文件放到独立目录。
• AI 生成的分析文档按项目名归档，方便后续复用。

9.3 提问策略

先问总览，再问细节。例如：

1. “这个项目的整体控制流程是什么？”
2. “OB1 调用了哪些功能块？”
3. “FB_ValveControl 的主要逻辑是什么？”
4. “AF 框架中的状态机是怎么实现的？”

这样能让 AI 逐步建立上下文，回答质量更高。

9.4 批量任务要加日志和重试

批量分析案例时，不要让一个失败任务拖垮整轮。脚本里要记录每个项目的日志，失败时单独标记，等第一轮跑完再重试失败项。

9.5 牢牢守住安全边界

• 不要将私有工程项目上传到不明确数据策略的云端 API。
• 不要用 AI 生成的结果直接修改安全相关逻辑。
• 官方示例程序可以用于学习，但不要违规二次分发。
• 涉及人脸、声音等场景时还需额外确认授权，本方案涉及的是 PLC 程序，主要关注代码版权和工程数据保密。

10. 总结与下一步

这个方案最值得尝试的地方在于：它不是简单地把代码片段复制给 AI，而是让 AI 通过 MCP 协议主动读取博途项目里的程序块、变量和调用关系，把学习官方 AF 框架案例的“找代码、读代码、理解结构”过程压缩成几轮对话。如果你经常需要阅读别人写的 PLC 程序，这套链路值得认真配置一次。

最先应该验证的是 MCP 连接是否成功，也就是/mcp能不能看到工具列表；如果这一步通了，后面所有的分析功能基本都能跑起来。最容易踩的坑集中在三处：博途项目路径配置错误、Node.js 版本太低、一次提问塞入太多上下文。按“最小案例连通、结构化提问、批量导出文档”的顺序推进，投入产出比最高。

后续可以扩展的方向很多：把分析结果整理成团队内部案例库；编写脚本对多个 AF 案例自动生成培训文档；把 MCP 服务器集成到自己的 Web 工具中；或者接入本地大模型，实现完全离线的代码导读。建议先花半天时间把 OpenCode 加博途 MCP 服务器的链路跑通，之后你再打开官方 AF 框架案例时，会觉得效率明显不一样。