我的征尘是星辰大海。。。

The dirt and dust from my pilgrimage forms oceans of stars...

-------当记忆的篇章变得零碎，当追忆的图片变得模糊，我们只能求助于数字存储的永恒的回忆

作者:黄教授

手机视频列表

个人工程实践备忘录

视频

音频

原始脚本

个人工程实践备忘录。
分布式双 AI Agent 协同围棋视觉识别项目全流程记录。
文档用途，完整记录2026年6月18日全天实践。
踩坑、设计思路、问题根源、留存多 agent 协同、火山 coding plan 工具适配、 open cv 传统视觉缺陷复盘。
一、项目基础背景、前置历史。
一、初代围棋识别程序开发历史。
一年前基于 Google Gemini 协作开发围棋棋谱录制工具。
核心功能全部落地。
一、图像采集、棋盘识别、棋子坐标解析。
二、标准 SGF 围棋棋谱文件导出。
三、 Study 分布回放模式，逐手还原对局落子顺序。
四、简易交互控制台，支持基础参数调整。
初代程序两大核心无解痛点。
一、棋盘四角自动检测泛化能力极差。
传统 OpenCV 应阈值方案缺陷依赖人工手写腐蚀膨胀。
颜色、颜码、轮廓匹配、角点检测、多层 if else 规则，受多重现实变量干扰，环境光照强弱、棋盘底色色差。
棋子哑光、镜面反光、画面杂物噪声、摄像头俯仰、倾斜拍摄角度、任意变量改变，检测逻辑直接失效。
无法覆盖全部现实场景。
临时折中方案，开发人工校准交互模块，通过鼠标、键盘手动拖拽，标注棋盘四个顶点，人工兜底修正识别偏差，仅能临时使用。
无法全自动运行。
二、棋子判定边界模糊问题，行业俗称推棋。
实际对局中，棋子无法完美贴合棋盘交叉点。
存在偏移半跨格情况。
斜视角摄像头会进一步放大坐标误差，连人类肉眼都存在判定歧义。
棋盘边缘堆积多余棋子会造成大量轮廓误检。
传统图像处理无法量化模糊边界归属。
初代项目结论，纯传统计算机视觉手写规则存在场景天花板，必须引入 YOLO 目标检测深度学习模型。
依靠标注数据及训练替代人工阈值逻辑，才能解决泛化差、模糊棋子判定两大核心难题。
二、本次迭代目标。
复用原有围棋代码工程，基于火山方舟、 Coding Plan 豆包代码大模型、 Cloud Code 客户端兼容层，搭建双设备分布式 AI Agent 协同开发流水线。
完成三件事。
一、重构图像检测模块，接入 YOLO 目标检测，淘汰纯 OpenCV 阈值识别。
二、建立标准化师生模式、测试教研体系，用200加张实景棋盘图片做测试题库，量化漏检、误检指标。
三、树莓派五，嵌入式图像采集端，加 Zbook 笔记本算力开发端，双 Agent 分工协作，同步开发，批量自测。
统一迭代代码。
二、前置环境部署全流程。
今日上午踩坑最多阶段一，Cloud Code 客户端获取难题一。
Anthropic 官方服务对中国大陆 IP 全域封锁，官网账号注册、原生 API 直连完全不可用。
二、仅独立二进制客户端安装包可通过境外网络下载。
解决方案，租用 DigitalOcean 美区 VPS 中转拉取安装包。
三、客户端特性，静态单文件编译，零动态库依赖。
同时支持 X 八六六四、 Zbook  A R M 六四、树莓派五双架构，下载对应架构程序可直接运行。
大幅降低多设备部署成本。
四、推理底层，客户端仅为交互外壳，不直连 anthropic 官方服务，全部请求转发火山方舟。
API  coding 兼容接口。
订阅套餐为 coding plan light 40元每月。
二、双设备分布式通信底层搭建一。
打通树莓派5与 Zbook 免密 SSH 公钥登录，实现双向文件读写、远程指令下发。
二、Claude Code 个人版底层通信机制限制。
企业商业版支持邮件轮巡，常连接消息同步，可实时感知跨实例指令。
个人版无内置消息队列，仅依靠共享目录文件读写传递任务。
测试日志、代码文件常驻 Agent 不会自动监听文件变更，仅能通过定时轮询、手动执行读取指令、同步信息，是极简但低效的原始 IPC 方案。
三 Git 仓库协作拓扑设计，放弃两台设备互相设为 Origin 的冗余方案，采用单一基准仓库作为核心源。
两台设备仅向基准库推拉代码，彼此仅同步临时开发分支，规避多元仓库提交冲突。
三、中途支线。
误以为限流来自 anthropic。
折腾 OpenCode 的完整踩坑链一。
现象， claude code 客户端调用抛出429超限报错，主观误判为 anthropic 对第三方客户端限流。
二、动机。
为绕开 claude 官方限制，下载 open code cli 工具，尝试更换客户端。
三、连续多层配置报错。
一、手动编写 Open Code Jason 旧版 Open Code 对 temperature 浮点参数做布尔类型强校验，配置文件直接失效。
混淆火山两套独立兼容接口。
API，Coding，Anthropic 协议。
API，Coding，斜杠 V 三，OpenAI 协议。
两套接口支持的模型名单完全隔 会用后持续提示， coding plan 不支持该模型。
使用官方 ark helper 一键配置工具，标准化参数，彻底修复 jason 接口、模型名匹配问题。
四、最终事实澄清，429限流与 anthropic 无任何关联，全部是火山 coding plan light 套餐自带5小时滚动 token 额度限制。
Cloud Code  Open Code 共享同一套餐额度值，切换客户端无法规避限流。
本次支线属于完全无意义的额外调试。
三、双 Agent。
师生测试校验体系设计，今日下午核心方案，以200张实景棋盘实拍图作为标准化测试题库，建立二元判定四分类评估标准。
量化识别算法优劣分为两种工作模式。
模式一，导师模式，人工出题， Agent 执行检测，由本人提供图片标准答案。
Agent 运行棋盘 detector 输出识别结果，四类判定结果。
一、 true true 图内含棋盘，模型成功检出，真阳性，合格。
二、True  false 图内含棋盘，模型漏检缺陷，需优化图像预处理。
三、 false  true。
无棋盘杂物图，模型误检出棋盘缺陷，需优化干扰过滤逻辑。
四、 false false 无棋盘，模型正确判定无棋盘，真阴性，合格。
模式二，学生模式， Agent 自主批量自测。
人工复核批改。
两台 Agent 独立批量跑完全部200张测试图片，自动生成检测日志。
本人通过 VNC 远程桌面分别接入两台设备。
人工逐图 review 标记四类结果，反向迭代 YOLO 与 OpenCV 代码逻辑。
双设备分工规划一， Zbook 笔记本高性能算理端。
代码编译、优乐模型训练、大批量图片批量推理、日志汇总统计。
二、树莓派五、嵌入式终端。
摄像头实景实时图像采集、本地检测器实际验证、嵌入式环境兼容测试。
三、协作流程。
向任意一台 Agent 下发迭代计划。
Agent 通过共享文件同步任务给另一台协作 Body 两台设备并行完成自测，产出两份独立测试报告。
运行后出现的分歧现象。
200张测试图批量执行完成后，两台 Agent 的识别判定结果大部分一致，但存在少量样本分歧。
推测分歧根源一。
两台设备 OpenCV 版本，图像解码底层存在微小差异，预处理输出像素偏差。
二、两端代码版本未完全同步。
某一侧存在未同步的参数调整。
三、低对比度、强光反光的边界模糊样本，检测置信度落在临界阈值，两端判定逻辑相反。
两台设备并发调用同一 coding plan light 套餐，5小时滚动 token 额度双向消耗，同等时间内消耗量翻倍，天然加速额度耗尽。
人工批改多轮测试日志后，发现算法识别缺陷较多。
下发指令给双 agent 优化流程，不再由人工 review 图片，让 agent 直接将全部测试图片。
上传至豆包代码大模型，由模型自主批改识别结果。
图像类多模态输入会产生极大 token 开销，即便图片完整上传，流程未完全执行。
批量图像请求预加载阶段就快速耗尽5小时滚动额度，直接触发429超限拦截。
平台报错文案存在严重误导性。
不会优先提示额度不足，反而抛出模型不兼容类提示，大幅提升故障排查难度。
Coding Plan Lite 套餐限制，5小时滚动额度、每周总额度、月度总额度三层限流。
Cloud Code  Open Code 等全部兼容编程工具，额度互通共享。
禁用通用 API v 一接口，仅 API coding。
App、 Coden、 V 三两条专用路径消耗套餐内免费额度，通用接口会单独产生付费。
Auto 自动调度模型仅支持 Anthropic 兼容接口，OpenAI V 三接口仅支持带 Code 后缀专用代码模型。
两套接口模型池完全隔离，配置极易出错。
验证了嵌入式端加高性能 pc 双 ai 代理分工开发的可行性。
贴合视觉嵌入式项目真实研发流程，师生四分类测试闭环，将模糊的视觉识别效果量化，替代过去纯主观调参模式。
迭代效率显著提升，完整摸清第三方兼容客户端、中转大模型平台、本地硬件三者的层级关系，厘清原生 anthropic 与火山 coding plan 两套完全隔离的体系。
纠正了客户端限流的认知误区。
通信机制短板，文件轮询同步消息效率极低，后续可搭建简易本地轻量消息队列，替代共享文件。
实现跨 Agent 实施任务同步。
套餐额度瓶颈， Lite 套餐无法支撑双设备并发加图像多模态自测。
长期高频开发，可切换单设备串行测试。
或升级 Coding Plan Pro 套餐提升额度上限。
平台工具缺陷，火山方舟报错文案分层混乱，两套接口文档分散，无额度实时可视化预警。
配置故障排查成本极高。
Agent分歧自动化开发日志对比脚本，自动筛选两台设备判定不一致的图片清单，无需人工逐张核对。
完成优漏检测模块完整接入，彻底解决传统 open cv 泛化差、推棋模糊判定的历史痛点。
完善双 agent 自动化自测流水线。
实现批量图片检测，分歧自动汇总，代码迭代闭环。
树莓派实际部署完整全自动围棋棋谱录制程序，取消人工四角校准兜底模块。
大陆网络封锁海外 AI 原生服务，兼容中转平台存在独立复杂的套餐、接口、模型规则，极易产生认知混淆。
多 Agent 并发共用同一订阅额度会加速限流。
图像多模态输入 token 消耗远高于纯文本代码对话。
中转平台报错提示逻辑混乱。
故障类型无清晰区分，易将额度耗尽。
配置参数错误，两类完全独立问题混淆。
传统手写规则计算机视觉存在天然场景天花板。
深度学习目标检测是实景多干扰场景下的唯一长期解决方案。
开源 AI 编程客户端存在版本兼容性 bug 官方一键配置工具可大幅降低手动配置失误概率。

