1. 从“单次问答”到“持续思考”：Agent循环的本质

如果你用过ChatGPT这类大语言模型，会发现它更像一个“知识渊博但健忘”的专家：你问一句，它答一句，上下文一长就容易跑偏或遗忘前文。这背后是传统LLM的“单次推理”模式。而“Agent循环”要解决的，正是让AI从一个被动的答题器，变成一个能主动思考、规划、执行并自我修正的“智能体”。

简单来说，Agent循环就是给AI装上一个“思考回路”。它让AI不再是一次性输出答案，而是能像人类解决问题一样：先理解目标，再拆解步骤，然后尝试执行，根据结果反馈调整策略，如此循环往复，直到任务完成或无法推进。这个循环的核心，是赋予了AI“行动”和“反思”的能力。无论是让AI帮你自动写一份市场报告，还是控制一个软件完成复杂操作，其底层驱动力都是这个循环机制。

理解Agent循环，是进入当前AI应用开发，特别是自动化与智能体（AI Agent）领域的关键门槛。它不仅是ReAct、LangGraph等流行框架的理论基石，更是区分“玩具Demo”与“可用产品”的核心。接下来，我将结合一线开发中的实战经验，为你彻底拆解Agent循环的原理、实现中的魔鬼细节，以及如何避开那些新手必踩的坑。

2. Agent循环的核心架构与工作流拆解

一个典型的Agent循环，可以抽象为一个经典的“感知-思考-行动”循环，但在工程实现上，它有更具体的组成部分。我们通常将其分解为几个核心模块，它们协同工作，构成了智能体的“大脑”和“手脚”。

2.1 核心组件：智能体的“器官”与功能

一个功能完整的Agent通常包含以下四个核心组件，它们共同构成了循环的骨架：

1. 规划器（Planner） ：这是循环的“指挥官”。它的职责是将用户模糊的、高层的指令（如“帮我分析一下上季度的销售数据”），分解成一系列具体的、可执行的子任务或步骤。规划器通常由LLM驱动，利用其强大的理解和推理能力。例如，它可能会输出这样的计划： [1. 连接到数据库，2. 查询Q3销售数据表，3. 计算环比增长率，4. 生成可视化图表，5. 撰写分析摘要] 。

2. 工具集（Tools） ：这是智能体的“双手”和“工具箱”。LLM本身无法直接操作世界，它需要工具来执行具体动作。工具可以是任何可调用的函数或API，比如：执行Python代码、调用搜索引擎、读写文件、操作数据库、控制鼠标键盘等。每个工具都有明确的名称、描述和参数规范，以便LLM理解何时以及如何调用它。

3. 执行器（Executor） ：这是循环的“执行单元”。它负责接收规划器给出的当前步骤，从工具集中选择合适的工具，并按照LLM生成的正确参数格式来调用该工具。调用后，执行器会收集工具的返回结果（可能是数据、成功状态或错误信息），并将这个结果作为“观察”反馈给系统。

4. 反思器（Reflector） ：这是智能体的“复盘系统”，也是高级Agent区别于简单自动化脚本的关键。反思器会评估当前步骤的执行结果和整体进度。它判断：任务是否已完成？当前结果是否符合预期？是否遇到了错误？是否需要调整后续计划？基于这些判断，它决定循环是继续、终止还是回到上一步重试。反思同样由LLM驱动，它让Agent具备了从错误中学习和动态调整策略的能力。

这四个组件通过一个核心的工作流引擎串联起来，就形成了我们所说的“循环”。

2.2 工作流引擎：驱动循环的“心脏”

工作流引擎是协调所有组件的调度中心。最经典、最直观的模式莫过于 ReAct（Reason + Act）框架 。它的循环流程可以清晰地用以下步骤描述：

1. 思考（Think） ：Agent根据当前的目标、已有的历史步骤和上一步的观察结果，进行“思考”。LLM会分析现状，并决定下一步应该做什么。它的输出通常是一个结构化的文本，包含“思考过程”和“行动决定”。例如：“用户需要销售分析报告。我已经完成了数据查询，现在需要计算增长率。我应该调用‘计算增长率’工具，参数是查询到的数据。”

2. 行动（Act） ：基于上一步的“行动决定”，工作流引擎从工具集中找到对应的工具，并格式化成正确的调用指令（如一个JSON对象），然后交给执行器去运行。

