章末自测-大赛人网

题目 1：为什么“LLM + 三个工具”不一定是 Agent？

某系统接入了一个大模型，并提供“查天气”“计算器”“网页搜索”三个工具。程序固定规定：每次请求都先搜索网页，再查天气，最后调用计算器。请判断这个系统是否已经具备典型 Agent 特征，并从“下一步由谁决定”的角度解释。

这个系统虽然用了 LLM 和多个工具，但更接近固定 Workflow。因为工具调用顺序已经由程序写死：搜索网页、查天气、计算器。模型并没有根据 Goal、State、Observation 动态选择下一步动作。Agent 的关键不是有几个 Tool，也不是是否接了 LLM，而是模型是否进入控制路径。如果路径仍由开发者完全预定义，系统就不能仅凭 Tool Calling 被认定为典型 Agent。

题目 2：判断题——流程越复杂，就越应该使用 Agent，对吗？

一个退款系统包含订单校验、金额判断、主管审批、财务审批、退款执行、审计记录等十几个节点。有人认为流程已经非常复杂，所以应该把整个系统改造成 Agent，让模型动态决定下一步。请判断这个建议是否合理，并说明原因。

通常不合理。复杂不等于不确定。退款系统虽然节点多，但金额阈值、审批规则、权限与审计要求都应该明确，而且属于强合规场景。这样的流程更适合 Workflow 或状态机，因为需要可预测、可审计、可复现。Agent 可以参与开放式子任务，例如总结退款原因、辅助风险分析，但核心资金流转不能由模型自由决定。判断是否需要 Agent，应看是否存在难以提前枚举的语义决策，而不是单纯看节点数量。

题目 3：代码阅读——为什么下面代码仍然是 Chain？

def run(text):
    summary = llm_summary(text)
    category = llm_classify(summary)
    title = llm_generate_title(summary, category)
    return title

请解释它为什么不是典型 Agent。如果希望它开始具备 Agent 特征，至少需要发生什么结构变化？查看参考答案

这段代码的执行顺序固定：先摘要、再分类、再生成标题。LLM 虽然参与了每个节点，但并没有决定“下一步做什么”，所以仍然是 Chain。要让它具备 Agent 特征，至少要引入一个运行循环与动作集合，让模型能够根据当前状态和 Observation 决定下一步，例如信息不足时先搜索、分类置信度低时重新获取信息、已经满足目标时提前结束。也就是说，需要从固定调用序列变成“决策 → Action → Observation → 再决策”的闭环。

题目 4：编程实现——写一个最小架构推荐器

请根据 steps_known、rules_clear、semantic_branching、many_possible_actions、high_risk 五个布尔变量，编写一个完整可运行程序，至少输出“优先 Workflow”“考虑 Workflow + Agent”“高风险场景只让 Agent 做分析”三类建议，并测试三个案例。

可以把本节的判断逻辑编码成一个非常简单的函数。重点不是追求百分之百准确，而是建立正确的工程顺序：先判断风险，再判断流程是否确定，最后判断是否真的需要动态语义决策。

def recommend_architecture(
    steps_known: bool,
    rules_clear: bool,
    semantic_branching: bool,
    many_possible_actions: bool,
    high_risk: bool,
) -> str:
    if high_risk:
        return "高风险场景：优先 Workflow，只让 Agent 做分析或建议。"

    if steps_known and rules_clear and not semantic_branching:
        return "优先 Workflow。"

    if semantic_branching and many_possible_actions:
        return "考虑 Workflow + Agent。"

    return "先实现简单 Workflow，再评估是否真的需要 Agent。"


if __name__ == "__main__":
    cases = [
        {
            "name": "退款审批",
            "args": (True, True, False, False, True),
        },
        {
            "name": "代码修复",
            "args": (False, False, True, True, False),
        },
        {
            "name": "固定数据清洗",
            "args": (True, True, False, False, False),
        },
    ]

    for case in cases:
        result = recommend_architecture(*case["args"])
        print(f'{case["name"]}：{result}')

退款审批会得到高风险场景建议，代码修复会得到 Workflow + Agent，固定数据清洗则优先 Workflow。真正项目还需要更细的约束，但这个练习能够帮助我们建立“不要一上来就 Agent 化”的思维习惯。

题目 5：综合应用——自动生成日报要不要 Agent？

某公司每天固定读取 5 张表，计算 12 个固定指标，按照固定模板生成日报并发送到群里。团队准备“升级 AI”，有人建议整套流程改成 Agent。请分析是否有必要；如果要加入 Agent，最适合放在哪个环节。

主体流程并不需要 Agent。读取固定表、计算固定指标、按模板生成日报、定时发送，这些步骤高度确定，用 Python、SQL 和 Workflow 更稳定、更便宜、更容易测试。如果要增加 Agent，最有价值的位置是“异常解释”环节：Workflow 先稳定产出指标，Agent 再判断今天哪些指标异常，并根据异常结果继续查询相关维度、生成解释。这样固定生产流程仍由 Workflow 控制，开放式分析交给 Agent，形成更合理的混合架构。

题目 6：对比分析——Workflow 的动态分支和 Agent 的动态决策有什么不同？

A 系统根据 score > 0.8 决定“自动通过”或“人工复核”；B 系统拿到错误日志后，从 read_file、search_files、run_test、edit_file 等工具中选择下一步。为什么我们通常只把 B 看作 Agent 的典型场景？