修正脚本

个人工程实践备忘录。
分布式双 AI Agent 协同围棋视觉识别项目全流程记录。
文档用途，完整记录2026年6月18日全天实践。
踩坑、设计思路、问题根源、留存多 agent 协同、火山 coding plan 工具适配、 open cv 传统视觉缺陷复盘。
一、项目基础背景、前置历史。
一、初代围棋识别程序开发历史。
一年前基于 Google Gemini 协作开发围棋棋谱录制工具。
核心功能全部落地。
一、图像采集、棋盘识别、棋子坐标解析。
二、标准 SGF 围棋棋谱文件导出。
三、 Study 分步回放模式，逐手还原对局落子顺序。
四、简易交互控制台，支持基础参数调整。
初代程序两大核心无解痛点。
一、棋盘四角自动检测泛化能力极差。
传统 OpenCV 硬阈值方案缺陷依赖人工手写腐蚀膨胀。
颜色、色域、轮廓匹配、角点检测、多层 if else 规则，受多重现实变量干扰，环境光照强弱、棋盘底色色差。
棋子哑光、镜面反光、画面杂物噪声、摄像头俯仰、倾斜拍摄角度、任意变量改变，检测逻辑直接失效。
无法覆盖全部现实场景。
临时折中方案，开发人工校准交互模块，通过鼠标、键盘手动拖拽，标注棋盘四个顶点，人工兜底修正识别偏差，仅能临时使用。
无法全自动运行。
二、棋子判定边界模糊问题，行业俗称推棋。
实际对局中，棋子无法完美贴合棋盘交叉点。
存在偏移半跨格情况。
斜视角摄像头会进一步放大坐标误差，连人类肉眼都存在判定歧义。
棋盘边缘堆积多余棋子会造成大量轮廓误检。
传统图像处理无法量化模糊边界归属。
初代项目结论，纯传统计算机视觉手写规则存在场景天花板，必须引入 YOLO 目标检测深度学习模型。
依靠标注数据及训练替代人工阈值逻辑，才能解决泛化差、模糊棋子判定两大核心难题。
二、本次迭代目标。
复用原有围棋代码工程，基于火山方舟、 Coding Plan 豆包代码大模型、 Cloud Code 客户端兼容层，搭建双设备分布式 AI Agent 协同开发流水线。
完成三件事。
一、重构图像检测模块，接入 YOLO 目标检测，淘汰纯 OpenCV 阈值识别。
二、建立标准化师生模式、测试教研体系，用200多张实景棋盘图片做测试题库，量化漏检、误检指标。
三、树莓派五，嵌入式图像采集端，加 Zbook 笔记本算力开发端，双 Agent 分工协作，同步开发，批量自测。
统一迭代代码。
二、前置环境部署全流程。
今日上午踩坑最多阶段一，Cloud Code 客户端获取难题一。
Anthropic 官方服务对中国大陆 IP 全域封锁，官网账号注册、原生 API 直连完全不可用。
二、仅独立二进制客户端安装包可通过境外网络下载。
解决方案，租用 DigitalOcean 美区 VPS 中转拉取安装包。
三、客户端特性，静态单文件编译，零动态库依赖。
同时支持 X86-64、ARM 64、树莓派五双架构，下载对应架构程序可直接运行。
大幅降低多设备部署成本。
四、推理底层，客户端仅为交互外壳，不直连 anthropic 官方服务，全部请求转发火山方舟。
API  coding 兼容接口。
订阅套餐为 coding plan light 40元每月。
二、双设备分布式通信底层搭建
一、打通树莓派5与 Zbook 免密 SSH 公钥登录，实现双向文件读写、远程指令下发。
二、Claude Code 个人版底层通信机制限制。
企业商业版支持邮件轮巡，长连接消息同步，可实时感知跨实例指令。
个人版无内置消息队列，仅依靠共享目录文件读写传递任务。
测试日志、代码文件常驻 Agent 不会自动监听文件变更，仅能通过定时轮询、手动执行读取指令、同步信息，是极简但低效的原始 IPC 方案。
三、Git 仓库协作拓扑设计，放弃两台设备互相设为 Origin 的冗余方案，采用单一基准仓库作为核心源。
两台设备仅向基准库推拉代码，彼此仅同步临时开发分支，规避多元仓库提交冲突。
三、中途支线。
误以为限流来自 anthropic。
折腾 OpenCode 的完整踩坑链
一、现象， claude code 客户端调用抛出429超限报错，主观误判为 anthropic 对第三方客户端限流。
二、动机。
为绕开 claude 官方限制，下载 open code cli 工具，尝试更换客户端。
三、连续多层配置报错。
一、手动编写 Open Code JSON 旧版 Open Code 对 temperature 浮点参数做布尔类型强校验，配置文件直接失效。
混淆火山两套独立兼容接口。
API，Coding，Anthropic 协议。
API，Coding，斜杠 V 三，OpenAI 协议。
两套接口支持的模型名单完全隔离，使用后持续提示， coding plan 不支持该模型。
使用官方 ark helper 一键配置工具，标准化参数，彻底修复 json 接口、模型名匹配问题。
四、最终事实澄清，429限流与 anthropic 无任何关联，全部是火山 coding plan light 套餐自带5小时滚动 token 额度限制。
Cloud Code  Open Code 共享同一套餐额度值，切换客户端无法规避限流。
本次支线属于完全无意义的额外调试。
三、双 Agent。
师生测试校验体系设计，今日下午核心方案，以200张实景棋盘实拍图作为标准化测试题库，建立二元判定四分类评估标准。
量化识别算法优劣分为两种工作模式。
模式一，导师模式，人工出题， Agent 执行检测，由本人提供图片标准答案。
Agent 运行棋盘 detector 输出识别结果，四类判定结果。
一、 true true 图内含棋盘，模型成功检出，真阳性，合格。
二、True  false 图内含棋盘，模型漏检缺陷，需优化图像预处理。
三、 false  true。
无棋盘杂物图，模型误检出棋盘缺陷，需优化干扰过滤逻辑。
四、 false false 无棋盘，模型正确判定无棋盘，真阴性，合格。
模式二，学生模式， Agent 自主批量自测。
人工复核批改。
两台 Agent 独立批量跑完全部200张测试图片，自动生成检测日志。
本人通过 VNC 远程桌面分别接入两台设备。
人工逐图 review 标记四类结果，反向迭代 YOLO 与 OpenCV 代码逻辑。
双设备分工规划一， Zbook 笔记本高性能算力端。
代码编译、YOLO模型训练、大批量图片批量推理、日志汇总统计。
二、树莓派五、嵌入式终端。
摄像头实景实时图像采集、本地检测器实际验证、嵌入式环境兼容测试。
三、协作流程。
向任意一台 Agent 下发迭代计划。
Agent 通过共享文件同步任务给另一台协作Agent，两台设备并行完成自测，产出两份独立测试报告。
运行后出现的分歧现象。
200张测试图批量执行完成后，两台 Agent 的识别判定结果大部分一致，但存在少量样本分歧。
推测分歧根源一。
两台设备 OpenCV 版本，图像解码底层存在微小差异，预处理输出像素偏差。
二、两端代码版本未完全同步。
某一侧存在未同步的参数调整。
三、低对比度、强光反光的边界模糊样本，检测置信度落在临界阈值，两端判定逻辑相反。
两台设备并发调用同一 coding plan light 套餐，5小时滚动 token 额度双向消耗，同等时间内消耗量翻倍，天然加速额度耗尽。
人工批改多轮测试日志后，发现算法识别缺陷较多。
下发指令给双 agent 优化流程，不再由人工 review 图片，让 agent 直接将全部测试图片。
上传至豆包代码大模型，由模型自主批改识别结果。
图像类多模态输入会产生极大 token 开销，即便图片完整上传，流程未完全执行。
批量图像请求预加载阶段就快速耗尽5小时滚动额度，直接触发429超限拦截。
平台报错文案存在严重误导性。
不会优先提示额度不足，反而抛出模型不兼容类提示，大幅提升故障排查难度。
Coding Plan Lite 套餐限制，5小时滚动额度、每周总额度、月度总额度三层限流。
Cloud Code  Open Code 等全部兼容编程工具，额度互通共享。
禁用通用 API v 一接口，仅 API coding。
App、 Code、 V 三两条专用路径消耗套餐内免费额度，通用接口会单独产生付费。
Auto 自动调度模型仅支持 Anthropic 兼容接口，OpenAI V 三接口仅支持带 Code 后缀专用代码模型。
两套接口模型池完全隔离，配置极易出错。
验证了嵌入式端加高性能 pc 双 ai 代理分工开发的可行性。
贴合视觉嵌入式项目真实研发流程，师生四分类测试闭环，将模糊的视觉识别效果量化，替代过去纯主观调参模式。
迭代效率显著提升，完整摸清第三方兼容客户端、中转大模型平台、本地硬件三者的层级关系，厘清原生 anthropic 与火山 coding plan 两套完全隔离的体系。
纠正了客户端限流的认知误区。
通信机制短板，文件轮询同步消息效率极低，后续可搭建简易本地轻量消息队列，替代共享文件。
实现跨 Agent 实时任务同步。
套餐额度瓶颈， Lite 套餐无法支撑双设备并发加图像多模态自测。
长期高频开发，可切换单设备串行测试。
或升级 Coding Plan Pro 套餐提升额度上限。
平台工具缺陷，火山方舟报错文案分层混乱，两套接口文档分散，无额度实时可视化预警。
配置故障排查成本极高。
Agent分歧自动化开发日志对比脚本，自动筛选两台设备判定不一致的图片清单，无需人工逐张核对。
完成YOLO检测模块完整接入，彻底解决传统 open cv 泛化差、推棋模糊判定的历史痛点。
完善双 agent 自动化自测流水线。
实现批量图片检测，分歧自动汇总，代码迭代闭环。
树莓派实际部署完整全自动围棋棋谱录制程序，取消人工四角校准兜底模块。
大陆网络封锁海外 AI 原生服务，兼容中转平台存在独立复杂的套餐、接口、模型规则，极易产生认知混淆。
多 Agent 并发共用同一订阅额度会加速限流。
图像多模态输入 token 消耗远高于纯文本代码对话。
中转平台报错提示逻辑混乱。
故障类型无清晰区分，易将额度耗尽错误与配置参数错误，两类完全独立问题混淆。
传统手写规则计算机视觉存在天然场景天花板。
深度学习目标检测是实景多干扰场景下的唯一长期解决方案。
开源 AI 编程客户端存在版本兼容性 bug 官方一键配置工具可大幅降低手动配置失误概率。

