营销号口中的“AI 革命三件套”已经把不少人绕晕了。今天不聊颠覆不聊趋势只回答三个工程问题Harness 到底是什么Agent 到底怎么定义AgentLoop 到底在循环什么。最近你只要点开任何科技内容平台大概率会刷到这样的标题“Agent 即将取代全栈工程师”“Harness 是下一代 AI 工程的核心”“AgentLoop 让 AI 自主写代码”。评论区经常吵成一团因为大家发现这些文章里 Harness、Agent、AgentLoop 好像被当成同义词在用今天叫“Agent 框架”明天叫“Harness 工程”后天又冒出来一个“AgentLoop 范式”。对于正在写业务代码、做后端、或者刚刚开始接触 LLM 应用开发的工程师来说最大的困惑不是“这些概念有没有价值”而是更直接的三个问题它们分别是什么彼此之间是什么关系我要是想动手写一个带 AI 的工程化项目到底应该先学哪一个这篇文章不准备讲抽象的商业故事而是想用工程视角把这三个词彻底拆开。我会从词源开始讲清楚各自的定义、解决的问题、以及它们在真实项目里的对应物然后手写一个最小可运行的 Agent 示例让你亲眼看到 Harness、Agent、AgentLoop 在代码里到底长什么样。读完你应该能判断哪些营销号文章是在吹概念哪些设计真正值得借鉴以及你自己的项目现在到底缺的是哪一个环节。先说一个明确判断方便你后面带着框架去读Harness 是“运行环境”Agent 是“程序主体”AgentLoop 是“执行循环”。三者不是竞争关系而是在不同技术层面上协作。理解了这一点你再看任何相关文章基本都不会被带偏。1. 为什么突然都在说 Harness、Agent、AgentLoop过去两年LLM 应用经历了两次明显的重心转移。第一次是 Prompt Engineering大家研究的核心问题是“怎么把提示词写得更好”目标是让模型说出更准确的回答。第二次就是现在正在发生的 Agent 化研究核心变成了“怎么让模型在一个受控环境里连续完成多步任务”目标不再是说一句话而是把一件事从头到尾做完。但“让模型做事”和“让模型对话”有一个本质区别对话只需要一次请求响应做事则需要把模型放进一个持续运行的上下文里给它工具、给它记忆、给它反馈并在一轮结果不理想时让它继续重试。这里就催生了一个工程需求你需要一个能承载这些能力的运行时系统。不同团队给这个运行时起了不同名字有的叫它 Agent Framework有的叫它 Harness有的叫它 Execution Loop。营销号很快发现了这个信息差于是开始混着用最终把所有和 Agent 相关的东西都堆在一起制造出一种“新概念爆炸”的感觉。如果你去看 OpenAI Codex 的工程实现或者社区里基于 DeepSeek 模型搭建的各种开源 Agent 项目你会发现它们内部一定有一个循环模型推理 - 决定调用工具 - 执行工具 - 把结果反馈给模型 - 模型继续推理。这个循环被 OpenAI 官方称为 Agent Loop而在很多自研框架里承载这个循环以及工具、上下文、模型连接的那一层被称为 Harness。Agent 则是这个系统里的“脑子”它表现为一次次的模型推理决策。所以你现在看到的三个热词并不是三个并列的新事物而是同一个 Agent 应用里三个不同的零件。下面我们逐个拆开讲。2. Harness从“马具”到 AI 开发者的“脚手架”2.1 Harness 这个词到底是什么意思Harness 在英文里的原意是马具也就是连接马匹和马车的那套挽具。后来工程领域引入了这个词最著名的用法是 test harness中文常翻译成测试夹具或测试框架。测试开发中你写了一批测试用例还需要一套能够自动准备测试数据、启动被测系统、收集测试结果的东西这套东西就是 harness。它本身不负责“做什么”只负责“让被测试的东西能在预定环境里被跑起来”。到了大模型应用时代Harness 的词义继续延伸。现在一个 LLM Harness 指的是一套能让大模型在受控环境中执行任务的运行时系统。它通常包含模型接口、工具注册表、上下文管理、权限控制、执行循环、日志与可观测性等组件。换句话说模型只是流水线上的“操作员”而 Harness 是整条流水线传送带、工位、工具箱、安全围栏都属于它。2.2 什么是 Agent Harness当 Harness 前面加上 Agent 三个字含义就更具体了。Agent Harness 就是专门为了支撑智能体任务设计的运行时框架它提供的核心能力有四个工具调用让模型在推理时声明“我要调用某个函数”框架负责把函数真正执行并把结果送回模型上下文。多轮状态管理任务往往是多步的Harness 需要维护用户目标、中间结果、历史行为让模型不会“失忆”。循环控制模型可能需要反复尝试Harness 需要定义循环结束的条件比如任务完成、步骤超限、模型主动放弃。安全与权限边界模型不能无限调用任意函数Harness 需要限制模型可以访问的工具、资源和个人数据。你可以这样理解模型本身只是一个能生成文本的概率系统。要让它在业务系统里真正做事你必须给模型穿上一整套“外骨骼”而这个外骨骼就是 Agent Harness。社区里已经有不少基于 DeepSeek、OpenAI、Claude 模型构建的 Harness 类项目比如有人把 Codex 的终端编码智能体能力重新封装成适用于其他模型的 harness也有人专门为 DeepSeek 模型开发了带工具调用、文件读写、命令行执行能力的开源 harness。这些项目的共同特点是它们不是模型而是模型的“运行时脚手架”。2.3 Harness 和普通 API 调用的区别很多初学者会问我直接用 SDK 调用一次 Chat Completion和用 Harness到底有什么区别区别非常大。普通 API 调用是一种“请求响应”模式。你发一条消息模型回一段文字整个交互就结束了。即使你把历史消息拼在一起发过去也只是把多轮对话变成一次长请求模型并没有真正的“自主行动能力”。Harness 则是一个常驻的执行系统。它会在一次任务里完成以下重复动作把当前状态整理给模型 - 模型决定要调用哪个工具 - Harness 执行工具 - 把工具结果整理给模型 - 模型根据结果再做下一步决策。这个过程不是一次性的 API 请求而是一个持续到任务结束的循环。这也是为什么你会频繁看到 AgentLoop 这个热词它描述的就是这个循环本身。为了更直观我用一张表对比传统调用和 Harness 的差异维度传统 API 调用Agent Harness交互模式请求 - 响应感知 - 决策 - 行动 - 观察循环执行上下文手动拼接消息框架维护状态和记忆工具完全由代码控制模型可动态选择工具结束条件一次响应结束任务完成或达到停止条件出错处理重试请求把错误信息反馈给模型继续迭代代码位置业务代码里的一行调用一套独立的运行时系统3. Agent不只是“会对话”而是“能办事”3.1 Agent 的准确定义Agent 这个词在 AI 领域已经存在几十年但在大模型时代它的含义被重新定义了。一个 LLM Agent 通常指以大语言模型为决策核心能够感知环境、制定行动计划、调用外部工具、并根据执行结果调整后续行为的智能体程序。很多人把 Agent 和 Chatbot 搞混这是最容易踩的误区。Chatbot 的核心目标是对话无论你是问问题、聊天还是让它写文案它都在做语言生成。Agent 的核心目标是完成任务对话只是它与用户交互的一种形式甚至很多时候用户根本不和它对话而是分配一个后台任务让它自己去执行。举个例子一个代码辅助 Agent 收到任务“把项目里所有过期的依赖升级到最新版本”它可能先读取依赖清单然后逐个检查新版本再修改配置、运行测试、查看测试结果、修复报错最后提交代码。整个过程里Chatbot 式的“一问一答”很难完成这件事因为任务需要它持续地做决策而不是生成一段建议文本。3.2 Agent 的核心四要素一个真正称得上 Agent 的系统至少应该具备四个要素感知能力。Agent 需要知道自己当前处在什么状态。对代码 Agent 来说感知就是读取文件、执行命令、查看报错对客服 Agent 来说感知就是读取用户诉求、查询订单信息、获取商品库存。决策能力。这是大模型发挥作用的地方。Agent 根据当前感知到的信息推理下一步应该做什么。决策不只是“回答什么”还包括“调用哪个工具”、“是否继续”、“是否需要询问用户”。行动能力。Agent 必须能对外部世界产生影响。这可能表现为调用业务 API、操作数据库、修改文件、发送邮件、执行命令。如果只有决策没有行动它顶多是一个建议引擎。反馈吸收能力。行动之后Agent 必须把结果带回到自己的上下文中作为下一轮决策的输入。比如工具调用失败了Agent 需要读取错误信息并尝试另一个方案。没有这一步Agent 就变成了“只做一次动作就结束”的脚本。3.3 为什么 Agent 这么难做营销号把 Agent 讲得像“装上就能用”但真正做过 Agent 的人都会遇到几个棘手问题。第一个是工具调用的稳定性。模型可能会生成无效的 JSON 参数、给出不存在的函数名、或者在没有必要的时候强行调用工具。这要求 Harness 层做大量的校验、回退和格式化处理。第二个是上下文管理。模型每轮推理都会消耗上下文窗口任务执行越久历史信息越多最终要么超长要么关键信息被淹没。工程上通常需要摘要、裁剪、结构化记忆等手段。第三个是错误不可控。Agent 执行真实任务时外部 API 可能超时、数据库可能连接失败、代码可能编译不过。Agent 需要能理解这些错误并决定是重试、换方案还是放弃。第四个是成本和安全。Agent 一旦循环起来Token 消耗会成倍增加同时工具权限如果过大可能造成数据破坏或非法操作。所以在生产环境里一定要有权限最小化、预算上限、人工审批等机制。这些难点本质上都不是 Agent 模型本身的问题而是承载 Agent 运行的 Harness 层需要解决的问题。这也是为什么近一年“Harness Engineering”会成为 AI 工程领域的重要方向。4. AgentLoopAgent 的核心运转机制4.1 什么是 AgentLoopAgentLoop 直译过来就是“智能体循环”。它指的是 Agent 在执行任务时反复进行的“推理-行动-观察”循环。很多开发者在刚开始接触 Agent 时会幻想它是一个自主执行的神奇程序但实际上它的核心逻辑极其简单一个带终止条件的循环。伪代码大致如下while not task_finished and steps max_steps: current_state build_state() # 整理当前上下文 decision llm.decide(current_state) # 模型决策 if decision.action finish: task_finished True break result execute(decision.action) # 执行工具调用 save_observation(result) # 保存观察结果供下一轮使用这个循环之所以需要被单独命名是因为它和传统的 while 循环有本质区别传统循环的循环体是确定的代码逻辑而 AgentLoop 的循环体包含一次大模型推理因此每次循环产生的结果都是概率性的、不可预测的。这意味着AgentLoop 必须在每一步都检查模型输出是否合法并为异常情况设计兜底策略。4.2 Agent Loop 在主流框架中的实现如果你用过 LangChain你应该见过 AgentExecutor它的内部就是一个 AgentLoop。如果你用过 LangGraph你定义的 StateGraph 中的节点和边本质上也是让模型在不同状态下循环转移。如果你用过 OpenAI 官方提供的 Agent SDK你会发现它的核心概念就叫 Agent LoopSDK 会负责执行循环、管理轮次、处理模型输出和工具调用。这些框架的目标是一致的把 AgentLoop 的实现细节给包起来让开发者只需要提供模型、工具、系统提示词就能获得一个可运行的智能体。差别在于配置方式和扩展能力。LangGraph 更强调图化编排适合复杂流程OpenAI Agent SDK 更轻适合快速接入而如果你自研就需要自己实现一套 Loop 逻辑。很多初学者容易把 AgentLoop 和 Prompt Engineering 混为一谈觉得 Agent 就是“写一个更复杂的 Prompt”。实际上 Prompt 只是 AgentLoop 里模型决策时的一份输入Agent 能否真正完成任务很大程度上取决于外部系统的构建比如工具的返回格式是否规范、循环的终止条件是否合理、状态的可观察性是否足够。这些都属于 Harness 层的范畴。4.3 一个小型 AgentLoop 的直观示例这里先给一个不依赖任何复杂框架的最小例子演示 AgentLoop 的骨架逻辑。它模拟了一个“会使用计算器工具”的 Agent 在一轮交互中如何循环def run_agent_loop(task: str, model, tools, max_steps5): messages [{role: user, content: task}] for step in range(1, max_steps 1): response model.complete(messages) message response.message messages.append(message) if message.finish_reason stop: return message.content if message.tool_calls: for call in message.tool_calls: result tools.execute(call.name, call.arguments) messages.append({ role: tool, tool_call_id: call.id, content: result, }) raise RuntimeError(超过最大步数任务未完成)注意这段代码里的重点每次模型输出后我们都把它追加到消息列表中工具执行结果也追加到消息列表中。这样模型在下一轮循环中就能“看到”自己刚才的行动结果并据此调整决策。这就是 AgentLoop 的核心原理也是它与传统 API 调用最大的不同。5. 把三个概念放在一起其实它们是一套系统现在我们可以把三个概念拼起来了。一段话概括Agent 是一个以大模型为决策核心的程序实体AgentLoop 是这个程序实体运转时的循环方法Harness 则是承载这个程序和循环的运行时系统。没有 HarnessAgent 就只是一个孤立的推理过程没有 AgentLoopAgent 就只能做一次决策而无法持续完成任务。用汽车来类比更直观。Harness 是整辆车它提供发动机、履带、仪表盘、安全带也就是 Agent 运行所需的一切基础设施。Agent 是驾驶员它负责观察路况、决定打方向盘、踩油门还是刹车。AgentLoop 是驾驶流程观察 - 判断 - 操作 - 观察新路况不断循环直到到达目的地。你不可能让一个驾驶员离开汽车去比赛同样你也不可能把 Agent 从 Harness 里单独拎出来部署上线。再回到最近很火的“deepseek harness”“codex harness”这类热词。你可以把它们理解为两件事一是为特定模型构建的 Agent 运行时项目二是模型厂商或社区在工程化过程中沉淀出的“外骨骼系统”。比如代码生成模型很擅长写代码但要让它在你的仓库里真正改文件、跑测试、看结果就需要一个能操作文件系统、命令行、Git 的 Harness。一些开发者把这些能力打包成开源项目起名时直接带上 harness于是这个词从工程术语变成了搜索热词。下面这张表总结了三个概念的定位概念本质解决的核心问题工程示例Harness运行时系统/框架怎么让模型安全、稳定地接入外部世界OpenAI Agent SDK、LangGraph、社区 deepseek harness 类项目Agent智能体程序让模型自主完成多步任务代码生成 Agent、客服 Agent、数据分析 AgentAgentLoop执行循环机制让 Agent 可以反复试错、观察并调整AgentExecutor 内部循环、SDK 中的 loop runner6. 写一个最小可运行的 Agent 示例亲手跑通 Harness Agent AgentLoop理论讲太多容易飘下面我们落地。我会用 OpenAI 的 Python SDK写一个非常小的 Agent它内置一个“查询天气”的工具然后让 Agent 根据天气查询结果给出穿衣建议。这个例子足够小但已经包含了一个 Agent 应用的全部骨架Harness工具注册、上下文维护、循环控制、Agent 决策LLM 调用、AgentLoop多轮循环。6.1 环境准备首先确认你的机器上安装了 Python 3.10 或更高版本。然后安装 OpenAI Python SDKpip install openai你需要一个 OpenAI API Key或者任何兼容 OpenAI 接口的模型服务地址。如果使用国内模型服务只需修改 base_url 和 model 参数即可下面代码的结构不用变。6.2 完整代码迷你 Agent 循环新建文件mini_agent_loop.py粘贴以下代码# 文件路径mini_agent_loop.py # 说明一个最小可运行的 Agent 示例演示 Harness Agent AgentLoop 的经典结构 import json import os from openai import OpenAI client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) # 这是一个工具函数对应 Harness 中的“工具注册” def get_weather(city: str) - str: 模拟天气查询工具 weather_map { 北京: 晴26 度, 上海: 多云28 度, 广州: 阵雨30 度, } return weather_map.get(city, f{city}晴天25 度) # 工具描述交给模型让模型知道有哪些工具可用、参数是什么 tools [ { type: function, function: { name: get_weather, description: 查询指定城市今天的天气, parameters: { type: object, properties: { city: {type: string, description: 城市名例如 北京} }, required: [city], }, }, } ] def run_agent(task: str, max_steps: int 5) - None: run_agent 就是一个小型 Harness 它维护上下文、调用模型、执行工具、控制循环终止条件。 循环体就是 AgentLoop。 messages [{role: user, content: task}] for step in range(1, max_steps 1): # 1. 模型决策 response client.chat.completions.create( modelgpt-4o-mini, messagesmessages, toolstools, tool_choiceauto, ) message response.choices[0].message messages.append(message) # 2. 如果模型没有要求调用工具说明任务已经回答完成 if not message.tool_calls: print(f[完成] {message.content}) return # 3. 执行模型请求的工具调用并把结果反馈给模型 for tool_call in message.tool_calls: args json.loads(tool_call.function.arguments) city args.get(city, ) result get_weather(city) print(f[第 {step} 步] 调用工具 {tool_call.function.name}({city}) - {result}) messages.append({ role: tool, tool_call_id: tool_call.id, content: result, }) # 4. 达到最大步数强制终止 print([达到最大步数任务结束]) if __name__ __main__: run_agent(北京和上海分别适合穿什么衣服请查询天气后给出穿衣建议)6.3 代码中的角色对应很多人第一次看完这个代码会问“Harness 在哪Agent 在哪AgentLoop 又在哪”这里明确对应一下。run_agent 函数就是最简版的 Harness。它负责创建消息上下文、调用模型、解析模型输出、执行工具、把工具结果回填到消息列表并控制最大步数。这些职责正是 Harness 的核心职责只是商业级框架会做得更复杂比如加入权限控制、状态持久化、错误重试和观测能力。模型本身是 Agent 的“决策核心”。它并不直接运行 Python 函数而是输出一段 tool_calls 结构说明自己希望调用哪个工具、传什么参数。这个决策能力来自大模型的训练能力它决定了 Agent 的上限。for 循环就是 AgentLoop。在每一轮循环中模型先决策框架执行工具返回观察结果再让模型继续决策直到模型不再请求工具或达到最大步数。这个循环结构就是所有 Agent 框架最底层的共性。注意一个容易踩坑的细节模型返回的 tool_calls 里的 arguments 是一个 JSON 字符串必须用 json.loads 解析再取出对应的参数否则直接调用会出现类型错误。如果你在开发中遇到“工具参数解析失败”问题大概率就出在这一行。6.4 运行方式与预期结果在终端里设置 API Key然后运行脚本export OPENAI_API_KEY你的APIKey python mini_agent_loop.py如果一切正常你会看到类似下面的输出具体文案由模型生成不一定完全一致[第 1 步] 调用工具 get_weather(北京) - 北京晴26 度 [第 2 步] 调用工具 get_weather(上海) - 上海多云28 度 [完成] 北京今天晴26度建议穿短袖或薄衬衫上海多云28度同样适合夏季轻薄衣物。判断成功的标准有两个第一终端里能看到工具调用被真实执行第二模型最后的回答引用了工具返回的天气信息而不是凭空编造。如果你看到的输出里模型直接给结论没有调用工具那说明模型认为这个任务不需要工具此时可以调整提示词明确要求“必须先查询天气再回答”。如果运行时出现网络或授权错误请先确认环境变量是否设置正确、模型名称是否可用、以及网络环境是否允许访问你选择的模型服务商。对不同模型服务你只需要替换 client 初始化中的 base_url 和 model 参数代码结构完全通用。7. 常见问题与排查思路在自己写 Agent 或把开源 Harness 项目接入项目的过程中你会遇到很多相似问题。这里列几个高频问题方便你直接排查。问题现象可能原因排查方式解决方案模型不调用任何工具工具描述不清晰或模型认为任务不需要工具查看请求中返回的 finish_reason确认是否被截断或直接输出文本优化函数描述明确职责边界在提示词中要求“必须调用工具后再回答”工具调用了但结果是错误数据参数解析失败或外部 API 返回异常打印 tool_call.function.arguments 和 tool 返回内容用 json.loads 解析并做参数校验外部 API 加超时和异常兜底Agent 一直循环不会终止循环终止条件设置不合理或模型每次都返回新的工具请求给模型强制终止指令或增加 max_steps 限制设置“当获得足够信息时返回最终答案”的终止提示代码层面强制限制循环次数上下文越来越长最终超限每轮都把完整工具结果塞进 messages查看请求长度和模型上下文上限对长结果做摘要、裁剪历史消息、使用内存检索等方式管理上下文开源 Harness 项目安装卡住依赖安装慢或网络源不稳定查看安装日志定位卡住的包切换镜像源或手动安装对应依赖版本优先参考项目 README 中的环境要求生产环境误调用危险操作Harness 没有做权限限制检查工具注册方式和权限模型为不同 Agent 配置最小工具权限敏感操作增加人工确认这类问题的共同根源是很多人把 Agent 当成一个“模型”来调却没有意识到 Agent 是一个“系统”。模型只是系统里的决策者出问题的地方往往在 Harness 层工具描述不准确、循环终止条件不合理、上下文管理缺失、权限控制不到位。因此排查问题时先画一下你的 Agent 执行链路再逐层观察比盲目调试模型参数要高效得多。8. Harness EngineeringAI 工程化里被低估的新方向8.1 什么是 Harness EngineeringHarness Engineering直译是“脚手架工程”或“运行时工程”它指的是为 LLM 应用构建工具链、执行环境和工程化保障措施的工作。这个说法最近在 Agent 开发社区传播很快主要原因是当模型能力越来越接近大家发现真正决定一个 Agent 产品成败的已经不再是选哪个模型而是你围绕模型搭建的执行系统和工程治理做得怎么样。Harness Engineering 的典型工作内容包括设计工具调用协议、实现工具权限控制、构建上下文管理策略、规划可观测性与日志链路、设置 Agent 循环的最大步数和成本预算、建立模型输出到工具执行的异常兜底、以及沉淀 Agent 评估体系。这些工作过去被认为只是“框架的细节”但当你要把一个 Agent 部署到生产环境每一个细节都会变成稳定性问题。8.2 Harness Engineering 和 Prompt Engineering 的区别老一代的 Prompt Engineering 关注的是“模型输入怎么写”Harness Engineering 关注的是“模型周围的世界怎么搭”。两者互补但层次完全不同。对比项Prompt EngineeringHarness Engineering核心对象提示词文本运行时系统主要手段调整 system/user prompt、few-shot构建工具链、状态管理、循环控制、权限边界解决目标让模型输出更符合预期让 Agent 能安全稳定地完成任务失败表象模型回答跑偏、格式不对工具调用失败、循环失控、数据安全风险适合人群业务方、算法工程师后端工程师、平台工程师、DevOps现在很多团队在招人时已经不再只要求“会写 Prompt”而是要求候选人理解 Agent 的执行链路会排查循环问题能设计工具接入规范。这说明 Harness Engineering 正在从边缘技巧变成 AI 应用开发者的基础能力。8.3 实际做 Harness Engineering 的几条原则如果你准备在自己的项目里正式落地一个 Agent下面几件事值得先想清楚。第一工具描述要像 API 文档一样严谨。模型通过函数的 name 和 description 来理解工具用途如果描述含糊模型就可能乱填参数。建议每个工具都写清楚参数类型、取值范围、返回结构并在测试集里验证工具调用的准确率。第二循环必须有终止条件。至少设置最大步数、最大 Token 消耗、超时时间以及模型主动输出终止标志时的处理逻辑。没有终止条件的 Agent 在生产环境里会变成“烧钱黑洞”。第三工具权限最小化。宁可让 Agent 先申请权限也不要让它在无人监督的情况下操作生产数据库。涉及删除、修改、支付等高风险操作时建议插入人工审批环节。第四日志和可观测性要内置。Agent 不像普通接口一次请求就是一次执行它是一个多次循环的过程。每一轮模型输出、工具调用、错误信息都应该有结构化的日志方便复现和排查。第五评估不能只看最终结果。你还需要评估“Agent 是否在合理步数内完成任务”、“是否产生了不必要的工具调用”、“是否在遇到错误时能正确自救”。这些指标能帮助你定位是模型能力问题还是 Harness 设计问题。9. 总结与下一步行动建议回到本文开头的问题Harness、Agent、AgentLoop 到底有什么区别现在答案很清楚了。Agent 是那个以大模型为大脑、能感知和行动的程序实体AgentLoop 是它持续运转的循环机制Harness 是承载这一切的运行时系统。营销号喜欢把它们混在一起说是因为分开说需要讲更多工程细节而混在一起更容易制造概念焦虑。作为工程师你要做的是绕过概念焦虑回到系统本身你的任务需要 Agent 吗你的 Agent 循环需要哪些工具你的运行时需要哪些安全和控制能力如果你想继续深入我建议按这个顺序实践。第一步把上面这个最小的 Agent 示例跑通仔细理解 messages 是怎么在循环里累加的这是所有 Agent 工程的地基。第二步尝试给它多加几个工具比如时间查询、文件读取、简单计算观察模型如何选择工具。第三步再引入一个成熟框架比如 LangGraph 或 OpenAI Agent SDK把你的自定义工具迁移进去感受框架帮你解决了哪些问题、又带来了哪些约束。第四步如果项目要上线再考虑权限、成本、可观测性、评估这些 Harness Engineering 问题。最后提醒一句不要迷信任何“一行代码让你的 AI 自主干活”的开箱方案。Agent 真正难的不是启动那一下而是后面无数个“模型没按预期调用工具”和“循环没有在正确的时候停下来”的瞬间。把 Harness、Agent、AgentLoop 这三个概念真正理解清楚你会在这些瞬间里从容很多。