用AI开发AI Agent：MiniMax Code实战GitHub数据查询

AI Agent 正从概念走向落地，但如何让大模型真正“动手”干活，而非停留在聊天层面？一位 B 站 UP 主分享了他的实战：用 MiniMax Code 开发一个能查询 GitHub 仓库数据的 AI Agent。整个过程展示了 AI 编程工具如何串联本地文件、远程服务器和外部服务，完成从需求拆解到代码生成、部署验收的全流程。

工具选型：MiniMax Code 与 Linux 环境

作者选择 MiniMax 作为主力工具，直接原因是套餐折扣（五折）和充足的 token 供给。使用的工具是 MiniMax Code 的 Windows 版本，安装后即可使用。本地环境之外，他还准备了一台 Linux 虚拟机（252.2 版本），并配置了密钥实现免密登录。MiniMax Code 能够自动登录这台远程机器，这为后续的自动化操作打下基础。

关键点在于：MiniMax Code 本地提供了一系列可调用的工具，大模型则负责判断“该调用哪个工具”。作者演示时，AI 自动列出了本地可用的能力，包括读文件、写文件、编辑文件、筛选文件、查找文件，以及对外部执行 MCP 命令、查看网页、创建后台任务等。这种“工具调用 + 模型决策”的组合，让 Agent 区别于写死的脚本——脚本只能执行预设动作，而 Agent 能根据任务自主选择路径。

MCP（Model Context Protocol） 是一种开放协议，旨在标准化大语言模型与外部工具、数据源的连接方式。它由 Anthropic 于 2024 年提出，允许模型以统一接口调用本地或远程的服务，例如文件系统、数据库、API 等。在 AI Agent 的上下文中，MCP 充当了模型与真实世界操作之间的桥梁：模型不再需要针对每个工具编写特定的调用代码，而是通过 MCP 协议动态发现和调用能力。这解释了文中 MiniMax Code 能够“对外部执行 MCP 命令”的含义——它内置了对 MCP 的支持，从而扩展了 Agent 可操作的范围，使其能灵活接入各种外部服务。

Agent 的核心：从 Pass 到主动判断

作者强调，如果模型不能自主判断调用哪个工具，那它本质上就是本地写的一个脚本，只是代替你执行一下。加上判断能力之后，它才能真正称为 Agent。这一观点点出了 Agent 与自动化脚本的分水岭：工具是手脚，模型是大脑。

在演示项目中，Agent 需要连接远程 Linux 服务器，AI 会自动寻找并调用相应工具完成登录。整个过程不需要人工干预，模型根据任务目标决定下一步动作。

Agent 与自动化脚本的本质区别在于自主决策能力。传统脚本由开发者预先编写好每一步操作，只能按照固定流程执行；而 AI Agent 则基于大模型的推理能力，根据当前任务目标和环境状态，动态决定下一步调用哪个工具、传入什么参数。这种“感知-决策-执行”的循环使 Agent 能够处理非结构化、开放式的任务。文中强调“模型是大脑，工具是手脚”，正是突出了模型在工具选择上的自主性。此外，Agent 通常具备记忆机制，能保留对话历史或任务上下文，从而在复杂流程中保持连贯性。这种架构使得 Agent 能够适应变化，而脚本一旦遇到未预设的情况就会失败。

项目设计：用 GPT 拆解任务，生成多 Agent 提示词

演示项目是一个开源 GitHub 仓库的数据查询工具。目标很明确：把 Gate 仓库（GitHub 仓库）中的信息提取出来，存入数据库，然后写一个 Agent 帮用户查询。比如查询某个用户提交了多少代码、在什么时间提交、修改了什么内容，以及哪些人提交次数最多、是主要贡献者。

