用AI Agent实现SLG自动采集：感知-决策-执行全解析

你有没有想过，一款 SLG 游戏里最消耗耐心的，不是排兵布阵，不是联盟外交，而是每天上线后的那几十次资源采集。点开地图、找资源点、派队伍、等返回、再派出去，整套动作本身没有任何技术含量，却每天雷打不动地吃掉你半小时。

过去解决这个问题的方案是脚本，是模拟点击，是按键精灵式的固定坐标循环。这类方案本质上是用“规则”对抗“变化”：界面一改版就失效，地图一换就乱点，网络一卡就傻等，更不用说多队伍、多资源点、不同采集时间的动态调度，传统脚本根本做不过来。

而 AI 时代的自动化，换了一个底层思路。

它不再执着于“精确模拟点击”，而是让程序长出眼睛和脑子：先看屏幕，理解当前地图和资源状态，再决定下一步派哪支队伍、去哪里采集、什么时候召回。这不再是 Rule-based 的脚本，而是 Perception-Decision-Action 的智能体。

这也是“清源AI开发教程-无尽冬日自动采集”这个项目最值得关注的地方。它不是一个简单的工具，而是一个完整的 AI Agent 开发案例，帮玩家把最枯燥的日常采集交给 AI，同时让开发者通过清源AI平台学习智能体开发、视觉识别、任务编排和异常兜底这一整套技能。

这篇文章我会从开发者视角，把这套自动采集智能体拆开讲清楚：它背后的技术原理是什么，开发流程怎么走，调试和验证要怎么做，以及真正容易踩坑的地方在哪里。

1. 为什么“自动采集”值得用 AI 重做一遍

先把结论放在前面：采集这类任务，恰好是 AI Agent 最适合落地的场景之一。

1.1 日常采集的三个特征

无尽冬日这类型游戏，日常采集任务有三个很突出的特征：

• 重复性极高。每天登录、找资源点、派采集队、等回城，几乎是一个固定循环。
• 动态变化明显。地图资源点的分布、剩余数量、其他玩家的争夺情况，每天都在变化。
• 视觉判断依赖强。判断一个资源点是否可采、队伍是否空闲、背包是否已满，靠的不是程序内部接口，而是屏幕上的画面。

这三个特征叠加在一起，意味着传统脚本很难稳定完成，而 AI 智能体却能发挥优势。

1.2 传统脚本的三个死穴

如果你写过模拟点击脚本，一定遇到过下面这类问题：

传统脚本的思维是“记住动作序列”，而 AI 智能体的思维是“理解目标并动态执行”。

1.3 AI 方案到底改变了哪一层

AI 自动采集的开发思路，不是写完点击坐标就结束，而是把整件事拆成三层：

• 感知层：通过截图和视觉识别，理解当前画面中的资源点、队伍状态、弹窗信息。
• 决策层：根据当前目标、队伍空闲状态、资源优先级，决定下一步动作。
• 执行层：把决策转换成实际操作，比如点击、滑动、确认，并验证动作是否生效。

这就是把它称为“智能体”而不是“脚本”的原因。脚本是固定的，智能体是能应对变化的。

2. 清源AI平台是什么，开发者能从中学到什么

2.1 平台定位

从公开资料和项目说明来看，清源AI是一个面向开发者的 AI 智能体开发平台，核心目标是把大模型能力、视觉识别、任务编排和自动化执行整合到一起，让开发者不需要从零搭建模型服务，就能构建属于自己的 AI 应用。

这个定位对独立开发者和进阶学习者都有价值。传统开发一个带视觉理解和决策能力的自动化程序，你需要：

• 自己部署视觉模型
• 自己写决策逻辑
• 自己搭建任务调度系统
• 自己处理各种异常情况

而在清源AI平台上，这些能力往往已经做成了服务或组件，开发者更关注的是：我的业务流程是什么、我需要模型做哪些决策、我的任务如何编排。

