Agent

什么是 Loop Engineering Loop Engineering 是 2026 年上半年在 AI Agent 圈子里逐渐流行的说法。它的核心思路是：与其由人逐步编写 Prompt、检查结果、再发出下一条指令，不如先设计一个自动循环系统，明确目标、检查方式和停止条件，让 Agent 按照「感知 → 行动 → 观察 → 再决策」的过程反复迭代，直到任务达到可验证的完成状态。 每个 Agent 本质上都运行在某种循环中。Loop Engineering 关注的是有意识地设计这个循环，包括：Agent 每轮能看到什么、可以执行什么操作、如何取得反馈、谁负责判断完成，以及什么情况下必须停止。 这个模式可以追溯到 ReAct（Reason + Act）范式：模型推理后采取行动，再根据环境返回的观察结果继续推理。Loop Engineering 将这种「推理—行动—观察—重复」的过程扩展为可控制、可验收的工程流程。 与 Prompt Engineering 的区别 维度 Prompt Engineering Loop Engineering 人的工作 编写当前这一步的指令 设计目标、反馈、验证和停止条件 执行方式 通常是一次或少量交互 自动进行多轮迭代 完成判断 人或执行任务的模型临场判断 预先定义的检查器或验收条件 适用场景 问答、生成单个结果、短任务 自动代码生成、软件维护、多步骤自主任务 两者不是替代关系。清晰的 Prompt 仍然是循环中每一步的输入；Loop Engineering 解决的是如何让这些步骤持续运行，并在正确的时机停下来。 一个循环需要哪些部分 一个可用的 Loop 通常包含以下要素： 目标：最终需要达到的状态，而不只是要执行的动作。 行动范围：Agent 可以读取、修改和执行哪些内容。 反馈：测试、构建、CI、部署状态或其他环境输出。 完成条件：可以重复执行并得到明确结果的验收检查。 状态：跨轮次保存的需求、进度、失败摘要和已完成事项。 停止条件：成功、达到最大轮次、超时或遇到不可恢复错误。 完成条件应尽量由测试退出码、构建结果、文件状态等客观信号表达，而不是让 Agent 根据自己的回答判断「应该已经完成」。这也是 Harness Engineering 能为 Loop 提供的关键能力：Loop 决定继续还是停止，Harness 提供可重复的验收信号。 ...

这套 skills 是什么 Matt Pocock（Total TypeScript / aihero.dev 作者）公开了一套面向 AI 编码的 Agent Skills 集合，本质是一组 SKILL.md 文件，把「从想法到上线」的工程流程拆成若干可被 Agent 按需加载的步骤。它不是某个 IDE 插件，而是一批可以装进 Claude Code（或其他支持 skill 的 harness）的流程说明。 装好之后目录大致是这样：~/.claude/skills/ 下一批软链接指向实际的 skill 仓库；setup-matt-pocock-skills 是每个仓库跑一次的前置配置（约定 issue tracker、triage 标签、文档布局）；ask-matt 是一个路由 skill，用来在记不清该用哪个流程时反查。 主流水线：idea → ship 大部分工作走这一条线： grill-with-docs：用连续追问把模糊的想法逼清楚，过程沉淀进 CONTEXT.md 和 ADR。没有工作目录时用 grill-me（无状态版）。 如果有些问题必须靠能跑的代码才能回答（状态、业务逻辑、要看的 UI），绕道 prototype 写一份一次性代码，用 handoff 在会话之间传递结论。 多会话构建：to-spec 把对话变成 spec，to-tickets 拆成一批 tracer-bullet ticket，每个声明自己的阻塞边；然后逐个 implement，ticket 之间清空上下文。单会话能做完就直接 implement。 implement 内部驱动 tdd（一次一个红-绿切片），收尾跑 code-review（Standards + Spec 两轴审查）再提交。 匝道和支线：bug 和请求堆积走 triage；线上出问题走 diagnosing-bugs（坚持先有一个已经变红的命令再谈修复）；大到一个会话装不下的模糊工程走 wayfinder（先画决策地图，产出决策而非交付物，再汇入 to-spec）。 ...