英文翻译

Personal Engineering Practice Memo.

Full Process Record of Distributed Dual AI Agent Collaborative Go Vision Recognition Project.

Document Purpose: Complete record of the full-day practice on June 18, 2026.

Pitfalls, Design Ideas, Root Causes, Multi-Agent Collaboration, Volcanic Coding Plan Tool Adaptation, OpenCV Traditional Vision Defect Review.

I. Project Background and Prior History.

I. History of the First-Generation Go Recognition Program Development.

One year ago, a Go game recording tool was developed based on collaboration with Google Gemini.

All core functionalities were implemented.

I. Image acquisition, board recognition, stone coordinate parsing.

II. Export of standard SGF Go game record files.

III. Study step-by-step replay mode, reconstructing the move order of the game move by move.

IV. Simple interactive console supporting basic parameter adjustments.

The two major unsolvable pain points of the first-generation program:

I. Extremely poor generalization of automatic detection of the four board corners.

Defects in traditional OpenCV hard threshold scheme: reliance on manual hand-crafted erosion and dilation.

Color, color gamut, contour matching, corner detection, multi-layer if-else rules, affected by multiple real-world variables: ambient lighting intensity, board background color difference.

Stone matte finish, mirror reflections, image noise from clutter, camera pitch, tilt shooting angles. Any change in variables leads to direct failure of the detection logic.

