01 · Agent Harness入门：从后端服务到Agent

1. Agent、模型与Harness，分别是什么？

AI Agent通常译为“智能体”。在这套课程里，它是一种围绕目标完成任务的应用：模型根据目标和已有信息选择下一步，程序执行，再根据实际结果继续推进。

比如，你提出“分析昨晚直播的成交额为什么下降”。Agent可以先查成交额，再根据结果补查流量或商品，最后整理分析。用户给出目标，具体步骤可以在执行中调整。

模型提供理解、推理和生成内容的能力。Agent Harness是围绕模型构建的一整套工程能力：决定模型能看到什么、怎样调用工具、遇到异常如何处理，以及如何记录和观察执行过程。

在系统里，Harness连接用户任务、模型和实际业务能力。它组织模型参与工作，让模型提出的操作在程序控制下执行，并把结果交付给用户。

Agent指面向用户完成任务的整体应用；Harness是其中负责组织与管理模型的工程部分。已有订单系统、商品系统仍是业务服务，可以被Agent复用。实际项目中，Harness的能力可能分布在应用代码、框架或平台里。

2. 先认识几个会反复出现的词

Prompt是Context的一部分；查回来的数据也会进入Context，但它们属于事实资料，不能自动变成应用指令。

Tool让模型能够借助程序获取信息或执行操作；ReAct解释这些操作怎样随着反馈往前推进。后面会用同一个任务把它们串起来。

3. Harness到底管哪些事？

先从四个问题理解它的职责：

“模型能看到什么”，包括挑选任务需要的数据、带上必要的对话、控制输入规模。把整库订单和所有历史日志都交给模型，可能使重点被淹没，还会增加费用。

“模型能做什么”，包括开放哪些工具、检查参数和用户权限。模型提出查询订单，不代表它获得了访问任意店铺的权限。

“任务怎样继续或停止”，包括保存执行进展、处理失败、限制次数和耗时。接口持续故障时，程序需要让任务停止或转交处理，不能任由模型反复尝试。

“怎样看清执行过程”，叫可观测性：通过日志、调用轨迹和指标，知道任务查过什么、慢在哪里、为什么失败。任务完成后，还需要评测，检查结果是否正确、是否满足要求。

这些能力共同影响任务能否可靠完成。即使程序一直正常运行，模型也可能解释错数据，因此执行成功与结论正确需要分别检查。

4. 同一个问题，传统后端和Agent有什么区别？

继续看“昨晚直播的成交额为什么下降”。传统后端可以先比较成交额，再按规则检查观看人数、支付转化和商品构成，输出报表或诊断结果。

传统服务也能有复杂分支：观看人数下降就查流量来源，流量正常再查转化。后续步骤由开发者预先编写。

Agent可以让模型根据问题和已取得的结果，提出下一步查询。用户追问“只看新品”“和上周同一天比”，模型可以相应调整查询条件与步骤，程序负责检查并执行。

这种灵活性也会带来问题：模型可能选错接口、漏查信息，或者反复查询。固定报表用现成接口或工作流就很好；需要根据问题与反馈调整步骤时，才更值得引入Agent。

实际系统也可以混合使用：金额计算、权限检查等由确定的代码完成，需要灵活判断的分析步骤交给模型。

5. Tool怎样把已有接口接进来？

模型不知道店铺昨晚的真实数据，也不会凭空拥有订单系统的访问权限。应用需要向它提供一个“对比两场直播成交额”的工具，并说明用途、输入和返回内容。

Tool背后可以是本地函数，也可以调用已有API；一个Tool还可以组合多个接口，完成筛选、聚合和计算。

工具参数通常用Schema描述，也就是字段、类型和约束的结构约定。参数怎么设计、返回多少数据，后面的工具调用篇会展开。

模型生成工具名和参数，程序校验后执行，再把实际结果交回模型。 这个过程叫Tool Calling，即工具调用。

比如订单接口返回“上一场10万元，昨晚8万元”。程序把这些结果放入后续模型请求，模型才有依据继续分析。只在服务器日志里打印“查询成功”，模型看不到实际金额。

这里展示的是只读查询。发通知、修改订单等会改变外部系统的操作，还需要单独控制执行权限和确认方式。

6. 步骤怎么安排？把ReAct与其他方式放在一起看

Tool解决“有哪些能力可以用”，执行方式解决“谁来安排步骤，什么时候调整”。Harness负责把这种安排落实为实际调用，并控制权限、次数和停止条件。

6.1 同一个直播分析任务，三种安排方式

预设工作流也可以调用模型、包含分支和循环。区别在于，哪些步骤与分支由开发者预先规定，哪些选择留给模型在运行中决定。

6.2 ReAct的关键，是让实际反馈影响下一次判断

ReAct由Reasoning（推理）与Acting（行动）组合而来。模型判断要做什么，程序执行获准操作，取得Observation（观察结果），再把反馈交给模型继续判断。

仍用虚构数据看一次过程：两场直播时长相同，成交额均按已支付订单金额计算，暂不扣退款。

后一次操作利用了前一次的实际结果。 如果工具超时，模型收到的应是查询失败，而不是“观看人数没变化”。模型可以调整查询、说明资料不足，程序也可以因超时或超限结束任务。

ReAct也可以有阶段计划；先规划再执行的某个子任务，也可以用ReAct完成。前者强调判断、行动和反馈的交替，后者把整体规划与具体执行分开，两者可以组合。先有计划也不保证更快、更省钱或更正确，要看实际任务。

6.3 Reflection：完成一版以后，再检查和改进

Reflection通常译为反思。这里先理解为：检查已有结果，给出反馈，再修改。例如报告说“流量下降导致成交额下降”，检查环节发现证据不足，要求补查转化数据，或把结论改成待验证方向。

它关注结果怎样改进，可以叠加在工作流、ReAct或规划执行之后。模型自己检查也可能漏错，因此仍要结合真实数据、程序校验或人工审核，并限制修改次数。

对这个直播分析Agent，可以把必查指标写成固定流程，让模型用ReAct补查异常，最后检查报告中的来源与结论。无须为了使用某个模式，把所有步骤都交给模型。

7. 后面的课程，都在补哪部分能力？

回到Harness的系统位置，后续课程逐步展开输入、工具、状态、执行环境和验证。它们共同组成一个系统，有些能力贯穿整个任务。

这些是能力划分，不要求每个模块都部署成独立服务。先让一个小任务跑通，再根据真实问题补能力。

8. 有后端经验，可以从哪里接上？

已有的接口设计、数据库查询、权限、超时和故障处理经验，都能继续使用。接入模型以后，还要考虑模型反复做决定带来的影响。

这一篇先能说清三件事就够了：Agent怎样完成任务，Harness负责哪些工程工作，以及Tool、ReAct和后续模块在其中处于什么位置。

下一篇从Prompt开始，讲任务要求怎样进入模型。