2.2 为什么说它适合作为 AI 开发入门案例

自动采集这类任务，表面上是游戏辅助，实际上是一个低门槛、高完整度的 AI 开发教学案例。它包含了几乎所有 AI Agent 都要面对的核心问题：

• 如何让模型理解真实世界的状态？
• 如何把一个长期任务拆成多步决策？
• 如何保证动作执行之后是可回滚、可验证的？
• 如何应对环境变化和异常？

这些能力，放到真实业务里，就是自动化运维、智能客服、RPA 机器人、UI 自动化测试的底层能力。这也是清源AI开发者招募这件事值得参与的原因——它更像是以赛代练，用一个具体任务把整套 AI 开发流程走完。

2.3 开发者招募与问卷

项目说明中提到“清源AI开发者招募中，欢迎大家填写评论区问卷报名”。如果你正在找 AI 开发方向的实践项目，这个入口可以留意一下。提前说一句，评论区问卷通常包含技术方向、擅长领域、期望获得的平台能力这类信息，建议填写前先梳理一下自己的基础，别写得太空。

3. 自动采集智能体的核心原理

这部分我们深入讲一下技术原理。理解了原理，后面开发才不会走弯路。

3.1 感知-决策-执行循环

AI 自动采集的实现核心是这样一个循环：

观察当前状态 -> 理解状态 -> 做出决策 -> 执行动作 -> 验证结果 -> 进入下一轮观察

用大白话说，就是“看一眼、想一下、动一下、再确认一下”。

这个循环不是一次性跑完就结束，而是持续运行。队伍采集中、队伍返回中、资源点被采空、意外弹窗打断……每一个状态变化都会触发新一轮感知和决策。

3.2 自动采集任务的需求拆解

把“帮我自动采集”这个模糊需求拆解成可执行的任务，大致是这样的：

每个子任务都是智能体的一步动作，而整个自动采集就是一个多步任务编排。

3.3 智能体需要具备的三种能力

• 界面理解能力：像人一样看懂屏幕内容，知道哪里是资源点、哪里是队伍列表。
• 决策规划能力：结合当前目标、资源优先级、队伍状态，选择最优动作。
• 动作执行与反馈能力：执行点击、滑动等操作，并确认操作是否生效。

这三项分别对应感知、决策、执行。如果你做过 UI 自动化测试，会对这套体系很熟悉，区别只是传统 UI 自动化靠定位器，AI 智能体靠视觉理解和语义理解。

3.4 与传统 UI 自动化的区别

这里做一个对比，便于理解 AI 方案的优势和适用边界：

结论很清楚：自动采集这类视觉强依赖、动态决策多的任务，AI 智能体方案有天然优势。

4. 环境准备与前置条件

开始开发前，先把环境准备好。这部分我会说明每一类环境的作用，具体版本请以清源AI平台实际提供的文档为准。

4.1 清源AI平台账号与开发者认证

第一步是注册清源AI平台账号，并进入开发者模式。通常需要：

• 一个可用的手机号或邮箱
• 完成基本实名认证
• 阅读并同意开发者协议

开发者认证的作用是开通模型调用、任务编排、部署发布等高级能力。如果项目说明中有招募问卷，可以先填写问卷，确认自己是否在首批开发者招募范围内。

4.2 运行设备与目标环境

自动采集需要真实运行游戏，所以你需要一台可以稳定运行游戏并进行屏幕捕获的设备。常见组合有两种：

• Android 模拟器 + ADB 控制
• 真机 + 无线调试

从开发便利性看，模拟器更适合初期调试，启动快、可截图、可随时重置环境。从真实效果看，真机更接近用户实际使用场景。建议初期用模拟器跑通逻辑，后期再到真机上做稳定性验证。

4.3 开发工具与依赖

平台相关的 SDK 以官方文档为准，但作为一个典型的 AI Agent 项目，常见依赖包括：