Cannot cover all real-world scenarios.

Temporary compromise: developed a manual calibration interaction module, allowing manual dragging with mouse and keyboard to mark the four board vertices, manually correcting recognition deviations. Only usable as a temporary fix.

Cannot run fully automatically.

II. The problem of ambiguous stone judgment boundaries, commonly known as "stone pushing" in the industry.

In actual games, stones cannot perfectly align with board intersections.

There are cases of offset by half a grid.

An angled camera further amplifies coordinate errors, causing ambiguity even for the human eye.

Excess stones piled at the board edges cause numerous false contour detections.

Traditional image processing cannot quantify the attribution of ambiguous boundaries.

Conclusion of the first-generation project: Pure traditional computer vision with hand-coded rules has a scenario ceiling. YOLO object detection deep learning model must be introduced.

Relying on labeled data and training to replace manual threshold logic to solve the two core problems of poor generalization and ambiguous stone judgment.

II. Goals of This Iteration.

Reuse the original Go code project. Based on Volcanic Ark, Coding Plan Doubao Code Large Model, and Cloud Code client compatibility layer, build a dual-device distributed AI Agent collaborative development pipeline.

Complete three tasks:

I. Refactor the image detection module, integrate YOLO object detection, eliminate pure OpenCV threshold recognition.