A 虽然运行时才知道走哪条分支，但所有路径已经由开发者提前枚举：高于 0.8 走自动通过，否则走人工复核。B 面对的是开放式语义结果，错误日志可能对应依赖、路径、配置、代码、环境等大量情况，开发者难以提前列全。模型需要结合 Goal 和 Observation，从多个工具及其参数组合中动态选择动作。因此，A 属于预定义规则驱动的动态分支，B 才更符合 Agent 的运行时语义决策。

题目 7：概念理解——为什么 Agent 必须把 Tool Result 作为 Observation 放回去？

如果模型在一开始已经生成一个完整计划，为什么还要把每次工具执行结果重新放回模型？请结合“读取文件失败”或“SQL 查询结果异常”解释。

因为真实环境会不断产生新信息，初始计划无法保证完全正确。比如模型计划第一步读取 app.py，但工具返回 FILE_NOT_FOUND。如果没有 Observation，系统只能机械执行后续计划；有了 Observation，模型可以重新判断，先 list_files 找真实入口文件。数据分析同样如此：第一条 SQL 可能显示只有某个媒体异常，这个结果会直接改变后续下钻方向。Observation 是环境对 Action 的真实反馈，是 Agent 能够修正路径的关键。

进一步阅读

ReAct: Synergizing Reasoning and Acting in Language Models：理解 Reason、Action、Observation 如何形成经典 Agent 循环。
LangGraph Concepts：适合从 State、Node、Edge 的视角继续理解 Workflow 与 Agent 如何组合。
Apache Airflow DAG Concepts：帮助建立“依赖复杂”和“动态决策”不是一回事的工程直觉。
Temporal Workflow Concepts：观察生产级 Workflow 如何处理状态、重试、超时和恢复。
OpenAI Tools / Function Calling 文档：重点理解模型如何表达“我想调用哪个工具”，而不是只记 API。
Human-in-the-Loop Agent 相关资料：提前理解为什么生产 Agent 不应该无限自主。
State Machine / Workflow 设计相关资料：适合加深对确定性流程的理解。
Agent Observability / Tracing 相关文章：提前建立“动态系统必须能复盘”的意识。

术语表

链式流程（Chain）：把多个处理步骤按固定顺序串联起来的执行方式。它适合路径稳定、步骤明确的任务，下一步通常可以在任务开始前确定。
有向无环图（Directed Acyclic Graph, DAG）：用节点表示任务、用有向边表达依赖，并且不存在循环。它特别适合并行、汇合、前置依赖等复杂但可预先定义的流程。
工作流（Workflow）：比单纯 DAG 更偏业务编排，通常包含状态、条件分支、重试、审批和异常处理。核心规则一般由开发者或业务规则提前定义。
智能体（Agent）：在本课程里，指能够根据 Goal、State、Observation 和可用 Tools，在运行过程中动态选择下一步动作的系统，而不是单纯“接入了大模型”的程序。
动作（Action）：Agent 某一轮选择执行的操作，例如读取文件、搜索代码、运行测试、查询数据库。Action 通常需要由 Harness 校验后才能真正执行。
观察结果（Observation）：Action 执行后的真实反馈，例如文件内容、错误日志、命令输出或 SQL 结果。Observation 会进入下一轮决策，帮助 Agent 修正行动路径。
主循环（Main Loop）：把“决策、执行、观察、再次决策”连接起来的持续运行循环。下一节会正式把它写成可扩展的 Python 结构。
智能体承载层（Agent Harness）：围绕模型构建的运行基础设施，负责 Tool、State、Context、安全、Tracing、审批和服务化等能力，使 Agent 的动态决策能够在受控环境中执行。

本章总结

这一节我们真正想解决的，不是“Agent 怎么写”，而是“为什么需要 Agent”。

Chain 并没有过时。只要任务步骤明确、顺序稳定，它仍然是最简单、最可靠的方案。DAG 解决的是复杂依赖与并行，它让流程从一条线变成一张图，但节点和依赖通常仍由开发者提前定义。Workflow 再往前一步，可以加入条件、状态、重试、审批和异常分支，非常适合业务规则明确的系统。

Agent 真正补上的，是另一类能力，当完整路径无法提前写死时，让模型根据目标、当前状态和环境反馈决定下一步。

所以我们从：

A → B → C

走到了：

Reason
  ↓
Action
  ↓
Observation
  ↓
Reason

这也是为什么本节反复强调，Agent 的核心不是“调用大模型”，而是把部分决策权交给模型。

“部分”两个字同样重要。

权限、安全、最大步数、SQL 白名单、工作目录、审批、超时、审计，这些事情不应该交给模型自由判断。真正成熟的系统往往不是“纯 Agent”，而是：

Workflow
+
Agent

确定的部分由 Workflow 保证稳定性，不确定的部分由 Agent 提供动态决策能力。

如果你想验证自己是否真的掌握了这一节，可以随便拿一个业务任务，不要问“能不能用 Agent”，而是问：

完整路径能不能提前列出来？
分支规则是不是明确？
下一步是否依赖上一轮的语义结果？
候选动作是不是多到难以穷举？
这个任务是否允许一定程度的不确定性？

当你能够根据这些问题判断该用 Chain、DAG、Workflow 还是 Agent，这一节最重要的能力就已经建立起来了。

下一节我们会正式进入整门课最核心的代码：Main Loop。

今天的：

当前状态
  ↓
决定下一步
  ↓
执行 Action
  ↓
得到 Observation
  ↓
继续判断

会被真正写成一个可运行、可扩展的 Python Agent Loop。

从下一节开始，Agent 不再只是架构图里的概念，而会第一次变成我们自己亲手写出来的程序。

文章版权归作者所有，未经允许请勿转载。

THE END

Harness Engineering
# Harness Engineering