目录
1. 为什么要做 Agent？Agent 解决了什么业务问题？常规的 GUI 方式不能解决问题吗？
3. less structure, more intelligence
一、前言
在信贷风控领域下，以加工出具有“高效能”和“高可解释性”的策略为目标，其中：策略加工过程会涉及不同场景下的要素切分和融合，切分的阈值和融合的规则通常采用运筹算法在满足特定的约束条件下来求最优解，求最优解的过程需要人工不断地去重跑运筹算法，并“人肉串联”从切分到融合整个流程。策略加工后随着时间推移，策略会面临要素迭代滞后、性能衰退等问题，从而缺乏系统性优化机制。围绕着这两个问题设计出两个 Agent 来解决相应的问题：
要素融合 Agent：提供“轻智能版”（workflow模式）和“智能版”（基于 Reflection 的自主规划模式）两种模式对要素进行切分和融合。
策略优化 Agent：采用 ReAct 模式对规则进行分析，分析出规则存在的性能瓶颈并做出优化。
二、Agent 模式选择
1. 常规 Agent 模式
a. LLM 自主规划类
ReAct：reason（推理）-> action（行动） -> observation（观察）。
Plan and Execute：规划与执行，先规划好完整步骤，再分步执行。
Reflection：反思驱动。大模型通过自我反思修正当前的结论。由此衍生出的常用模式（即本项目采用的模式）如下：
Step 1：思考当前需求，并初步生成执行计划
Step 2：执行执行计划中的每个节点，且每执行完一个节点时，会根据节点输出更新执行计划（已执行的节点不能再变更）
Step 3：直到所有节点执行完成，则结束当前执行计划
b. Workflow 预编排类
固定业务流程模板并按顺序调度即可，大模型除起到串联参数外，通常也会作用到某个节点（比如 Agent 节点）。
2. 怎么选择 Agent 模式？
选择怎么样的 Agent 模式还是要回归到业务本身，信贷风控领域下要素的产生和策略的优化都耗时耗力，比如拿要素切分来说，除前置的数据处理外，使用固定的切分算法（如等频切分）耗时基本都是小时级别。所以结合任务的长周期性和资源耗费情况，要素融合 Agent 采用了带 Reflection 的自主规划模式，即先让大模型生成候选执行计划（Execute Plan）列表，再做策略（比如最大置信度）选择，最后执行计划节点执行过程中不断的刷新执行计划。要素融合 Agent 不采用 ReAct 模式考虑点如下：
从交互体验上讲，ReAct 模式是先选择工具，再执行工具，要素融合工具往往参数比较多，过程中可能需要不断地反问用户，而 Reflection 模式提前规划好执行计划，用户可通过一次性填参避免频繁交互。
从“策略生成”这种业务模式上讲，采用 ReAct 模式太发散，容易走很多弯路，浪费计算资源。
Reflection 模式先全局生成候选执行计划列表，在执行过程中不断的刷新执行计划本质上已经覆盖了 ReAct 模式，如果单纯使用 ReAct 模式，可能面临结点执行失败而导致整个执行计划失败，由于每个结点执行起来很“重”，最好执行前就保证执行路径的正确性，而全局规划正在是解决这个问题，并提供一个尽快、尽全的模式。
策略优化 Agent 解决的是规则性能问题，过程需要结合专家经验知识、工具查询的事实结果等信息来决定策略怎么优化，非常符合 ReAct 模式。
三、需求分析
与常规需求分析不同的是，理论上大模型的需求调研和初步可行性分析的执行者的角色从技术向产品（或运营）转变。然而信贷风控属于偏中后台的领域，往往缺少兼风控知识和AI产品经验的产品，所以就需要技术深度参与其中。技术在整个需求调研过程中，核心关注：
策略是怎么产生的。策略的产生是一个周期长而且复杂的流程，同时策略也会分不同的细分场景，所以要先以某入垂直场景做切入点，再横向扩展。因涉及到利益关系和各方（研发、算法和策略）的参与程度不同，往往生产关系的解决也是非常核心的一环。
需求分析包含：Agent 定义、用例描述（分类及对话方式举例）、可能涉及的工具、大模型作用的业务场景等。
四、Agent 领域模型
先放一张 OpenAI 研究主管 Lilian Weng 给 Agent 的定义图：Agent=大模型（LLM）+规划（Planning）+记忆（Memory）+工具使用（Tool Use）：
附：图片来源文章《LLM Powered Autonomous Agents》，地址：LLM Powered Autonomous Agents | Lil'Log
结合 Agent 定义和信贷风控领域的长周期的特点定义了任务型Agent下的领域模型，如下图：
该领域模型是一个通用的领域模型，目前支持了Workflow、ReAct、基于 Reflection 模式下的 Agent 设计。核心领域概念如下图（这里先不讲多智能体的概念）：
| 中文 | 英文 | 解释 |
|---|---|---|
| Agent | Agent | agent 定义 |
| Agent任务（模板） | AgentTaskTemplate | Agent 一般会支持多类任务，通过意图识别来路由不同的任务类型，比如要素融合 Agent 有几类任务：评级切分、评级融合等 |
| 执行计划 | ExecutePlan | 简称EP，大模型规划或者人工预设的工作流，是一个有向无环图。这里采用 GraphViz 语言定义图。 |
| 执行计划模板 | ExecutePlanTemplate | 在 workflow 模式下由人工预设的执行计划图 |
| 会话 | Chat | 用户会话 |
| 用户任务 | UserTask | 是为多智能体设计的，中枢 Agent 会将用户一句话拆解成多个用户任务，每一个用户任务由单独的 Agent 完成 |
| Agent 任务 | AgentTask | Agent任务实例，比如评级切分任务实例等。一个用户任务对应多个Agent任务实例 |
| Prompt模板 | PromptTemplate | 提示词模板 |
| 工具组 | ToolGroup | 一般任务型Agent使用的都是异步工具，这里将异步工具拆分为提交、查询、中止三个工具，合称为一个工具组 |
| 工具 | Tool | 异步工具的提交、查询、中止是三个工具；同步工具只有一个提交工具 |
五、Agent 引发的思考
1. 为什么要做 Agent？Agent 解决了什么业务问题？常规的 GUI 方式不能解决问题吗？
虽然在 Agent 元年尝试新技术无可厚非，但这个问题在什么场合下都规避不了，必须要找到合理的答案。常规大模型主要解决以下两类问题：
借助大模型能力，以更加便捷的方式（LUI等）替换原有 GUI 方式为用户提效。比如降低应用开发门槛、简化流程复杂度（如抽参）、协同完成某项复杂任务等。
利用大模型进行决策，比如结合业务专家经验知识进行路径规划和业务分支决策。这一点比较有说服力。
要素融合 Agent 利用了 Agent 串联协作和大模型决策能力，策略优化 Agent 结合丰富的策略专家经验知识利用了大模型决策能力。另外，想清楚业务每个点在使用大模型解决怎么问题？大模型核心优化点在哪里？非常感谢今年带我的老板，虽然整个 Agent 项目效果不尽如意，但最终以另一种形式得到延续。
2. 开发思维的转变
Agent 是人的代理，理解到这一层是 Agent 开发者入门的体现。比如以“人”能理解的语言去描述技术方案，执行计划状态机系统上的描述是“暂停“，对用户的描述是”待用户输入中”。
3. less structure, more intelligence
引用集团内网某位大佬的描述：
传统软件开发强调结构化、模块化和流程确定性，通过定义函数、类、借口和工作流来实现功能。而“less structure, more intelligence”则是一种依赖”智能涌现“的设计思想：不预设 workflow 和 step，通过提供一个更强的智能内核（微调大模型）和更自由的执行环境（集成虚拟机），让AI自主探索和决定最佳路径。
这个想法现阶段还是较理想化，产品化的 Agent 交互很难做到这一点，即使真正能做到智能化，还需要考虑业务方是否能接收？用户渗透率如何？据业界的一个统计数字，依赖 wokflow 模式的场景占 Agent 模式的 90%以上。根据实战经验，即使 workflow 模式下 Agent 也避免不了各种产品的优化：COT和思考路径的展示、通过卡片和按钮等方式怎么限制用户和大模型、任务型异步工具执行完成怎么触达用户等等。
六、小结
啰嗦了这么多，但我觉得这些想法确实值得记录。2025年AI发展迅猛，该项目自3月启动以来，历经 MCP、A2A 等协议的推出，以及各类 Agent 框架的快速兴起，许多新技术的演进令人感同身受。接下来，我将结合具体业务场景，持续更新任务型 Agent 的设计细节，包括执行规划、工具设计、Prompt 调优等方面的实践经验。