从 Prompt 到 Graph AI 驱动开发大致走过几条主线：Prompt Engineering 解决「怎么说清楚」；Context Engineering（含 RAG）解决「给模型看什么」；Loop Engineering 解决「让 Agent 自我修正」——给一个任务，改代码、跑测试，失败了再继续修。 复杂业务里，单 Agent 的 Prompt Loop 很快会顶到天花板。Graph Engineering（图工程）把流程拆成有向图：节点专职分工，边负责确定性控制流，AI 只承担局部推理与代码生成。下面按「为什么需要 → 怎么划职责 → 怎么落地」写一版可落地的骨架。 不想额外起 Python 主控、只在 Claude Code 里管多阶段任务时，见 Graph Engineering：纯 Claude Code 实现。 为什么需要 Graph Engineering Loop Engineering 在「单任务、短轮次」时很好用。一旦任务变长、角色变多，常见会撞上三类问题。 上下文污染（Context Pollution） 循环次数上去后，会话里堆满历史报错、半成品 diff、无效尝试。模型要在噪声里找有效信号，表现会越来越差：重复改同一处、忽略刚写过的约束、或「修 A 弄坏 B」。根因往往不是模型突然变笨，而是上下文被污染了。 缺乏确定性控制（Nondeterminism） 若下一步完全由 LLM 在 Context 里自行决定，容易陷入死循环：同一失败路径反复尝试，或越改越散。控制流（何时重试、何时换策略、何时中止）若也交给模型，系统就缺少可预期的停机条件。 职责模糊 让同一个 Agent 同时做架构规划、写前后端、跑单测、做 Code Review，等于把多种能力边界揉进一次长会话。结果常常是：规划被实现细节冲淡，实现被 review 口径扯偏，测试结论又被前序噪声干扰。 Graph Engineering 的应对方式很直接：用有向图把复杂流程解耦为专职节点（Nodes）；把控制流交还给确定性的代码（Edges）；只把局部推理与代码生成交给 AI。 Graph Engineering 在说什么 可以把它看成三层分工： ...

这篇写什么 Graph Engineering 的完整落地通常是：Python + LangGraph 当指挥官，Claude Code 当执行者，pytest 一类命令当 quality gate。有时不想额外起一个 Python 主控进程，只想在 Claude Code 里把一段有依赖关系的多阶段任务当图来管。 本文只写这条路径：控制流、节点隔离、跨节点状态都尽量落在 Claude Code 自带能力或手工骨架上，不接 LangGraph。图工程「为什么需要」以及三层分工的完整论述见母文；这里默认读者已经接受「用有向图拆专职节点、把控制流从 Prompt 里抽出来」这一目标。 能落地到两种深度，选哪种取决于要不要付节点隔离和显式状态的成本。 轻量方案：任务队列当 DAG DAG（Directed Acyclic Graph，有向无环图）说的是：节点之间有方向（A 依赖完成后才能做 B），但不能成环（不能出现 A → B → A，否则永远等不到起点）。任务列表里的「阻塞 / 被阻塞」关系正好就是这种结构——依赖边把阶段串成可调度的顺序，而不是随便挑一个未完成任务开干。 Claude Code 自带的任务系统（创建 / 更新 / 列出任务）可以把每个阶段建成一个节点，用「阻塞 / 被阻塞」关系显式建边，状态走 pending → in_progress → completed；某个节点的依赖没完成前，它不会出现在「可执行」列表里，相当于用依赖门控替代了「下一步该做什么」的临时判断。 执行仍然发生在同一个会话、同一段上下文里：Agent 顺着依赖关系挑下一个已解锁的节点，直接实现，完成后回写状态，再挑下一个。没有节点隔离，也没有单独的图执行器在跑——图的推进是模型手动读状态、手动调用更新接口完成的，不是由代码在每一步自动求值条件边。跨节点的「状态」也不是一个结构化的 state 对象，只是任务列表里的标题 / 描述 / 状态字段，加上还留在同一段对话历史里的实现细节。 适合依赖关系不复杂、能在一次会话内跑完、不需要严格隔离上下文的多阶段任务——比如按一份规格文档的实现顺序逐节点推进。 示意如下： Claude Code 单会话 +------------------------------------------+ | Task list (DAG) | | A ──► B ──► C | | pending / in_progress / completed | +------------------------------------------+ | | 同一对话上下文里依次执行 v 实现 → 回写任务状态 → 挑下一个已解锁节点 重量方案：子代理 + 独立工作树 + 显式状态文件 如果需要的是真正的节点隔离，通常要在 Claude Code 里手工搭三件东西： ...