• Python 3.8+
• 图像处理库（如 OpenCV、Pillow）
• HTTP 客户端库（如 requests）
• 平台提供的智能体 SDK

如果你不确定装什么，可以先安装一个最小的 Python 环境，然后从项目模板或官方示例开始跑通，再逐步加依赖。

# 创建虚拟环境（示意） python3 -m venv qingyuan-env source qingyuan-env/bin/activate # 基础依赖（示意，以官方文档为准） pip install requests pillow opencv-python

4.4 一个重要提示：先想清楚最小可运行任务

很多新手在环境准备阶段就开始追求“完整功能”，这是错误思路。更合理的做法是先定义最小可运行任务，例如“识别当前地图上是否有森林资源点”。

跑通这个最小任务，再一步步扩展成完整的自动采集智能体。环境越简单，排错越快。

5. 核心流程拆解：从需求到智能体

我建议你把自动采集智能体的开发拆成五个阶段，每个阶段有明确的输入和产出。

5.1 定义采集任务

第一步，明确智能体要完成的目标。对于无尽冬日的日常采集，任务定义大致是：

• 检查是否有空闲采集队伍
• 如果有，寻找附近资源点
• 选择优先级最高的资源点
• 派出采集队
• 监控采集状态
• 采集完成或队伍满后召回

建议把这些规则写成任务描述文档，不要只存在脑子里。后续调试和优化都需要它。

5.2 设计状态感知

状态感知是自动采集智能体的输入来源。你需要定义“当前是什么状态”这件事是程序如何知道的。

状态感知分两类：

• 静态状态：当前地图上有哪些资源点、类型是什么。
• 动态状态：队伍是否空闲、资源剩余量、是否被攻击、是否有弹窗。

在 AI 方案中，这两类状态主要通过截图 + 视觉识别来获取。你需要为每个关键画面准备截图样本，标注可能出现的变体。

5.3 配置决策策略

决策策略是智能体的“大脑”。它决定了在某种状态下，智能体应该采取什么动作。

最简单的策略是规则表：

进阶一点的策略，是让大模型根据当前状态自动生成动作序列。这种做法更灵活，但对模型的稳定性要求更高，建议你先把规则表跑通，再尝试模型决策。

5.4 执行动作队列

决策得出后，要转成具体动作。动作队列是从“想做什么”到“怎么做”的桥梁。

一个典型的动作序列长这样：

序列开始 1. 点击“地图”按钮 2. 等待地图加载完成 3. 点击目标资源点坐标 4. 点击“派出队伍” 5. 选择空闲队伍 6. 点击“出征” 序列结束

每一个动作执行后，都要触发一次感知验证，确认动作真正的效果。这是 AI 智能体比传统脚本稳定得多的根本原因。

5.5 异常兜底与结束条件

自动采集智能体真正难的不是“正常工作”，而是“异常后不会崩”。

你需要为下面这些异常设计兜底逻辑：

• 截图失败或识别置信度低
• 点击后无反应
• 弹窗阻塞操作
• 网络异常
• 智能体连续决策异常

结束条件也很重要：资源采空、背包满、设定时间到、玩家手动接管。这几种场景都要能正常退出循环。

6. 完整示例：一个采集智能体的开发示意

下面用一个简化示例演示清源AI体系下自动采集智能体的大致开发思路。注意：以下代码是演示用途，实际 API 名称和数据结构请以清源AI官方 SDK 文档为准。

6.1 任务定义文件

建议把任务定义从代码中抽离出来，放进独立配置文件，便于后续修改。

{ "task_name": "endless_winter_daily_collect", "targets": [ { "resource_type": "wood", "priority": 1 }, { "resource_type": "stone", "priority": 2 }, { "resource_type": "food", "priority": 3 } ], "max_collect_time": 900, "check_interval": 5, "stop_conditions": [ "all_resources_empty", "manual_override", "bag_full" ] }

配置核心是“采什么、优先级是什么、多久检查一次、什么时候停”。把这个文件独立出来，意味着你可以不修改代码就调整采集策略。