II. Establish a standardized teacher-student mode, test and research system. Use 200+ real board images as a test question bank, quantify missed detection and false detection metrics.

III. Raspberry Pi 5, embedded image acquisition end, plus Zbook laptop computing development end. Dual Agent division of labor and collaboration, synchronous development, batch self-testing.

Unified iteration of code.

II. Full Process of Pre-Environment Deployment.

Phase with the most pitfalls this morning: Cloud Code client acquisition challenges.

I. Anthropic official services are fully blocked for mainland China IPs. Official website account registration and native API direct connection are completely unavailable.

II. Only the standalone binary client installer can be downloaded via overseas networks.

Solution: Rent a DigitalOcean US VPS as a relay to pull the installer.

III. Client characteristics: static single-file compilation, zero dynamic library dependencies.

Supports both X86-64 and ARM 64, including Raspberry Pi 5 dual architecture. Downloading the corresponding architecture program allows direct execution.

Greatly reduces multi-device deployment costs.

IV. Reasoning backend: the client is merely an interactive shell, does not directly connect to Anthropic official services. All requests are forwarded to Volcanic Ark.

API coding compatible interface.

Subscription plan is Coding Plan Light, 40 RMB/month.

II. Building the Distributed Communication Layer for Dual Devices.

I. Enable passwordless SSH public key login between Raspberry Pi 5 and Zbook, allowing bidirectional file read/write and remote command dispatch.