作者没有直接让 MiniMax Code 硬写代码，而是借助 GPT 来解析任务、生成提示词。他先向 GPT 说明需求，让 GPT 拆解整个项目：从 GitHub 仓库获取完整的历史 Commit、作者、分支、标签、文件变更等，使用 Git 原生命令解析变更，去重后存入数据库；然后 AI Agent 理解自然语言，选择工具汇总结果；最后写一个自然语言聊天界面，供用户追问信息。

GPT 进一步安排了模块化方案：设计独立开发和验收的子 Agent，主 Agent 负责架构、任务分配、代码集成与最终验收，子 Agent 负责具体代码编写。最终产出了一份包含总体架构、数据库设计、采集方案、主 Agent 提示词、七个子 Agent 提示词、主 Agent 调度规范和最终验收标准的文档。

多 Agent 系统指由多个智能体协同完成任务的架构，通常包含一个主 Agent（或协调者）和若干子 Agent。主 Agent 负责分解任务、分配子任务、整合结果和最终验收；子 Agent 则专注于具体子任务，如代码生成、数据采集、测试等。这种分工模拟了人类团队的工作模式，能提升复杂项目的开发效率。多 Agent 系统的关键挑战在于协调：需要清晰的通信协议、任务分配规范和冲突解决机制。文中 GPT 生成的“主 Agent 调度规范”正是为了解决这一问题，确保子 Agent 并行工作时能有序推进，避免重复或遗漏。

关键决策与实现过程

在动手前，作者确认了一个关键问题：是否要把 Redis 中所有历史版本文件的原始内容存入数据库。他询问 GPT 原始内容指什么，并认同代码本身没必要存库，最终采纳 GPT 的建议使用方案 A。随后下载完整提示词，快速浏览确认内容齐全后，发给 MiniMax Code 实施。

MiniMax Code 先阅读文档并列出计划，经作者审核后，直接在 Linux 机器上用 Docker 安装数据库。关于密钥来源，作者把之前配置的 Cloud Code key 发给 AI 直接使用。他还提醒 AI 安装任何工具时使用国内源。从界面可以看到，AI 自动装好了 VCOOL、Python 环境、Node，配置了国内源，GitHub 相关也没有问题。左侧显示起了两个子 Agent 并行工作。

经过几个小时的开发，六个子 Agent 完成了各自任务。作者让 AI 启动服务，进入验证阶段。

国内源（镜像源） 是指位于国内网络环境下的软件包仓库镜像，如清华大学的 TUNA 镜像、阿里云^广告镜像等。由于网络延迟和带宽限制，直接从海外官方源下载依赖（如 Python 包、npm 模块、Docker 镜像）可能非常缓慢甚至失败。将包管理器的源地址替换为国内镜像，可以显著提升下载速度，保障开发环境的顺利搭建。在 AI 自动配置环境时，提醒模型使用国内源是一个实用技巧，能避免因网络问题导致的任务中断。这反映了在实际落地中，除了模型能力，基础设施的本地化配置同样重要。

实践启示：多 Agent 协作与工具生态

这次实战展示了几个值得关注的趋势。第一，AI 编程工具正在从“代码补全”走向“任务执行”，MiniMax Code 的工具调用能力让模型能操作文件系统、执行命令、访问网络。第二，多 Agent 架构开始落地，主 Agent 负责调度和验收，子 Agent 并行开发，这种分工模拟了人类团队的协作模式。第三，提示词工程依然是关键环节，作者用 GPT 生成结构化提示词，再交给执行工具，形成了“规划”与“执行”的分离。

对于想尝试的开发者，作者的路径可以借鉴：先明确任务边界，用擅长规划的模型拆解并生成提示词，再用具备工具调用能力的 AI 编程工具落地，过程中保持人工审核节点，尤其是数据库设计、密钥管理和依赖源配置。

需要留意的是，这类实践对 token 消耗较大，工具套餐的性价比会影响可持续性；多 Agent 并行也带来协调成本，主 Agent 的调度规范是否清晰直接决定最终质量。AI Agent 的门槛在降低，但要跑通完整项目，仍然需要人对架构和关键决策的把控。