Agent 基础面试：从运行循环讲到 Harness

在大模型应用中，AI Agent（智能体）是以模型为决策核心，围绕任务目标调用工具，并依据执行反馈持续调整行动的软件系统。 核心能力包括目标理解、行动规划、工具使用和反馈调整。

从基本运行过程看，可以用四部分来理解：

Agent = 模型 + 工具集 + 运行循环 + 当前状态

• 模型（Model）：理解目标，结合当前信息选择工具和下一步行动。
• 工具集（Tools）：执行外部操作，例如检索文档、查询数据库或调用业务接口；实际执行由应用程序完成。
• 运行循环（Loop）：组织模型决策、工具执行和结果反馈，持续推进任务，并在任务完成或达到执行限制时停止。
• 当前状态（State）：保存任务目标、对话、工具结果和中间进展，为后续决策提供依据。

例如比较北京和上海的实时温度，模型选择天气工具，应用执行查询并记录结果，运行循环再把结果交回模型进行比较；若缺少其中一地的数据，可根据反馈决定是否补查。

我会围绕一次任务的执行链路，把 Agent 拆成五类职责：

1. 任务入口与会话管理：接收用户目标，建立任务标识，管理必要的输入、取消和进度返回。
2. 上下文与状态管理：组织当前目标、已确认条件、相关历史和知识，保存执行进度及工具结果；长期记忆按需要加入。
3. 模型决策与任务编排：模型判断下一步或生成计划，编排器控制依赖、分支、循环和退出条件。
4. 工具执行与结果反馈：登记工具及参数结构，校验调用与权限，执行 API、检索或文件操作，再把真实结果交回决策循环。
5. 验证、交付与运行保障：检查结果是否满足任务，生成最终回答或文件，并记录错误、耗时和调用轨迹，支持必要的重试与恢复。

主链路是：请求进入 → 组装上下文 → 模型提出动作 → 程序执行 → 写回状态与结果 → 继续决策或交付。最小 Agent 可以从模型、工具、状态和运行循环做起，规划、长期记忆和多 Agent 按业务需要扩展。

Agent Loop 是围绕当前任务状态反复进行决策、执行和反馈的控制过程。每一轮都把任务要求与已有结果交给模型，由模型决定下一步；运行系统执行合法的工具调用，把真实结果写回状态，再判断继续、等待输入还是结束。

一轮通常包括五步：

1. 构建输入：组织任务目标、当前进度、历史消息、相关资料和可用工具。
2. 模型决策：生成工具调用请求、直接回答，或提出需要用户补充的问题。
3. 执行动作：检查工具是否存在、参数和权限是否符合要求，再调用工具。
4. 更新状态：把调用与结果关联起来，记录新事实、进度、错误和资源消耗。
5. 判断下一步：目标未完成则进入下一轮；需要信息或审批则暂停；满足完成条件或触发停止条件时结束。

例如查询某类商品及库存，第一轮先搜索商品，拿到商品 ID 后，下一轮才能查询对应库存，最后结合两次结果回答。循环的作用就在于让下一步依赖前一步的实际反馈，而不是一次性猜出整条路径。

Agent 中的 Harness 是围绕模型搭建的执行系统，负责把模型的判断转成实际操作，再把操作结果反馈给模型。模型主要负责理解任务、推理和选择动作；Harness 负责提供上下文、执行工具、维护状态，并落实权限、预算和验证规则。

可以从四项职责理解它：

1. 准备上下文：组织任务要求、历史消息和相关资料，控制每次调用给模型看什么。
2. 执行动作：提供工具和运行环境，校验调用参数与权限，执行后返回真实结果或错误。
3. 管理过程：维护任务状态，限制循环次数、时间和成本，并按任务需要保存恢复点。
4. 验证与反馈：通过测试、业务规则和执行日志判断结果是否达标，失败时让模型修正或转人工处理。

例如查询两座城市的天气，模型可以决定调用哪个工具、传什么城市；真正发起查询、处理超时、回传温度和检查结果是否齐全的，是 Harness。它的作用是让 Agent 能持续、可控地完成任务，而不只是生成一段看起来合理的回答。

Harness 要把模型的动作建议交给可信的授权与执行层检查，再在受限环境中执行。核心是明确“谁能对什么资源做什么”，并让约束在模型判断错误时仍然生效。

