AutoGPT 社区挑战提交指南：从任务定义到 PR 合并的完整流程

本文基于 AutoGPT 仓库的官方提交文档 submit.md，完整讲社区挑战（Challenge）的提交流程：挑战文档的存放位置与分类、文件命名规范、基于 challenge_template.md 的四个必填章节，以及提交后的社区评审机制。读完本篇，你能够把一个发现到的 AutoGPT 能力短板，规范化地转化为一份可被社区采纳、可被后续 Agent 复现评测的挑战文档。

什么是 AutoGPT 的挑战（Challenge）

在理解提交流程之前，需要先明确挑战的定义。根据 introduction.md 的说明：

• 定义：挑战是 AutoGPT 目前难以解决或尚未完成的任务或问题，可能包括改进特定功能、增强模型在特定领域的理解，甚至是当前版本所缺失的新特性；
• 价值：解决这些挑战直接提升 AutoGPT 的性能、可用性与通用性，同时也让社区能够以贡献者的身份深度参与项目演进；
• 两种参与方式：一是 Submit a Challenge（本文主题）——提交你发现的 AutoGPT 尚不能完成的任务；二是 Beat a Challenge——对已有挑战贡献解决方案，其操作指引见 beat.md。

挑战体系的最终目的是沉淀出一套可复现的评测资产：仓库中 classic/direct_benchmark/challenges/ 目录按 abilities、alignment、library、verticals 等子目录组织了实际的挑战代码与测试数据，说明挑战文档并不只是说明文字，而是会与基准测试工程配套存在。

提交流程总览

官方文档给出的标准流程为四步：

1. 在 AutoGPT 仓库的 challenges 目录下新建 .md 文件，并选择正确的类别；
2. 用描述性的标题命名文件，单词之间用连字符（hyphen）而非空格，例如 improve-context-understanding.md；
3. 在文件内严格遵循 challenge_template.md 的结构，描述问题、界定范围、定义成功标准；
4. 提交文件（Commit）并创建 Pull Request（PR）。

提交后，社区会评审和讨论该挑战；若被认为合适（deemed appropriate），它将被加入 挑战列表。下面逐步展开。

第一步：在 challenges 目录创建文档并选择类别

官方要求把挑战 .md 文件创建在仓库的 challenges 目录中。对应当前仓库的实际布局，挑战文档集中位于 docs/content/challenges/，其下已经按主题划分了类别子目录：

• docs/content/challenges/memory/：记忆类挑战，测试 Agent 在一系列任务中记住并利用信息的能力，典型形式是跟随文本文件中的指令并全程保持对关键数据（如 task ID）的追踪；
• docs/content/challenges/information_retrieval/：信息检索类挑战，评估 Agent 从大量来源中搜索、提取并呈现相关信息的能力，涵盖解析用户查询、浏览网页、过滤非结构化数据等任务。

“选对类别”（pick the right category）是文档中明确强调的要点：类别决定了挑战在 list.md 中的归属位置，也决定了后续挑战作者去哪个目录查找同类参考实现。如果你的挑战不属于现有类别，可以参考 building_challenges.md 中的做法——该文档指出，在创建测试挑战时，“若不存在对应类别，可以新建一个”（If no category exists you can create a new one）。

第二步：按命名规范命名文件

命名规则有两点硬性要求：

• 文件名必须是挑战标题的描述性翻译，让读者不看正文即可大致理解挑战内容；
• 单词之间使用连字符而非空格，例如 improve-context-understanding.md。

这种 kebab-case 命名与 Git 提交信息、URL 友好性等社区惯例一致，也便于在 PR 评审和列表页中快速检索。可以对照现有文件命名，如 memory/challenge_a.md、information_retrieval/challenge_a.md，均以简洁可排序的方式标识了同一类别下的多个挑战。

第三步：遵循模板撰写挑战内容

这是流程中最核心的一步。challenge_template.md 定义了挑战文档必须包含的四个章节，提交者需要完整继承这一骨架：

1. Description（描述）

清晰、简洁地描述挑战本身，并附上能说明问题的示例或文件。这是评审者判断“是否合适”的首要依据，描述越具体，后续挑战作者复现问题时的成本越低。