6.2 智能体主循环代码

下面是一个极简化的 Python 代码，展示感知—决策—执行的基本结构。真实项目中，感知和动作执行需要调用清源平台的能力，这里先关注整体结构。

import time class CollectAgent: def __init__(self, config): self.config = config self.running = True def perceive(self): # 调用清源AI视觉识别能力，检测当前画面状态 # 返回结构示例： # { # "screenshot": "...", # "idle_teams": 2, # "resource_points": [ # {"type": "wood", "position": [120, 340], "remaining": 8500} # ], # "popups": [] # } state = qingyuan_sdk.vision_recognize() return state def decide(self, state): # 1. 先处理异常弹窗 if state["popups"]: return [{"action": "close_popup"}] # 2. 没有空闲队伍就等待 if state["idle_teams"] == 0: return [{"action": "wait", "duration": 30}] # 3. 按优先级找第一个可采集资源点 for target in self.config["targets"]: for point in state["resource_points"]: if point["type"] == target["resource_type"]: return [ {"action": "select_point", "position": point["position"]}, {"action": "send_team", "team_index": 0} ] return [{"action": "wait", "duration": 60}] def execute(self, actions): for action in actions: qingyuan_sdk.execute_action(action) time.sleep(1) # 等待动作生效 def run(self): while self.running: state = self.perceive() actions = self.decide(state) self.execute(actions) time.sleep(self.config["check_interval"]) if __name__ == "__main__": config = load_config("config.json") agent = CollectAgent(config) agent.run()

这段代码的核心是perceive -> decide -> execute的循环结构。感知结果是一个结构化数据，决策逻辑基于配置和当前状态，执行动作通过平台能力完成。

6.3 动作执行与日志记录

真实项目中，每个动作都应该有日志，便于排查问题。

LOG_FORMAT = "[{timestamp}] {level} - {message}" def log_action(action, result): message = f"action={action} result={result}" print(LOG_FORMAT.format( timestamp=time.time(), level="INFO", message=message ))

建议记录的信息包括：动作名称、动作参数、执行结果、从感知到决策的完整链路。这类日志是后续排查问题的第一手资料。

6.4 如何判断代码是否跑通

跑通的标准不是“代码不报错”，而是让一次采集流程完整走完：派出队伍、完成采集、队伍返回、资源到账。

建议先手动把游戏调整到“有空闲队伍、地图上有资源点”的状态，再启动智能体，观察它能否完成一轮采集。

7. 运行结果与效果验证

开发完成之后，验证是很关键的一步。这里给出三个层面的验证思路。

7.1 单次任务验证

验证逻辑是否通顺，做单次任务验证即可。

• 准备状态：游戏账号已登录，有至少一个空闲队伍，地图上有资源点。
• 启动方式：启动智能体主循环。
• 预期结果：智能体在 60 秒内识别出资源点并派出采集队。
• 成功标准：游戏内能看到队伍出发动画，截图确认队伍状态变为采集中。

如果失败，第一步先检查感知结果是否正确：智能体是否“看到”了资源点？如果感知层就是错的，后续决策和执行一定错。

7.2 长时间稳定性验证

单次成功不等于能用。自动采集的真实价值在于它能长时间稳定运行，所以至少做一次 30 分钟以上的连续运行验证。

重点观测以下指标：

• 完成了多少轮采集
• 遇到多少次异常弹窗
• 多少次感知识别失败
• 决策是否出现死循环
• 是否出现“卡在某个画面超过 2 分钟”的情况

任何一项异常，都要记录日志并归类原因。

7.3 效果评估指标

完成率和人工干预次数是最核心的两个指标。理想情况下，一次完整采集流程内，人工干预次数应为 0。

8. 常见问题与排查思路

以下是我认为 AI 自动采集开发中最常见的五类问题，整理成表格，方便你按图索骥。

