企业官网建设流程全解析

你是否想过，为什么你的 AI 智能体总是“差那么一点”？它能完成任务，但不够稳定；它能输出结果，但需要人工反复审核；它能运行，但无法融入你的工作流。

答案可能在于：你只构建了一层循环，而优秀的智能体需要四层循环的协同工作。

本文源自 @swyx 的精彩文章《Loopcraft: The Art of Stacking Loops》，我们将深入拆解这四层循环架构，并结合 LangChain 的原生组件，为你展示如何构建一个真正“生产级”的智能体系统。无论你是 AI 应用开发者、技术架构师，还是对智能体工程化感兴趣的读者，这篇文章都将为你提供可落地的架构思路。

文章结构速览：本文将依次介绍智能体循环 → 验证循环 → 事件驱动循环 → 爬山算法循环，最后给出四层关系总结和最佳实践建议。

Loop 工程的艺术

以下是对这种“循环栈”的理解，以及如何利用 LangChain 的原生组件（Primitives）来实现每个层级的架构。

1.环层 1：智能体循环 (Loop 1: The Agent)

从本质上讲，智能体就是一个模型在循环中不断调用工具，直到任务完成。

这就是 LangChain 的 create_agent 所实现的功能。挑一个模型，接入工具，你就得到了一个可以运行的智能体循环。正是"工具"赋予了智能体在现实世界中采取行动的能力。

下面是一个最小可运行的智能体循环示例，使用 LangChain 的create_react_agent实现：

fromlangchain_openaiimportChatOpenAIfromlanggraph.prebuiltimportcreate_react_agentfromlangchain_core.toolsimporttool@tooldefsearch_docs(query:str)->str:"""搜索内部文档库"""returnf"找到与'{query}'相关的文档片段：请参考 docs/guide.md"@tooldefwrite_file(path:str,content:str)->str:"""写入文件到仓库"""withopen(path,"w")asf:f.write(content)returnf"已写入{path}"llm=ChatOpenAI(model="gpt-4o",temperature=0)agent=create_react_agent(llm,[search_docs,write_file])# 运行智能体循环——模型会自动规划、调用工具、直到任务完成result=agent.invoke({"messages":[("human","请搜索'智能体架构'相关文档，并将结果写入 summary.md")]})print(result["messages"][-1].content)

以我们内部的文档智能体为例（我们将在接下来的文章中一直用它作为引导示例）。在第一层循环中，它接收到改进文档的请求，模型开始规划并起草修改内容，然后使用工具去克隆仓库、读取文件、编写文档、发起拉取请求（Pull Request）等。

2.环层 2：验证循环 (Level 2: Verification loop)

智能体循环确实能把工作做完，但它并不总能在第一次尝试时就产出正确或一致的结果。当工作质量的"一致性"至关重要时，通常需要在其外部包裹一层验证循环，用来检查输出并在结果不达标时将反馈送回模型。

验证循环引入了一个评分器（Grader）：它会根据既定的规则评分标准（Rubric）来检查智能体的输出。如果未通过，就会带着反馈意见将结果打回重做。评分器可以是确定性的代码，也可以是基于智能体的（例如经典的"LLM 担任裁判"）。

下面是用 Python 实现验证循环的示例，使用after_agent钩子接入评分逻辑：

fromtypingimportDict,Anyfromlanggraph.graphimportStateGraph,ENDfromtypingimportTypedDict,LiteralclassAgentState(TypedDict):messages:listattempts:intmax_attempts:intdefgrader(state:AgentState)->Literal["rework","accept"]:"""评分器：检查输出是否包含关键信息"""last_msg=state["messages"][-1].content# 确定性评分规则checks=["代码示例"inlast_msg,"配置说明"inlast_msg,len(last_msg)>200,]ifall(checks):return"accept"# 未通过则打回，附带反馈state["messages"].append(("system","输出缺少必要内容，请补充代码示例和配置说明"))return"rework"# 构建带验证循环的图builder=StateGraph(AgentState)builder.add_node("agent",lambdastate:state)# 实际接入 create_react_agentbuilder.add_node("grader",grader)builder.set_entry_point("agent")builder.add_conditional_edges("agent",grader,{"rework":"agent",# 不合格 → 重新执行"accept":END# 合格 → 结束})

RubricMiddleware 组件专门处理这种模式，或者你也可以通过 create_agent 上的 after_agent 钩子（Hook）来实现。

在我们的文档编写智能体示例中，评分器会在每次尝试后运行测试，检查所有链接是否能正常访问、所有 CI（持续集成）检查是否通过，以及代码差异（Diff）是否仅局限于被请求修改的范围。这样一来，无需人工审核就能拦截这类常见错误。

权衡利弊： 引入验证循环会增加单次运行的延迟和成本。但当质量比速度更重要时（这几乎涵盖了绝大多数生产环境的落地场景），这么做是非常值得的。

3.环层 3：事件驱动循环 (Level 3: Event driven loop)

智能体开发中最重要的环节之一是集成层（Integrations Layer）：将你的智能体连接到现有的生态系统中，使其能够在后台自主运行。

事件驱动循环将你的智能体与生态系统紧密相连。一旦某个事件被触发，比如上传了新文档、触发了定时任务、或者接收到了 Webhook（网络钩子），智能体就会开始运行。此时，智能体不再需要你手动去调用，而是作为一个持续运行的组件嵌入在一个更大的系统内。