2. Input（输入）

如果挑战涉及特定输入文件，需要在此说明文件名与内容，并用三反引号（```）代码块格式化内容。模板给出的示例展示了输入文件可能带有“噪声”：

instructions_1.txt

The current task_id is 4563.
[NOISE intended to confuse the agent]
Read the file instructions_2.txt using the read_file command.

值得注意的是模板特意保留了 [NOISE intended to confuse the agent] 这样的干扰行——这说明挑战文档本身就需要明确标注哪些输入是真实指令、哪些是用于考验 Agent 鲁棒性的噪声。已有的 Memory Challenge A 即采用了这种多文件串联的输入设计：Agent 从 instructions_1.txt 开始逐层读取后续指令文件，最终把 task_id 写入 output.txt。

3. Scope（范围）

界定挑战的边界，包括所有相关的约束、要求与限制。明确 scope 的价值在于：它把“AutoGPT 做不好某件事”这个模糊反馈，收窄为一个有明确边界的可验证命题，避免评审和后续解题工作发散。

4. Success Evaluation（成功评估）

解释成功如何被度量。这一章直接决定了挑战是否可“被攻克”——参照 memory/challenge_a.md 的写法，成功标准被精确表述为“Agent 若把 task_id 写入了输出文件，即视为成功”。从源码结构看，这一标准随后会被翻译成 classic/direct_benchmark/challenges/ 下的自动化测试断言，因此撰写时就应当以“能被断言检验”为标准来表述成功条件。

第四步：Commit 并创建 Pull Request

文档撰写完成后，提交文件并通过 PR 提交到仓库，走正常的开源协作评审流程。这里需要强调适用前提：提交挑战是对 AutoGPT 仓库的贡献行为，需要你自己拥有可写权限的 fork 与 PR 权限，且提交的目标位置以仓库维护者合入时的实际目录结构为准（当前仓库中挑战文档位于 docs/content/challenges/）。

提交之后：评审、入列与被攻克

流程文档明确了提交后的两条后续路径：

1. 社区评审：社区成员会 review 并讨论该挑战，若被认为合适，将加入 挑战列表；
2. 等待被攻克：对列表中的挑战，解题者按 beat.md 的指引开始工作——选择挑战、彻底理解问题与范围、开发并提交解决方案。

从 building_challenges.md 可以进一步看到挑战文档与工程实现之间的关系：挑战并不绑定特定框架，其行为模式是“扮演一个希望完成某件事的用户”——输入为用户诉求加文件等其它输入，输出为工件（文件、图像、代码等）。挑战作者还会在集成测试中定义 Agent fixture（如示例中的 kubernetes_agent，通过 CommandRegistry 装配 file_operations、app 命令集与 AIProfile），并用 pytest 驱动交互循环、断言输出工件内容。也就是说，一份被采纳的挑战文档，最终会沿着“文档 → 列表页 → 自动化测试”的链路演化为可重复运行的基准用例。

此外，introduction.md 中有一条重要提示：项目正在逐步向 agbenchmark 迁移。agbenchmark 提供了更简化的改进 AutoGPT 的方式，直接运行 agbenchmark 命令即可开始攻克挑战。因此提交挑战时，应关注仓库当前主推的评测入口，文档中的挑战定义（Description / Input / Scope / Success Evaluation）依然是通用的问题描述骨架，只是评测执行层可能落在 agbenchmark 体系而非旧的测试框架上。

提交前自查清单

综合上述文档，提交一份新挑战前可对照以下清单：

检查项	依据
文件位于 challenges 目录且类别正确	submit.md 第 1 步
文件名 kebab-case、标题有描述性	submit.md 第 2 步
Description / Input / Scope / Success Evaluation 四章齐全	challenge_template.md
输入文件以代码块完整给出，噪声与指令区分清晰	模板 Input 章节示例
成功标准可被客观断言（如文件内容、关键字段）	memory/challenge_a.md 的成功判定写法
已了解 agbenchmark 迁移方向，避免重复建设	introduction.md 的 warning 提示

按照这份流程提交，你的挑战就具备了进入 挑战列表、并被社区后续攻克（Beat a Challenge）的完整条件。