LLM：Agent 逻辑与应用场景

Agent 的核心由两个变量决定：控制任务走向的workflow（工作流）、控制内容生成的context（上下文）。

这套想法来自两处实践的交汇。一拨是达摩院李瑞博，他提出用 workflow 和 context 两个变量来分 Agent 场景，搭出了理论框架。另一拨是开发社区，踩了一堆坑后总结出落地原则——脚本干脚本的事，模型干模型的事。两拨人说的其实是一回事：Workflow = 确定性逻辑 → 交给工程/脚本，Context = 推理判断 → 交给大模型。

据此可分为 4 类典型场景（达摩院李瑞博，25.09.23）：

workflow 与 context 均确定：该场景易实现自动化，类似于传统 RPA（机器人流程自动化），常见应用如发票处理、表单填报等。在此类场景中，AI 主要起 “粘合剂” 作用，发挥空间相对有限。
workflow 确定但 context 不确定：此类场景需要借助语义理解进行信息补全，例如客服问答、合同解析等任务。完成这些任务依赖外部检索、知识图谱等方式来填补信息缺口。
workflow 不确定但 context 确定：在这种情况下，Agent 需要自主规划任务执行路径，典型应用包括市场分析报告生成、个性化推荐等。End-to-End RL Agent（强化学习 Agent）在此类任务中表现出色。
workflow 与 context 均不确定：这是最复杂的场景，Agent 需要具备推理和探索能力，适用于创新方案设计、跨部门信息收集等任务。此类场景依赖通用型 Agent，关键在于配备丰富工具，特别是开放编程能力，如克隆修改 Github 代码等操作。

高不确定性环境的应对方案

当 Agent 处于高不确定性环境时，容易出现 “幻觉（hallucination）” 或陷入无限循环，需要借助以下工具和方法应对（达摩院李瑞博，25.09.23）：

动态规划与探索：允许 Agent 自主分解任务、迭代执行路径。
上下文补全：通过检索、搜索、知识整合等方式填充未知信息。
执行力提升：重点利用编程工具，支持代码的生成、修改和运行。
多代理协作：模拟 “团队分工” 模式，提高任务执行的鲁棒性。

职责边界怎么划

Workflow 管什么

顺序执行、条件分支、数据拼接、接口调用、数据清洗、特征计算——这些逻辑能写死的就写死。脚本的优势在于：没有幻觉、执行速度快、Token 消耗低。

开发社区的实践者总结过：大模型只做脚本和编程做不到的事，剩下程序本来就能做的，用程序做更精确可控、速度更快、成本更低。

Context 管什么

意图理解、多因素推理、模糊场景决策、风险定性——这些是代码无法完成的活儿，只能交给模型。

Sub Agent 步骤数优化实践

Sub Agent（受主控 Agent 调用的子代理）的优化案例，属于 “workflow 与 context 均确定” 这一类场景。

原方案让大模型自主调用 5~~6 个工具，走 9~~10 个步骤，导致 Sub Agent 不受控、输出千奇百怪。优化后的方案是：

预先封装用户信息：将所有用户信息预先封装成用户画像宽表，由工程侧完成数据拼接与预处理 → context 变得确定
降低决策复杂度：让大模型只做一件事——读宽表，做定性判断 → workflow 变得确定
职责分离：把数据处理（工程化）和逻辑推理（模型）分开，前者交给工程，后者交给模型
核心优化原则：降低 agent 操作步骤数，比提升 prompt 质量更有效

通过将一个原本复杂的任务（workflow 和 context 都有不确定性）改造为明确的单步任务，Agent 的输出稳定性大幅提升。这个发现对复杂任务优化很有启发：让大模型专注它擅长的定性判断，把数据处理提前做好，这样效率和准确性都能提升不少。就像让短跑选手专注跑步，别让他一边跑一边跨栏递水。

工程化落地的风险警示

有人把系统权限完全交给 AI，结果 AI 一个失误，整个系统崩了。教训很直白：权限越小越稳，脚本能干的绝不交给 Agent，别指望让模型包办一切。

一句话

先工程化，再智能化。确定性流程交给脚本，模型只做最终判断。步骤越少、权限越小，系统越稳。