3. 观察（Observe） ：执行器运行工具，并将运行结果（成功的数据或失败的错误信息）返回给工作流引擎。这个结果就是本次循环的“观察”。

4. 循环判断 ：工作流引擎将本次的“思考”、“行动”、“观察”作为一个完整的步骤记录到历史中。然后，它将当前状态（目标+完整历史）提交给反思器。反思器判断任务状态：

   • 如果任务完成 ：循环终止，输出最终结果。
   • 如果遇到错误或需要调整 ：反思器可能会建议修改后续计划，甚至回溯到之前的某一步重试。
   • 如果仍需继续 ：流程回到第1步“思考”，开始下一个循环。

这个 Think -> Act -> Observe -> Loop 的过程，就是Agent循环最本质的体现。它让AI具备了持续与环境（通过工具）交互并逐步推进任务的能力。

注意 ：在实际开发中，为了节省成本和提高响应速度，“思考”和“反思”有时会合并或简化。例如，让LLM在一次调用中同时输出“下一步行动”和“是否继续”的判断。但这并不改变其底层循环逻辑。

3. 循环中的关键技术细节与实现难点

理解了宏观架构，我们深入到代码和配置层面。实现一个稳定可靠的Agent循环，以下几个技术细节是成败的关键。

3.1 提示工程：为LLM绘制“思考地图”

LLM在循环中扮演“大脑”角色，但它需要极其明确的指令才能正确工作。这就是提示工程的核心。一个用于Agent循环的提示词（Prompt）通常包含以下几个部分：

• 系统角色设定 ：明确告诉LLM它现在是一个“任务执行专家”，必须遵循严格的输出格式。
• 可用工具描述 ：以清晰的结构列出所有工具的名称、功能描述、输入参数格式和示例。这是LLM学习使用“工具箱”的说明书。
• 输出格式约束 ：这是强制性的。必须要求LLM以指定的格式（如JSON、XML或特定的文本标记）来输出它的“思考”和“行动决定”。例如，要求它必须输出 {"thought": "...", "action": {"name": "tool_name", "args": {...}}} 。没有这个约束，LLM的自由发挥会让程序无法解析。
• 当前任务与历史上下文 ：将用户目标和之前所有步骤的 (Thought, Action, Observation) 三元组历史，作为上下文提供给LLM。这相当于它的“短期工作记忆”。
• 停止条件 ：明确告诉LLM，当它认为任务已经完成时，应该输出一个特定的结束标记（如 {"action": "FINISH", "args": {"result": "最终总结..."}} ）。

实操心得 ：工具描述要尽可能精确、无歧义。避免使用“处理数据”这种模糊描述，而要用“计算列表数据的平均值，输入是一个数字列表，输出是一个浮点数”。同时，历史上下文会随着循环越来越长，需要警惕LLM的上下文长度限制。高级做法是引入“记忆摘要”机制，定期将冗长的历史压缩成一段精炼的摘要，再喂给LLM。

3.2 工具的设计与封装：稳定性的基石

工具是Agent与真实世界交互的桥梁，它的设计直接决定Agent能力的上限和稳定性。

• 原子性与幂等性 ：工具功能应该尽可能“原子化”，即只做好一件小事。例如，“查询数据库”是一个工具，“格式化查询结果”应该是另一个工具。这降低了单个工具的复杂度，也让LLM更容易理解和调用。同时，工具应尽量设计为“幂等”的，即多次调用同一参数的工具，产生的结果应该相同，这有利于错误重试。
• 严格的输入输出校验 ：在工具函数内部，必须对输入参数进行类型、范围、有效性校验。LLM生成的参数可能有格式错误或逻辑错误。一个健壮的工具应该在内部处理好这些边缘情况，返回明确的错误信息，而不是直接崩溃。
• 结构化输出 ：工具应返回结构化的数据（如字典、列表），而不是大段的自然文本。结构化数据更容易被后续的工具或LLM解析和处理。例如，一个搜索工具返回 [{"title": "...", "url": "...", "snippet": "..."}, ...] 远比返回一整段HTML文本要友好。

避坑指南 ：新手最容易犯的错误是让工具直接执行高风险操作（如 rm -rf / 或删除数据库）。必须在工具层或执行器层设计“安全沙箱”和“权限控制”。例如，对文件操作工具限制路径范围，对代码执行工具使用容器隔离。