II. Limitations of Claude Code personal edition's underlying communication mechanism.

Enterprise commercial edition supports email polling, long connection message synchronization, enabling real-time awareness of cross-instance commands.

Personal edition has no built-in message queue, only relies on shared directory file read/write to transfer tasks.

Test logs and code files resident in the Agent. The Agent does not automatically monitor file changes; it can only read instructions and synchronize information through timed polling or manual execution. This is a minimal but inefficient raw IPC solution.

III. Git repository collaboration topology design: Abandon the redundant scheme of setting the two devices as each other's origin. Use a single benchmark repository as the core source. Both devices only push and pull code to the benchmark repository, and only synchronize temporary development branches with each other, avoiding conflicts from multiple repository commits.

III. Midway Side Branch.

Misunderstood rate limiting as coming from Anthropic.

Complete pitfall chain of tinkering with OpenCode.

I. Phenomenon: The Claude Code client threw a 429 quota exceeded error. Subjectively misjudged it as Anthropic rate limiting third-party clients.

II. Motivation: To bypass Claude's official restrictions, downloaded the Open Code CLI tool and attempted to switch clients.

III. Continuous multi-layer configuration errors.

I. Manually wrote Open Code JSON. The old version of Open Code enforced a boolean type check for the temperature float parameter, causing the configuration file to fail directly.