这里再三提醒一下：不管做什么自动化操作，都要注意合规边界。游戏自动化操作可能涉及用户协议，批量操作更是高风险。本文仅讨论 AI 智能体开发技术，请你开发测试时使用自己的测试账号，并遵守游戏平台和清源AI平台的相关规则。

9. 最佳实践与工程建议

把整套流程跑通之后，你会发现，真正决定一个自动采集智能体好不好用的，不是模型多强，而是工程细节是否到位。

9.1 任务设计：从“最小闭环”开始

先做最小闭环，再做完整功能。如果第一版就想着覆盖所有资源点、所有弹窗、所有异常，那么你很可能会在调试中失去耐心。

建议迭代路线：

1. 先把“识别资源点并派出一队采集”跑通。
2. 扩充到“多队伍并行采集”。
3. 再加入“资源优先级”和“自动召回”。
4. 最后处理各种异常弹窗。

一步一个闭环，每个版本都是可运行、可验证的。

9.2 安全与合规边界

这一点必须放在前面。自动采集涉及对玩家操作的模拟，你需要谨慎确认：

• 使用小号和测试账号进行开发。
• 控制自动化频率，避免短时间密集操作。
• 遵守游戏平台和清源AI平台的服务协议。
• 不要把这个程序发布成公开工具供他人不当使用。

AI 开发能力本身是中性的，用在哪里、怎么用，需要开发者自己守住边界。

9.3 日志与监控

生产可用的智能体必须有日志和监控。

• 每个动作都要记录，方便回溯。
• 每个异常都要有独立错误码，方便统计。
• 长时间无状态变化时要有告警。
• 日志要包含截图信息，因为很多问题离开画面很难定位。

建议早期就把日志系统做好，不要等到出了问题再补。

9.4 配置与代码分离

不要动不动就改代码。资源优先级、采集等待时间、弹窗处理方式，都放进配置文件。

这样做的原因很简单：智能体跑在真实环境里，你会频繁调整参数。配置文件可以快速迭代，改代码则容易引入新 Bug。

9.5 从自动采集到更复杂的智能体

最后建议你思考一下迁移能力。自动采集智能体虽然是为游戏开发的，但它背后的“视觉感知—决策规划—动作执行—结果验证”模式，可以直接迁移到其他场景：

• UI 自动化测试中的智能回归测试
• RPA 工具中的智能流程处理
• 外部系统操作中的数据录入与校验
• 开发运维中的任务编排与自动恢复

如果你能在开发自动采集的过程中，把这些通用方法沉淀出来，那这个项目的收获就远不止“做个游戏外挂”这么简单。

10. 总结与后续学习方向

回到开头的问题：为什么自动采集这件事值得用 AI 重做一遍？

因为传统自动化的瓶颈从来都不是“动作执行”，而是“环境理解”和“动态决策”。清源AI这类平台把大模型能力和任务编排做成了开发者可用的服务，自动采集则是检验这套能力的最佳练兵场。它规模适中、逻辑清晰、反馈直接，非常适合用来理解 AI Agent 的完整开发链路。

如果你对这条方向感兴趣，接下来可以着重做三件事：

• 把本文提到的感知—决策—执行框架，用清源AI平台的真实 SDK 完整实现一遍。
• 把自动采集扩展到更复杂的场景，比如多账号统筹、基于地图数据的路线规划、资源收益统计。
• 深入研究视觉识别在小屏游戏界面上的适配问题，提前积累界面样本和模型调优经验。

如果你已经在准备自己的清源AI应用，评论区问卷报名时，建议带上自己的技术方向和实践想法，这样更容易获得匹配的开发者资源和反馈。等到第二版、第三版迭代时，你会感受到前面所有工程细节的回报。

开发智能体最大的乐趣，不是说它完美代替了人手，而是你亲手把一个模糊的“要是能自动就好了”，变成一个能够稳定运行的流程。这个过程，值得每个开发者体验一次。