• 身份与最小权限：从认证会话取得用户、租户和授权范围，按任务开放必要工具；每次执行前校验参数、资源归属和业务状态，不能接受模型自行声明的身份或批准标记。
• 执行隔离：文件、命令和网络访问分别设边界。限制可读写目录、进程权限、网络出口和资源预算，子进程也要受相同约束；提示词中的目录要求不能替代实际隔离。
• 按风险处理授权：已获授权且在范围内的操作可以自动执行；超出范围或需要额外确认的动作，先展示具体目标和影响。授权要绑定工具、资源、参数和有效期，拒绝后不能换个工具绕过。
• 数据与记录：网页、文档和工具结果作为不可信数据；凭据留在执行层，返回和日志做必要脱敏。记录允许、拒绝、授权与实际执行结果，并验证越权、注入和重复执行等场景。

例如 Coding Agent 可以在获准工作区内读代码、修改文件并运行测试；读取其他用户文件、访问凭据目录或向新地址上传内容，应由资源与出口策略决定是否允许，不能因模型说“任务需要”就自动放行。

下面以企业研搜助手为参考示例：它把公开网络信息、内部业务数据和私有文档结合起来，回答研究问题，并按需生成 Markdown 或 PDF。后端使用 Python，Agent 主要由 DeepAgents 组织，同时复用 LangChain 和 LangGraph 的基础能力。

• DeepAgents：通过 create_deep_agent 组装主 Agent、三个自定义业务专家和工具。主 Agent 理解任务、选择专家、汇总结果并生成文件；专家分别查询网络、数据库和内部知识库。
• LangChain：统一模型接入和工具接口，把搜索、SQL、知识库等业务函数交给 Agent 调用。
• LangGraph：作为底层运行时承接图状态、流式执行和检查点。项目通过 thread_id 关联会话，当前检查点使用进程内的 InMemorySaver。
• FastAPI：承接任务提交、上传下载和取消接口，后台异步执行 Agent，通过 WebSocket 推送进度和结果。

数据侧，Tavily 提供公开搜索，MySQL 保存结构化业务数据，RAGFlow 提供内部文档问答。选择这套组合，是因为任务需要按信息来源动态委派并交付报告；业务工具、会话目录和前端事件由项目代码接入，通用工具循环与专家委派复用框架。

LangChain 侧重用组件和高层 Agent 架构构建应用，LangGraph 侧重显式控制有状态流程的执行。 两者可以一起使用，不能简单理解为“LangChain 只能顺序执行，LangGraph 才能做 Agent”。

• LangChain 提供模型、消息、工具和检索等集成，以及可通过中间件定制的 Agent 封装，适合快速连接模型与业务能力、构建常见工具调用 Agent。
• LangGraph 是较底层的编排框架与运行时。开发者定义状态、节点及流转规则，组织分支、循环、并行和暂停恢复，适合需要精细控制执行路径与状态生命周期的任务。
• 当前 LangChain 的 Agent 建立在 LangGraph 之上，也能使用持久化、流式输出和人工介入等能力；直接写 LangGraph，主要是为了进一步掌控流程结构，而不是获得前者完全没有的功能。

例如普通知识问答，可以先用模型、检索器和提示词组成清楚的处理流程；标准工具调用助手，可以从 LangChain Agent 开始。若问数系统要显式安排检索、SQL 生成、校验、有限纠错和人工处理分支，直接用 LangGraph 更容易表达这些控制规则，节点里仍可复用 LangChain 组件。

LangGraph 是面向有状态、多步骤任务的编排框架与运行时。它把流程表示成图：State 保存当前数据，Node 读取状态并执行模型、工具或普通代码，Edge 决定下一步，Reducer 定义各字段怎样合并更新。定义后编译成可执行图，运行时推进分支、循环和并行步骤。

它的价值是把任务进度和控制流显式化，并能结合检查点、人工中断、流式输出和子图支持较长流程。比如“分析销量并形成报告”，可以明确哪些条件不足要澄清、哪些资料可以并行获取、哪些结果到齐后才汇总。

优点是流程可控、状态与失败位置较容易定位，适合分支多、需要暂停恢复的任务。代价是要维护状态 Schema、合并与路由规则、检查点及版本兼容；节点重跑时的业务幂等也需要应用处理。简单线性调用未必需要引入这层抽象，LangGraph 也不会自动提高模型判断或工具结果的正确性。