下面是用 FastAPI + LangGraph 实现事件驱动智能体的示例，支持 Webhook 触发和定时任务：

fromfastapiimportFastAPI,Requestfromlanggraph.checkpoint.memoryimportMemorySaverfromlanggraph.graphimportStateGraphimportasyncio app=FastAPI()agent_graph=None# 接入你的 create_react_agent@app.post("/webhook/docs")asyncdefhandle_docs_request(request:Request):"""Webhook 触发：收到 Slack 消息后启动智能体"""payload=awaitrequest.json()channel=payload.get("channel","#docs-plz")message=payload.get("text","")config={"configurable":{"thread_id":f"docs-{channel}"}}result=agent_graph.invoke({"messages":[("human",f"请处理文档请求：{message}")]},config=config)return{"status":"processing","result":result["messages"][-1].content}@app.on_event("startup")asyncdefstart_cron_agent():"""定时任务：每天凌晨 2 点自动检查文档更新"""asyncdefcron_job():whileTrue:now=asyncio.get_event_loop().time()# 实际项目中用 APScheduler 或 Celery Beatawaitasyncio.sleep(86400)# 每 24 小时agent_graph.invoke({"messages":[("human","检查所有文档是否需要更新")]})asyncio.create_task(cron_job())

LangSmith Deployment 支持这种触发器基础设施，包括对 Cron 定时任务和 Webhook 的支持。其中一个广受欢迎的定时任务应用案例是 openclaw 中的"心跳（Heartbeats）"机制，它能让你的智能体变成一个全天候在线、主动提供帮助的助手。

我们的文档智能体是由我们免代码智能体构建工具 Fleet 驱动的。Fleet 的频道（Channels）和调度表（Schedules）可以完美处理事件驱动和 Cron 风格的触发器。我们设置了一个频道，只要有人在我们的 Slack#docs-plz 频道中发送消息，就会自动触发文档智能体去干活。

4.环层 4：爬山算法循环 (Level 4: Hill climbing loop)

前三个循环实现了工作的自动化，而第四个循环（可以说也是最重要的一个）实现了"优化的自动化"！

智能体的每一次运行都会产生一个追踪记录（Trace）：其中记录了模型做了什么、调用了哪些工具、评分器的反馈等等。这些追踪记录包含了极具价值的信号，能反映出哪些做法有效，哪些无效。爬山算法循环（Hill climbing loop）会安排一个分析智能体去审查这些追踪记录，并利用分析结果来重写和优化外壳框架的配置。优化的内容可以包括提示词/工具的微调，或是评分标准的修改。

下面是一个分析追踪记录并自动优化提示词的实现示例：

fromlangchain_openaiimportChatOpenAIfromlangchain_core.promptsimportPromptTemplate# 1. 收集追踪记录traces=[{"task":"编写 API 文档","tools_used":["search","write"],"score":0.6,"error":"缺少参数说明"},{"task":"编写 API 文档","tools_used":["search","write"],"score":0.7,"error":"格式不符合规范"},{"task":"更新 README","tools_used":["read","write"],"score":0.9,"error":None},]# 2. 分析智能体审查追踪记录analyzer=ChatOpenAI(model="gpt-4o",temperature=0.3)analysis_prompt=PromptTemplate.from_template(""" 分析以下智能体运行追踪记录，找出系统性问题并给出优化建议： 追踪记录： {traces} 请输出： 1. 高频错误模式 2. 建议修改的提示词片段 3. 建议调整的评分标准 """)analysis=analyzer.invoke(analysis_prompt.format(traces=traces))print("分析结果：",analysis.content)# 3. 自动优化——更新智能体的系统提示词defupdate_system_prompt(analysis:str)->str:"""根据分析结果自动重写系统提示词"""if"缺少参数说明"inanalysis:return("你是文档编写智能体。在编写 API 文档时，""必须包含以下部分：\n""- 接口描述\n- 请求参数（含类型、必填、说明）\n""- 响应示例\n- 错误码说明")return"你是文档编写智能体，请按规范输出。"new_prompt=update_system_prompt(analysis.content)print("优化后的系统提示词：",new_prompt)

在 LangChain 中，你可以使用我们专门用于追踪分析的智能体 Engine，来落地这第四层循环。

回到文档智能体的例子：我们让 Engine 审查文档智能体的追踪记录以检测潜在问题。当多个追踪记录都释放出同一个潜在问题的信号时，系统就会自动提交一个 Issue，请求对出错的提示词或工具进行修改。

这里的关键一着在于：返回的箭头不仅仅是循环回顶部，而是直接深入系统内部，更新了智能体循环本身。外层循环的每一次迭代，都会让内层循环变得更加高效。

展望未来：提示词和工具的配置是最容易进行自动改进的，但它们绝非唯一的选择。对于运行开源/权重开放（Open-weight）模型的团队来说，爬山算法循环可以接入强化学习微调（RL Fine-tuning），将追踪记录或评估结果作为训练信号，来直接提升模型本身的能力。诸如记忆（Memory）和检索到的技能（Retrieved skills）等辅助上下文，也可以通过同样的方式进行优化。循环是一种模式，至于具体优化什么，完全取决于你。

上述4层的关系梳理
环层1 和 2：主动调用模式（顺序关系），1产生原始输出，2检查输出质量，反馈修正
环层 3：触发方式变了（不是顺序关系），是一种事件驱动的方式
环层 4：分析前三个循环产生的追踪记录（Trace），反过来优化环层1的配置（提示词、工具、评分标准）