3.3 状态管理与循环控制：避免“鬼打墙”

Agent陷入无限循环或重复执行无效步骤，是开发中最常见的问题之一。这需要通过精细的状态管理和循环控制逻辑来解决。

• 循环终止条件 ：必须设置多种“保险丝”。

  1. 最大循环次数 ：硬性限制，如最多循环20次，防止死循环。
  2. 超时控制 ：整个任务或单个步骤的最长执行时间。
  3. 明确完成信号 ：依赖LLM（反思器）输出的“任务完成”判断。
  4. 目标达成检测 ：可以编写一个独立的“目标校验”工具或函数，定期检查当前结果是否已满足任务要求。

• 历史上下文窗口管理 ：随着循环进行，历史记录会越来越长。你需要一个策略来决定保留哪些历史。常见策略有：

  • 完整保留 ：适用于短任务。
  • 滑动窗口 ：只保留最近N步的历史。
  • 摘要压缩 ：定期用另一个LLM调用，将长历史压缩成一段摘要，然后用“摘要+最近几步细节”作为新上下文。这是平衡记忆与成本的关键技术。

• 错误处理与重试机制 ：当工具调用失败或LLM输出不符合格式时，不能直接让Agent崩溃。

  1. 格式错误 ：解析失败时，可以将错误信息连同原问题重新提交给LLM，要求它纠正输出格式。
  2. 工具执行错误 ：将工具返回的错误信息（如“数据库连接失败”）作为“观察”反馈给LLM，让它决定是重试、换一种方式还是报错停止。
  3. 有限重试 ：对特定错误（如网络超时）设置自动重试，但重试次数不宜过多（通常2-3次）。

4. 主流框架下的循环实现实战

理论说再多，不如看代码。下面我们以两个主流框架为例，看看循环是如何具体实现的。这里不会罗列全部代码，而是聚焦在体现循环核心的代码片段上。

4.1 基于LangChain的ReAct Agent实现

LangChain的 AgentExecutor 本质上封装了一个ReAct循环。其核心逻辑如下：

from langchain.agents import initialize_agent, AgentType
from langchain.llms import OpenAI
from langchain.tools import Tool

# 1. 定义工具
def search_api(query):
    # 模拟搜索工具
    return f"关于'{query}'的搜索结果..."
search_tool = Tool(name="Search", func=search_api, description="用于搜索信息的工具")

# 2. 初始化Agent（这里选择了REACT_DOCSTYLE，即一种ReAct变体）
llm = OpenAI(temperature=0)
agent = initialize_agent(
    tools=[search_tool],
    llm=llm,
    agent=AgentType.REACT_DOCSTYLE, # 使用ReAct风格的Agent
    verbose=True # 打开verbose，可以看到内部循环的思考过程
)

# 3. 运行循环
result = agent.run("请搜索一下LangChain的最新版本，并告诉我主要更新内容。")

当你设置 verbose=True 运行时，会在控制台看到类似以下的输出，这正是内部循环的痕迹：

> Entering new AgentExecutor chain...
我需要找到LangChain的最新版本信息。我应该使用搜索工具。
Action: Search
Action Input: "LangChain latest version release notes"
Observation: 关于'LangChain latest version release notes'的搜索结果... 版本0.0.200，主要更新包括...
根据搜索结果，我知道了最新版本是0.0.200，更新内容包括...
我现在可以给出答案了。
Final Answer: LangChain的最新版本是0.0.200，主要更新了...
> Finished chain.

这个 Action -> Observation -> Thought -> ... -> Final Answer 的链条，就是LangChain帮你管理的ReAct循环。 AgentExecutor 内部帮你处理了提示模板组装、LLM调用、工具分发、历史记录等所有繁琐工作。

4.2 基于LangGraph构建更复杂的循环工作流

当任务需要非线性的流程（如循环、分支、并行）时，LangChain的简单Agent可能不够用。这时，LangGraph就派上用场了。它允许你用图（Graph）的方式来定义工作流，节点是函数（工具或LLM调用），边是逻辑流转。

下面是一个简化版的、具有自我反思和重试能力的Agent循环图：

from langgraph.graph import StateGraph, END
from typing import TypedDict, Annotated
from langchain_core.messages import HumanMessage
import operator