Confused two separate Volcanic compatible interfaces.

API, Coding, Anthropic protocol.

API, Coding, slash V3, OpenAI protocol.

The model lists supported by the two interfaces are completely isolated. After use, consistently prompted that "Coding Plan does not support this model."

Used the official Ark Helper one-click configuration tool, standardized parameters, completely fixed JSON interface and model name matching issues.

IV. Final factual clarification: The 429 rate limit has nothing to do with Anthropic. It is entirely due to the 5-hour rolling token quota limit of the Volcanic Coding Plan Light subscription.

Cloud Code and Open Code share the same subscription quota. Switching clients cannot bypass the rate limit.

This side branch was a completely unnecessary extra debugging effort.

III. Dual Agent.

Teacher-Student Test and Verification System Design. Core plan for this afternoon: Use 200 real board photos as a standardized test question bank, establishing a binary judgment four-class evaluation standard.

Quantify recognition algorithm quality into two working modes:

Mode 1: Teacher mode. Human sets questions, Agent performs detection. Standard answers provided by me for the images.

Agent runs the board detector and outputs recognition results, four judgment categories:

I. True True: Image contains a board, model successfully detected. True positive, pass.

II. True False: Image contains a board, model missed detection (defect). Need to optimize image preprocessing.

III. False True: Image of clutter without a board, model falsely detected board (defect). Need to optimize interference filtering logic.

IV. False False: No board, model correctly judged no board. True negative, pass.

Mode 2: Student mode. Agent autonomously batch self-tests.

Manual review and correction.

Both Agents independently run all 200 test images in batch, automatically generate detection logs.

I access both devices via VNC remote desktop.

Manually review each image, mark the four types of results, and iteratively refine YOLO and OpenCV code logic.

Dual device division plan:

I. Zbook laptop: high-performance computing end. Code compilation, YOLO model training, large-scale batch image inference, log aggregation statistics.

II. Raspberry Pi 5: embedded terminal. Real-time camera image acquisition, local detector validation, embedded environment compatibility testing.

III. Collaboration process: Send an iteration plan to either Agent. The Agent synchronizes the task to the collaborating Agent via shared files. Both devices parallel self-test, producing two independent test reports.

Discrepancy phenomenon after running:

