予枫个人主页 个人专栏: 《Java 从入门到起飞》《读研码农的干货日常》《Java 面试刷题指南》 Debug 这个世界Return 更好的自己过去几年“AI Agent”几乎成了一个被反复使用、也被反复误解的词。有人说Agent 就是一个会调用工具的大模型有人说Agent 是能够自主完成任务的系统也有人认为只要在 Prompt 里写了 ReAct 格式让模型按“思考—行动—观察”循环执行就可以叫 Agent。这些说法都没有错但都不够工程化。如果只是说“Agent 能自主工作”这个定义太宽泛无法指导系统设计如果只是说“Agent 会用工具”这个定义又太窄无法解释今天产品级 Agent 里那些复杂的权限、状态、沙箱、验证和调度机制。我更倾向于从架构演进的角度理解 AgentAgent 不是某一个单点能力而是一套围绕 LLM 构建起来的持续执行系统。它的核心不是“大模型会不会思考”而是系统如何让模型在正确的上下文中做决策用安全的方式调用工具在可控的循环里持续推进任务并在合适的时候停止。1. 第一阶段LLM Loop让模型从“回答”变成“执行”最早一批 Agent 原型给了我们一个非常重要的启发只要把 LLM 放进循环里它就不再只是一个问答模型而开始具备持续执行任务的形态。以 BabyAGI 为代表它的结构非常简单whileTrue:tasktask_queue.dequeue()resultllm.execute(task)new_tasksllm.create(result)task_queue.add(new_tasks)这套结构没有复杂工具也没有权限控制更没有持久化状态。它只有三个核心组件一个任务队列一个 LLM 执行器一个 LLM 任务生成器。但它证明了一件事LLM Loop 一个可以持续推进任务的系统。这是 Agent 的第一层工程定义Agent LLM LoopLoop 很关键。没有 LoopLLM 只是一次性响应用户输入有了 LoopLLM 才能在完成当前任务后继续判断下一步该做什么。但这种早期架构也非常脆弱。它容易无限循环缺少验证机制错误会在循环中不断放大。也就是说它有了“自主性”的雏形但还没有“可控性”。2. 第二阶段LLM Tools Loop让 Agent 真正拥有“手”接下来LangChain Agent 将早期粗糙的循环封装成了更标准的“推理—行动—观察”结构。典型流程是用户输入 ↓ LLM 推理下一步 ↓ 选择工具并执行 ↓ 观察工具返回结果 ↓ 继续推理 ↓ 直到输出最终答案这一阶段最重要的变化是 Agent 开始拥有工具调用能力。也就是说模型不再只是“生成文本”而是可以通过 Tool 接口访问外部系统例如搜索资料查询数据库调用 API执行代码操作文件发送请求这时Agent 的定义变成了Agent LLM Tools Loop Stop Conditions这里多了两个关键点。第一是Tools。工具让 Agent 从“会说”变成“会做”。如果没有工具模型再聪明也只能停留在文本层面有了工具模型才能真正改变外部世界。第二是Stop Conditions。停止条件让 Agent 从“无限循环的实验品”变成“可运行的工程系统”。比如最大迭代次数、最大执行时间、提前停止策略等都是为了防止 Agent 在错误路径上无限消耗资源。但这个阶段的 Agent 仍然有明显限制它大多是一次会话里的线性循环状态能力弱崩溃后难以恢复执行过程也不容易被人工干预。这意味着它可以做 Demo可以做原型但距离稳定生产系统还有距离。3. 第三阶段Stateful Graph让 Agent 变得可控、可恢复LangGraph 的出现解决的是线性 AgentExecutor 的核心问题如果 Agent 的执行过程不可中断、不可回放、不可恢复那么它就很难用于复杂任务。线性循环的问题在于开始 → 推理 → 工具调用 → 观察 → 推理 → 工具调用 → 结束这个过程一旦开始外部很难介入。一旦中途失败状态也很容易丢失。LangGraph 的思路是不要把 Agent 看成一个简单的 while 循环而要把它看成一个有状态执行图。输入 ↓ [推理节点] → [工具调用节点] → [验证节点] ↑ ↓ └────── 重试决策节点 ↓ [人工介入节点] ↓ 输出这带来了几个重要能力第一执行结构从线性循环变成有向图。Agent 可以分支、重试、并行也可以根据不同结果进入不同路径。第二状态可以持久化。通过 CheckpointAgent 即使中途失败也可以从断点恢复而不是从头再来。第三人工可以介入。在关键节点上人可以检查、批准、修改或终止任务这让 Agent 更适合真实业务场景。第四调试能力增强。当执行过程可以回放问题就不再是黑盒而是可以定位到具体节点。这一阶段的 Agent 定义可以进一步升级为Agent (LLM Tools) × Stateful Execution Graph HITL Checkpoint也就是Agent 不只是一个会循环调用工具的模型而是一个可观测、可控制、可恢复的执行系统。但这仍然主要解决的是“执行流程”的问题还没有完全解决“执行环境”的问题。例如工具调用是否有权限边界代码执行是否在沙箱中上下文如何压缩和组织每一步输出如何验证敏感操作是否需要审批失败后如何进行审计这些问题引出了下一层架构Harness。4. 第四阶段Harness让 Agent 从“能跑”变成“能安全地跑”如果说前几个阶段关注的是 Agent 如何执行任务那么 Harness 关注的是Agent 在什么环境里执行任务。一个非常有价值的定义是Agent Model Harness也就是说如果你不是模型本身你就是 Harness 的一部分。Harness 包括什么它几乎包括包裹在模型外部的一切工程设施系统提示词工具注册表权限控制沙箱环境上下文管理验证机制钩子脚本子代理编排日志与可观测性这也是为什么同一个模型在不同 Agent 产品中的表现可能差异巨大。很多时候真正拉开差距的不是模型本身而是 Harness 的设计。一个好的 Harness 会回答这些问题模型能看到什么 模型能调用什么 模型不能做什么 工具执行在哪里发生 输出如何验证 失败后如何回滚 敏感操作如何审批 整个过程如何审计因此这一阶段的 Agent 定义可以写成Agent LLM Harness进一步展开Agent LLM 工具 权限 上下文 验证 钩子 沙箱这一步非常关键。因为它让 Agent 不再是“裸奔的推理机器”而是一个有边界、有规则、有保护层的系统。对于生产环境来说Agent 的问题从来不只是“能不能完成任务”还包括是否安全是否可控是否可审计是否可恢复是否能在错误发生时限制损失这也是我认为很多 Agent Demo 和真实 Agent 产品之间最大的差距。Demo 关注“模型能不能做成一件事”。产品关注“模型在复杂环境里能不能稳定、安全、可控地持续做事”。5. 第五阶段Loop Engineering让 Agent 真正具备持续自主性即使有了强大的 Harness仍然有一个问题没有解决谁来启动下一次运行如果每次都需要用户手动输入系统本质上仍然是“被动响应”。它可以很强但还不够自主。Loop Engineering 关注的是 Harness 之上的一层Harness 负责让 Agent 安全执行 Loop Engineering 负责让 Agent 持续运转。这一层会引入更多系统级组件例如Automations定时或事件触发Worktrees隔离多个 Agent 的执行空间Skills将项目知识沉淀成可复用能力Plugins / Connectors连接工单系统、数据库、Slack、GitHub 等外部系统Sub-agents区分执行者和检查者Memory跨会话保存状态这时的 Agent 已经不只是“用户问一句它答一句”。它可以定时检查任务主动发现工作分派子任务在隔离环境中执行调用外部系统保存长期状态自我验证结果在满足条件时停止因此完整的工程定义可以写成Agent (LLM Harness) Loop进一步展开Agent LLM 工具 权限 上下文 验证 钩子 沙箱 调度 工作发现 持久化状态 子代理 自验证 停止条件这才更接近今天产品级 Agent 的形态。6. 一个更完整的工程定义把前面的几层合起来我会这样定义 AI AgentAI Agent 是一个在固定循环中运行的智能执行系统。它使用 LLM 进行推理和决策通过 Harness 提供工具、权限、上下文、验证和沙箱环境来执行动作并通过 Loop 层实现调度、状态持久化、任务发现、自我验证和停止控制。用公式表达Agent LLM(Reasoning) H(T, P, C, V, S) L(A, W, M, Sub, Stop)其中T Tools工具注册表与工具 Schema P Permissions权限系统与审批边界 C Context上下文管理与压缩 V Verification验证信号、测试与检查 S Sandbox隔离执行环境 A Automations调度与事件触发 W Worktrees并行隔离执行空间 M Memory跨会话状态持久化 Sub Sub-agents子代理与 Maker/Checker 分离 Stop Stop Conditions停止条件与收敛判断这个定义的好处是它不是抽象概念而是可以直接指导系统设计。当我们评估一个 Agent 系统时可以逐项拆解它有没有工具 工具有没有 Schema 有没有权限边界 上下文是否可控 执行是否在沙箱里 结果是否经过验证 失败后能不能恢复 能不能跨会话记忆 能不能自动触发 什么时候停止如果这些问题回答不清楚那么这个系统可能只是一个“会调用工具的聊天机器人”还不能算完整意义上的产品级 Agent。7. 为什么这个视角更适合工程实践过去关于 Agent 的讨论经常陷入几个抽象争论LLM 到底会不会规划Agent 是否真的自主ReAct 是否等于 AgentTool Calling 是否足够多 Agent 是否一定更强这些问题当然重要但如果从工程视角看会更清晰。LLM 提供的是推理和决策能力。Harness 提供的是执行环境和安全边界。Loop 提供的是持续运行和自主调度能力。三者缺一不可。没有 LLM系统没有智能决策能力。 没有 HarnessAgent 就是不安全的裸奔系统。 没有 LoopAgent 就只是等待用户启动的工具。所以一个成熟的 Agent 不应该只看模型能力也不应该只看是否支持工具调用而应该看整体系统设计。真正有价值的问题不是这个 Agent 用了什么模型而是这个 Agent 的 Harness 怎么设计 它的权限边界在哪里 它如何管理上下文 它如何验证结果 它如何恢复失败 它的 Loop 如何触发 它什么时候停止这些问题才决定 Agent 能不能从 Demo 走向生产。8. 对开发者的启发如果我要设计一个 Agent 系统我不会一开始就追求“多智能体”“完全自主”或“复杂规划”。我会优先搭好四个基础层第一明确工具边界。每个工具都要有清晰的 name、description、args_schema 和返回结构。模型不应该猜工具怎么用而应该在明确接口中做选择。第二建立权限系统。读操作、写操作、危险操作要分级。涉及外部副作用的操作例如发邮件、提交代码、删除数据、支付订单必须有审批或回滚机制。第三加入验证闭环。Agent 的输出不能只靠模型自信。代码要跑测试数据要校验文档要检查格式关键结论要有来源。第四设计停止条件。一个 Agent 是否可靠很大程度取决于它是否知道什么时候停。没有停止条件的 Agent最终会变成资源黑洞。在这些基础上再逐步增加状态持久化、调度触发、子代理协作和长期记忆。也就是说Agent 的建设路线不应该是先追求自主再补安全而应该是先建立边界再扩大自主性这是我认为 Agent 工程化最重要的一条原则。结语Agent 的本质是“带边界的自主执行系统”回过头看Agent 的演化其实是一层一层补全能力的过程LLM Loop能持续执行 LLM Tools Loop能调用外部能力 Stateful Graph可控、可恢复 Harness安全、有边界、可审计 Loop Engineering可调度、可持续、自主运行所以Agent 不是一个 Prompt 技巧也不是一个简单的 Tool Calling Demo。它是一套围绕 LLM 构建的工程系统。如果用一句话总结Agent 用 LLM 做决策用 Harness 管边界用 Loop 给系统生命力。一个没有 Harness 的 Agent是裸奔的推理机器。一个没有 Loop 的 Agent是等待人按启动键的工具。只有同时具备推理能力、执行边界和持续循环能力的系统才更接近真正意义上的 AI Agent。参考来源Yohei Nakajima, “BabyAGI”, GitHub, March 2023Harrison Chase, LangChain Agent / LangGraph, 2023-2025Addy Osmani, “Agent Harness Engineering”, addyosmani.com, April 19, 2026Addy Osmani, “Loop Engineering”, addyosmani.com, June 7, 2026Anthropic, “Effective Harnesses for Long-Running Agents”, anthropic.com, November 26, 2025Viv Trivedy, “Anatomy of an Agent Harness”, 2026