# 定义状态结构，用于在节点间传递信息
class AgentState(TypedDict):
    task: str
    plan: list
    history: Annotated[list, operator.add] # 关键：这是一个累加器，自动追加历史
    current_step: int
    result: str

# 定义节点函数
def planner_node(state: AgentState):
    """规划器节点：拆解任务"""
    # 调用LLM生成计划...
    new_plan = ["步骤1：搜索", "步骤2：分析", "步骤3：总结"]
    return {"plan": new_plan, "current_step": 0}

def actor_node(state: AgentState):
    """执行器节点：执行当前步骤"""
    step = state["plan"][state["current_step"]]
    # 调用LLM决定使用什么工具和参数...
    action = "Search"
    action_input = "查询内容"
    # 模拟工具调用
    observation = f"执行 {action} 得到结果。"
    # 将本次（思考、行动、观察）记录到历史
    history_entry = f"Step {state['current_step']}: Thought: 需要{step}; Action: {action}({action_input}); Observation: {observation}"
    return {"history": [history_entry], "current_step": state["current_step"] + 1}

def reflector_node(state: AgentState):
    """反思器节点：检查是否继续"""
    # 基于当前历史和结果，调用LLM判断
    # 模拟判断：如果执行了3步，就结束
    if state["current_step"] >= len(state["plan"]):
        return {"result": "任务完成", "next": END}
    else:
        return {"next": "actor"} # 继续执行下一个步骤

# 构建图
workflow = StateGraph(AgentState)
workflow.add_node("planner", planner_node)
workflow.add_node("actor", actor_node)
workflow.add_node("reflector", reflector_node)

# 设置边
workflow.set_entry_point("planner")
workflow.add_edge("planner", "actor")
workflow.add_edge("actor", "reflector")
# 反射器决定下一个节点是`actor`还是`END`
workflow.add_conditional_edges(
    "reflector",
    lambda x: x["next"], # 根据reflector返回的`next`值决定流向
    {"actor": "actor", END: END}
)

# 编译并运行图
app = workflow.compile()
initial_state = {"task": "分析某个主题", "history": [], "plan": [], "current_step": 0, "result": ""}
final_state = app.invoke(initial_state)

在这个图中， planner -> actor -> reflector 形成了一个环。 reflector 根据条件决定是让流程回到 actor 继续下一步，还是流向 END 结束。这就是一个用图清晰定义的、可自定义的Agent循环。你可以轻松地在图中添加处理错误的分支、支持并行执行多个工具等复杂逻辑。

5. 开发中的典型问题与调试心法

即使理解了原理，在实际开发中你依然会遇到各种光怪陆离的问题。下面是我从多个项目中总结出的常见“病症”及其“药方”。

5.1 常见问题排查清单

问题现象	可能原因	排查步骤与解决方案
Agent陷入死循环	1. 反思逻辑有缺陷，无法正确判断终止条件。 2. 工具执行结果始终无法满足目标检测条件。 3. 历史上下文混乱，导致LLM做出错误决策。	1. 检查反思提示词 ：确保明确给出了“任务完成”的判断标准。可以要求LLM在输出中必须包含“任务是否完成”的布尔判断。 2. 添加硬性限制 ：务必设置 max_iterations （最大循环次数，如15次）。 3. 打开Verbose日志 ：一步步查看LLM的“思考”和“行动”，找到循环点。 4. 简化任务 ：用一个极简的、必能成功的任务测试，看循环是否能正常结束，以排除工具和规划的问题。
LLM不调用工具，一直说废话	1. 工具描述不清晰，LLM不理解何时该用。 2. 系统提示词未强调“必须使用工具”。 3. LLM温度（temperature）设置过高，导致输出不稳定。	1. 优化工具描述 ：使用“If you need to X, then use tool Y”的句式。为每个工具提供1-2个清晰的调用示例。 2. 强化系统指令 ：在提示词开头用强语气写明“你 必须 使用提供的工具来完成任务。禁止凭空想象答案。” 3. 降低温度 ：将LLM的 temperature 参数设为0或0.1，以获得更确定、更遵循指令的输出。
工具调用参数格式错误	1. LLM输出的JSON或参数格式与预期不符。 2. 工具函数本身对输入校验不严。	1. 使用Pydantic模型 ：在LangChain中，用 StructuredTool 或 @tool 装饰器定义工具时，使用Pydantic模型来严格定义输入参数的类型和结构，LLM会更好地遵循。 2. 在提示词中提供更严格的示例 ：在Few-Shot示例中，给出完美的参数调用范例。 3. 添加后处理解析 ：在执行器调用工具前，添加一个“参数解析与清洗”的步骤，尝试修正一些常见的格式错误（如多余的引号、缺少的括号）。
历史上下文过长，导致性能下降或LLM失忆	循环步骤多，每次都将全部历史传入，很快触及LLM上下文窗口上限。	1. 启用摘要 ：使用LangChain的 ConversationSummaryBufferMemory 或类似机制，将旧的历史对话总结成一段短文。 2. 滑动窗口 ：只保留最近5-10步的详细历史，更早的步骤丢弃或仅保留关键结果。 3. 向量检索记忆 ：将历史步骤存储在向量数据库中，每次只检索与当前步骤最相关的几条历史，这是处理超长任务的高级方案。
多步骤任务中，后续步骤忘记最初目标	历史中充满了中间步骤的细节，冲淡了核心目标。	1. 目标置顶 ：在每次调用LLM的提示词中，都将 原始用户任务 放在最前面或一个醒目的位置（如 ## 核心任务：XXX ）。 2. 定期重申目标 ：在规划器或反思器的提示词中，明确要求LLM回顾原始目标，检查当前进展是否偏离。