After batch execution of the 200 test images, the recognition results of the two Agents were mostly consistent, but there were a few sample discrepancies.

Speculated root causes of discrepancies:

I. Slight differences in OpenCV versions and image decoding backends between the two devices, resulting in pixel deviations in preprocessing output.

II. Code versions not fully synchronized between the two ends. Some parameter adjustments on one side were not synced.

III. Low contrast, strong light reflection boundary ambiguous samples, detection confidence falling on the critical threshold, causing opposite judgment logic on the two ends.

Both devices concurrently called the same Coding Plan Light subscription. The 5-hour rolling token quota was consumed bidirectionally, doubling the consumption rate over the same time period, naturally accelerating quota exhaustion.

After manually reviewing multiple rounds of test logs, many algorithm recognition defects were found.

Issued instructions to both Agents to optimize the process: instead of manual image review, let the Agents directly upload all test images to the Doubao Code Large Model, and let the model autonomously review the recognition results.

Image multimodal input incurs extremely large token overhead. Even if images were fully uploaded, the process was not fully executed.

During the batch image request preloading phase, the 5-hour rolling quota was quickly exhausted, directly triggering 429 overload interception.

The platform error messages were severely misleading.

Instead of prioritizing a quota insufficient hint, they threw model incompatibility type prompts, greatly increasing troubleshooting difficulty.

Coding Plan Lite subscription limitations: three-layer rate limiting: 5-hour rolling quota, weekly total quota, monthly total quota.

All compatible programming tools such as Cloud Code and Open Code share the same quota.

The general API v1 interface is disabled. Only the API Coding App Code V3 two dedicated paths consume the subscription's free quota. The general interface will incur separate charges.

The Auto scheduling model only supports the Anthropic compatible interface. The OpenAI V3 interface only supports dedicated code models with the Code suffix.

The two interface model pools are completely isolated, making configuration very error-prone.

IV. Summary.

Verified the feasibility of a dual AI agent division of labor approach with embedded end + high-performance PC.

Aligned with the real development process of vision embedded projects. The teacher-student four-category test loop quantifies vague visual recognition performance, replacing the previous purely subjective parameter tuning mode.

Iteration efficiency significantly improved. Fully understood the hierarchical relationship between third-party compatible clients, relay large model platforms, and local hardware. Clarified the two completely isolated systems: native Anthropic and Volcanic Coding Plan.

Corrected the misconception about client rate limiting.

Communication mechanism shortcomings: File polling for message synchronization is extremely inefficient. In the future, a simple local lightweight message queue could be built to replace shared files, enabling real-time task synchronization across Agents.

Quota bottleneck: The Lite subscription cannot support dual-device concurrency plus image multimodal self-testing. For long-term high-frequency development, switch to single-device serial testing or upgrade to Coding Plan Pro to increase the quota limit.

Platform tool defects: Volcanic Ark error messages are poorly layered. The two interface documentations are scattered, with no real-time quota visualization warning. Configuration troubleshooting cost is extremely high.

Agent discrepancy automation: Develop a log comparison script to automatically filter out images where the two devices' judgments differ, eliminating the need for manual image-by-image checking.

Completed full integration of the YOLO detection module, thoroughly solving the historical pain points of poor OpenCV generalization and ambiguous stone judgment.

Improved the dual-agent automated self-test pipeline.

Achieved batch image detection, automatic discrepancy aggregation, and code iteration closure.

Deployed a fully automatic Go game recording program on Raspberry Pi, removing the manual four-corner calibration fallback module.

Insights:

Mainland China's internet blockade of overseas AI native services. Compatible relay platforms have independent and complex subscription, interface, and model rules, easily causing cognitive confusion.

Multi-agent concurrency sharing the same subscription quota accelerates rate limiting.

Image multimodal input consumes far more tokens than pure text code conversations.

Relay platform error messages are illogical. Failure types are not clearly distinguished, easily confusing quota exhaustion errors with configuration parameter errors—two entirely separate issues.

Traditional hand-coded rule computer vision has a natural scenario ceiling. Deep learning object detection is the only long-term solution for complex real-world multi-interference scenarios.

Open-source AI programming clients have version compatibility bugs. Official one-click configuration tools can significantly reduce the probability of manual configuration errors.