从LLM到Agent：Agentic系统的知识地图

LLM 提供理解与生成能力，Agent 把这些能力组织成可执行的任务系统。 设计 Agent 的关键，是明确哪些决策交给模型，哪些事实由环境提供，哪些边界由程序保证。

以“调查一次订单异常并给出处理建议”为例，写出一段分析只是任务的一部分。系统还要获取有权限查看的订单、识别缺失证据、根据查询结果决定下一步，并区分“已提出处理建议”和“已经执行处理”。本文围绕这个差别，建立后续十二篇文章的阅读地图。

1. 从一次推理到持续执行

教学时常把模型调用写成一个函数：

response = model(context, generation_options)

这是接口抽象，不是对所有模型内部机制的完整定义。输入输出可以包含文本、图像、音频或结构化消息；推理过程也可能使用缓存与内部状态。一次调用能生成计划、修订方案、判断错误，但这些能力并不自动产生可恢复的任务记录、真实的工具副作用或可靠的完成证明。

应该区分三个层次：

因此，不能用“自回归不能修改已输出 token”推导出“模型不能规划或反思”。它可以在后续输出中修正前面的方案；系统需要保证的是修订是否被正确执行、是否保存，以及执行结果是否支持修订。

模型变强可以减少错误、改善规划，也可能简化外围架构。它仍不会替应用决定某个用户能否退款，或替数据库建立幂等约束。

2. 用五类职责拆解系统

本系列用 LLM、Memory、Tools、Planner、Runtime 五类职责分析 Agent。这是工程分解方式，不是要求每个项目都部署五个独立组件。

短任务可能不需要长期记忆；规划可以融入模型调用；反思可能由测试、规则或下一轮推理完成。拆分的目的在于定位职责，不能把组件数量当成熟度。

同一个失败也可能跨越多个职责。例如查错订单，可能源于模型误解、工具描述含糊、身份参数错误或后端授权缺失。需要沿着输入、决策、调用和结果定位，不能仅凭表象归责给某个模块。

3. 控制循环把决策与环境连接起来

ReAct 论文研究了推理与行动交替的方式：动作取得环境信息，后续决策据此调整。本系列把这种反馈过程进一步拆为六类活动，便于讨论工程职责。

这六项不一定对应六次模型调用，也不是唯一标准。一次模型调用可以同时理解问题并提出动作；测试失败可以直接成为反馈，无需先让另一模型写一段评价。

下面是教学伪代码，省略了具体 SDK、持久化和权限实现：

def run_agent(goal, runtime):
    state = runtime.start(goal)
    while runtime.can_continue(state):
        response = runtime.decide(state)
        runtime.record_assistant_response(state, response)

        if response.tool_calls:
            for call in response.tool_calls:
                if not runtime.can_continue(state):
                    return runtime.finish(state, status="stopped")
                result = runtime.execute_checked(state, call)
                runtime.record_tool_result(state, call.id, result)
        else:
            return runtime.assess_and_finish(state, response)

    return runtime.finish(state, status="stopped")

其中，记录模型发出的工具调用和记录工具结果是两件事；不能只把结果塞进历史而遗漏对应调用。没有工具调用也只说明模型给出了回答，不能直接证明任务成功。最终状态需要保留“完成”“等待输入”“被取消”“预算耗尽”“失败”等区别。

循环的边界至少要覆盖任务步数、总时限、成本预算、用户取消和无进展。它们解决的问题不同：达到预算是停止理由，不是完成证据；同一查询重复出现，也可能是合理轮询，需要结合结果变化和工具契约判断。

4. 用订单异常调查贯穿各层

以下是说明性场景，不是某个产品的实测记录：用户发现一笔订单显示“处理中”，希望系统查明原因并给出建议。

这里的价值来自动态补充证据：系统无需提前穷举每一种异常组合，但也不把业务规则交给模型自由改写。

后续记忆篇讨论如何保留这笔订单的调查状态，规划篇讨论何时补查、何时停止，多 Agent 篇讨论是否值得拆出独立调查任务，可信篇则讨论如何约束真正有副作用的操作。

5. Workflow 与 Agent 的区别在决策边界

工作流并不等于 DAG，也不等于只能走一条静态路径。状态机可以有条件分支、重试、循环和等待；同样，Agent 也可以被严格限制在某个步骤内。

Anthropic 的工程说明用一个实用区别描述两者：工作流主要沿预定义路径组织模型与工具，Agent 则让模型在运行中决定更多执行步骤。这个区分有助于讨论控制权，不是互斥的产品分类。

没有“路径超过 20 条就必须用 Agent”的阈值。判断依据是：动态决策是否带来可测量的收益，其成本与错误是否可接受。

在订单案例里，“查询哪些证据”可以交给 Agent 调整，“什么条件允许退款”仍由业务服务判断。即使整条订单状态机能画出来，异常调查环节仍可能受益于 Agent。

6. 十三篇文章怎样衔接

下图是职责地图，不是部署分层，也不意味着所有模块必须建设。

为方便系列讨论，A1–A4 表示本文自定义的自主性形态，M1–M4 表示记忆职责，T1–T3 表示学习时间尺度。这些是组织材料的记号，不是行业认证标准，更不能相互替代。

可观测、安全与评估贯穿上述阶段，不应在功能开发完毕后才补上；但其实现复杂度应匹配实际风险与规模。

7. 优先投入工具契约与结果评估

工具契约决定模型提出的动作是否能被正确执行。描述应说清用途、参数含义、返回字段和限制；服务端则负责授权、业务校验与副作用控制。描述长度或工具数量无法单独衡量质量。

评估决定一次调整是否有效。针对订单场景，可以分别检查对象定位、证据覆盖、未知状态处理、越权拦截、建议正确性和执行结果。还要记录人工介入、耗时与成本，避免用“回答看起来完整”代替业务结果。

评估集应覆盖主要场景、边界条件与失败路径，并保留独立测试样本。样本数量由覆盖与统计需求决定，不能把固定的 50 条当作生产门槛。早期人工核验与小规模回放，也能帮助团队发现最值得修正的问题。

构建 Agent 的收益，在于把语义理解与环境反馈结合起来，完成难以预先写尽的任务。它是否值得引入，应由同一批任务上的结果、成本和可控性证明。后续文章就在这个基础上，逐步把“会提出动作”推进到“能可靠交付结果”。