5.2 调试心法：像侦探一样观察你的Agent

调试Agent不同于调试普通代码，因为核心决策者（LLM）是一个“黑盒”。我的方法是 结构化日志记录与复盘分析 。

1. 开启最详细的日志 ：无论用什么框架，第一步就是打开所有 verbose 或 debug 输出。你会看到每一次LLM调用的输入（Prompt）和输出（Completion），以及工具调用的入参和结果。这是所有调试信息的源头。

2. 为每个循环步骤打上“快照” ：在关键节点（如调用LLM前、调用工具后）记录完整的系统状态。包括：当前任务、完整历史、可用工具列表、上一步结果等。将这些快照保存下来（可以存为JSON文件）。

3. 复盘失败轨迹 ：当Agent失败或行为异常时，不要只看最后一步。把整个循环的“快照”从头到尾看一遍。问题往往出在中间某一步：可能是规划器拆解错了，可能是某次工具调用返回了误导性信息，也可能是反思器做了一个错误的判断。顺着时间线，你就能像侦探破案一样找到“第一现场”。

4. 构建最小可复现案例 ：当你怀疑是某个工具或某段提示词的问题时，不要在原项目中硬调试。新建一个最简单的脚本，只包含那个有问题的组件，用最直接的输入去测试它。这能帮你快速隔离问题。

5. 成本与延迟监控 ：Agent循环意味着多次调用LLM和工具。务必在开发早期就加入简单的计数和计时逻辑，监控平均完成一个任务需要多少次LLM调用、多少次工具调用、总耗时多少。这能帮你发现效率瓶颈（比如某个工具特别慢）和成本黑洞（比如反思逻辑过于复杂导致调用翻倍）。

6. 性能优化与进阶模式

当一个基础循环能跑通后，下一步就是让它跑得更快、更稳、更聪明。这里分享几个进阶的优化思路。

6.1 降低延迟与成本：循环的“提速”与“省钱”之道

LLM调用是循环中最耗时的部分。优化方向有两个：减少调用次数和降低每次调用的成本/耗时。

• 减少不必要的LLM调用 ：

  • 缓存（Caching） ：对于具有确定性的子任务（如“将用户输入翻译成英文”），如果输入相同，输出必然相同。可以为LLM调用结果建立缓存，避免重复计算。LangChain等框架内置了缓存支持。
  • 简化反思逻辑 ：不是每一步都需要深刻的“反思”。对于简单的、线性的任务，可以设定每执行N步才进行一次正式的反思评估，中间步骤默认继续。
  • 预测性规划 ：在任务开始时，让规划器一次性生成一个更详细的、包含多个步骤的列表，并明确步骤间的依赖关系。这样，在一些步骤可以并行执行，或者某些步骤不需要LLM介入（直接按计划执行工具）时，就能减少LLM的调用。