什么是 LangGraph LangGraph 是 LangChain 生态系统中的一个框架，专门用于构建有状态的、多步骤的 AI 应用程序。它通过图（Graph）的方式来定义和管理复杂的 AI 工作流，让开发者能够创建具有循环、条件分支和持久化状态的智能体系统。 LangGraph 的核心理念是将 AI 应用程序建模为状态机，其中节点代表操作步骤，边代表流程控制，状态在节点之间传递和更新。 核心概念 State（状态） State 是在整个工作流中传递和更新的数据结构。通常使用 TypedDict 定义： from typing import TypedDict, Annotated from langgraph.graph import add_messages class AgentState(TypedDict): messages: Annotated[list, add_messages] user_input: str analysis_result: str Node（节点） Node 是执行具体操作的函数，接收当前状态并返回更新后的状态： def research_node(state: AgentState): # 执行研究任务 result = do_research(state['user_input']) return { "analysis_result": result, "messages": [("assistant", f"研究完成：{result}")] } Edge（边） Edge 定义节点之间的连接关系： Normal Edge（普通边）：直接连接两个节点 Conditional Edge（条件边）：根据状态决定下一个节点 from langgraph.graph import StateGraph, END # 普通边 workflow.add_edge("node_a", "node_b") # 条件边 def should_continue(state): if state['done']: return END return "continue_node" workflow.add_conditional_edges( "decision_node", should_continue ) Graph（图） Graph 是完整的工作流定义，包含所有节点、边和状态管理： from langgraph.graph import StateGraph workflow = StateGraph(AgentState) # 添加节点 workflow.add_node("research", research_node) workflow.add_node("analyze", analyze_node) workflow.add_node("respond", respond_node) # 定义边 workflow.add_edge("research", "analyze") workflow.add_edge("analyze", "respond") # 设置入口点 workflow.set_entry_point("research") # 编译图 app = workflow.compile() 核心特性 1. 状态持久化 LangGraph 支持状态的持久化存储，可以实现： ...

Hand Off 是什么 VS Code Copilot Chat 在 Agent 模式下提供 “Hand off a session to another agent” 功能，将当前对话的完整上下文移交给另一个 agent 继续处理。 移交时，接收方 agent 会获得： 完整的对话历史记录 已收集的文件上下文 前一个 agent 的中间结论和工具输出 接收方 agent 可以直接从当前状态继续，而不需要从头重建上下文。 与普通切换 Agent 的区别 普通切换 Hand off 上下文 丢失，重新开始 完整传递 用途 新任务 同一任务的延续 历史记录 不带过去 带上全部历史 为什么要切换 Agent，而不是在主 Agent 里继续？ Fan-out 并行（最核心的理由） 主 agent 收集完上下文后，同时把同一份上下文发给多个子 agent 做不同的事： 主 agent 分析完代码库 ├── 子 agent A → 写单元测试 ├── 子 agent B → 写文档 └── 子 agent C → 做安全审查 主 agent 是单线程的，无法并行处理多个子任务。Fan-out 到多个子 agent 是最强的切换理由。 ...

什么是 CrewAI CrewAI 是一个开源的 Python 框架，专门用于构建和管理多智能体（Multi-Agent）系统。它允许开发者创建一个由多个 AI 智能体组成的"团队"（Crew），这些智能体可以协同工作，共同完成复杂的任务。 核心概念 Agent（智能体） Agent 是 CrewAI 中的基本执行单元，代表一个具有特定角色和能力的 AI 助手。每个 Agent 具有： Role（角色）：定义 Agent 的身份和职责 Goal（目标）：Agent 要达成的目标 Backstory（背景故事）：为 Agent 提供上下文和个性 Tools（工具）：Agent 可以使用的工具集合 from crewai import Agent researcher = Agent( role='研究员', goal='收集和分析相关信息', backstory='你是一位经验丰富的研究专家，擅长从各种来源收集准确信息', tools=[search_tool, scrape_tool], verbose=True ) Task（任务） Task 定义了需要完成的具体工作，包括： Description（描述）：任务的详细说明 Agent：负责执行该任务的智能体 Expected Output（期望输出）：任务完成后的预期结果 from crewai import Task research_task = Task( description='研究 AI 领域的最新发展趋势', agent=researcher, expected_output='一份包含最新 AI 趋势的详细报告' ) Crew（团队） Crew 是多个 Agent 和 Task 的组合，负责协调整个工作流程： from crewai import Crew, Process crew = Crew( agents=[researcher, writer, reviewer], tasks=[research_task, write_task, review_task], process=Process.sequential # 顺序执行 ) result = crew.kickoff() 执行流程 CrewAI 支持两种执行流程： ...