• 选择更经济的模型 ：并非所有步骤都需要GPT-4级别的“大脑”。可以采用模型路由策略：让一个速度快、成本低的小模型（如GPT-3.5-Turbo、Claude Haiku）负责常规的规划和工具调用，只在需要复杂推理、反思或最终总结时，才调用更强大也更贵的模型（如GPT-4、Claude Sonnet）。这被称为“分层模型策略”。

6.2 引入长期记忆与知识库

基础循环只有“短期工作记忆”（当前会话的历史）。要让Agent真正“聪明”起来，需要给它配备“长期记忆”。

• 向量数据库作为记忆体 ：将Agent执行任务过程中的关键决策、学到的事实、产生的最终结果，以文本片段的形式存入向量数据库（如Chroma、Pinecone）。当下次遇到类似任务时，可以先从向量库中检索相关记忆，作为上下文提供给LLM。这能让Agent“记住”过去做过什么，避免重复劳动，也能基于历史经验做出更好决策。
• 技能库（Skill Library） ：将成功解决过某类问题的完整“规划-执行”序列，封装成一个可复用的“技能”。当遇到相似的新任务时，Agent可以直接调用或适配这个技能，而不是从头开始规划。这极大地提升了效率。

6.3 多智能体协作：从“单线程”到“工作组”

对于极其复杂的任务，可以引入多个具有不同专长的Agent，让它们协同工作。这就是多智能体系统。

• 角色分工 ：例如，一个项目可以包含：一个“项目经理”Agent负责拆解任务和协调；一个“研究员”Agent负责搜索和信息收集；一个“程序员”Agent负责写代码；一个“评审员”Agent负责检查质量。每个Agent都有自己的循环。
• 通信机制 ：Agent之间需要通过一个“共享工作区”或“消息总线”来通信。例如，研究员将找到的资料放到共享区，程序员从中获取所需信息。这通常需要更上层的工作流框架（如CrewAI、AutoGen）来协调。
• 竞争与辩论 ：对于开放性问题，可以设计多个持不同观点的Agent进行“辩论”，最终由一个“裁判”Agent综合各方意见得出结论。这种方式能有效减少单一LLM的偏见和幻觉。

实现多智能体协作，本质上是将单个Agent循环封装成一个模块，然后在更高层级上设计这些模块之间的交互图。这带来了强大的能力，但也显著增加了系统的复杂性和调试难度，建议在单智能体应用非常稳定后再考虑。

7. 安全性与可靠性设计考量

让一个自主循环的AI帮你做事，兴奋之余必须警惕风险。安全性设计不是可选项，而是必选项。

• 工具执行的沙箱化 ：任何执行代码、访问文件系统、操作数据库的工具，都必须在严格的沙箱环境中运行。使用Docker容器、虚拟机或安全的子进程来隔离，并限制其资源（CPU、内存、网络、文件系统权限）。绝对禁止Agent拥有直接执行任意Shell命令的高权限工具。
• 用户确认与审批环 ：对于高风险操作（如发送邮件、支付、删除数据），不要完全自动化。设计“人工审批”环节，让Agent在执行前将操作详情提交给用户确认。这可以是一个简单的“是/否”提示，集成在聊天界面中。
• 输入输出过滤与监控 ：对用户输入和Agent的输出进行监控和过滤，防止提示词注入攻击（用户输入恶意指令操纵Agent）或Agent输出有害内容。可以部署一个轻量级的审查模型或规则引擎进行实时检查。
• 可解释性与审计日志 ：Agent的每一步操作、每一次LLM思考、每一个工具调用及其结果，都必须完整、不可篡改地记录下来。这不仅是调试的需要，更是事后审计、追溯责任、改进系统的唯一依据。确保日志包含时间戳、会话ID、用户ID等全链路信息。

Agent循环原理是将静态的LLM转化为动态智能体的魔法。它通过规划、执行、观察、反思的闭环，让AI具备了解决复杂问题的初步能力。从简单的ReAct模式到基于图的工作流，从单智能体到多智能体协作，其核心思想一以贯之： 让AI学会“自己动手，边做边想” 。

掌握它，你就能开发出真正理解意图、自主完成任务的下一代AI应用。但请始终记住，能力越大，责任越大。在赋予AI循环能力的同时，用牢靠的工程实践为它套上缰绳，是每一位开发者必须完成的功课。