一、LLM Agent 的架构与执行流程
最近 AI 编程领域涌现了许多非常实用的 Agent 工具，比如写代码的 Claude Code、Codex、Kimi Code 以及各类”龙虾”工具。通过一些文章了解到，这些 Agent 的整体架构主要由以下模块组成：
- LLM（大语言模型）：作为核心推理引擎；
- Function Call（函数调用）：让模型具备与外部工具交互的能力；
- 存储（上下文记忆压缩）：管理对话历史和上下文信息；
- 任务编排：协调多个步骤的执行顺序。
标准执行流程
- 用户输入首先经过 System Prompt 进行修饰；
- 修饰后的内容发送给大模型；
- 大模型返回封装为标准格式的响应内容。
响应内容的分类
响应内容可以分为以下两种类型：
类型一：直接展示
大模型的响应内容直接在聊天窗口中展示给用户。
类型二：函数调用（Function Call）
表示需要调用外部工具来执行具体操作，常见的操作包括：
- 读取文件
- 写入文件
- 文本替换
- 调用外部 API
- 调用 WebFetch（网页抓取）
二、一次”类 Agent”的早期实践——语音助手
了解 Agent 的执行流程后，我回想起在 ChatGPT 刚出现的时候（大约是 2022 年或 2023 年），我曾为公司产品做过一个类似的自动化执行 Demo——语音助手。
业务背景
我们的场景是：在查词结果页植入一个语音助手。所谓查词结果页，就是用户搜索英文单词后，展示英文发音、美式发音、中文释义以及例句等内容的页面——这是一个功能相当复杂的页面。
语音助手的核心功能
我为语音助手定义了三个主要功能：
- 发音功能
用户说”发音”，App 自动调用 TTS 发音接口播放单词。 - 查询功能
用户说”帮我查询苹果怎么翻译”，App 识别指令后自动查询对应单词。 - 页面控制
用户说”向下滚动”，页面自动向下滚动一定距离。
设计初衷
我们希望实现的业务目标是：让学生处于沉浸式学习状态，用最少的操作完成目标功能。
举个例子——用户想查询”苹果”这个单词：
传统操作：拿起手机 → 聚焦输入框 → 输入”苹果” → 点击搜索。整套流程会打乱学习节奏。
我们的方案：借助语音识别 + 大模型，让用户通过语音驱动 App，最大程度减少对沉浸式学习的打断。
三、语音助手的技术实现逻辑
语音助手的设计逻辑，与今天 Agent 的理念其实不谋而合。
格式化指令设计
我给语音助手设计了一套格式化的指令体系：
1. 查询与翻译
- 当用户说”帮我查询什么”或”帮我翻译什么”，大模型返回的数据类型为
Query； - 返回内容中包含用户具体要查询的项目（如”苹果”）；
- App 接收到响应后，判断类别为
Query，随即调用内部搜索模块执行查询。
2. 朗读与播放
- 当用户说”朗读某内容”或”播放某内容”，大模型返回的数据类型为
Play； - App 拿到响应后，调用内部 TTS 接口播放当前单词。
3. 页面滚动
- 当用户说”向下滚动”或”向上滚动”，大模型返回的数据类型为
Scroll； - App 解析到
Scroll指令后，调用页面相关函数控制滚动。
核心逻辑
整体流程可以概括为：
接收大模型响应 → 通过
if-else判断响应类型（发音 / 查询 / 滚动）→ 调用 App 当前页面的对应功能执行操作
这和今天 Agent 的逻辑完全一致——都是根据大模型的响应，来判断并执行下一步操作。
四、回顾与反思
这个功能最终没有上线，回想起来确实有些可惜。
当时的原因
- 产品评估：产品侧认为该功能的意义不够大，因此没有推进上线；
- 认知局限：我们当时对这项技术的想象空间认识不足，没有看得更远。
今天的视角
现在回看，无论是手机上各种自动化操作，还是形态多样的 Agent 工具，其底层逻辑都与我们当年的语音助手高度相似。如果当时能有更深入的思考和更广阔的视野，也许能做出一些不一样的东西。
这篇文章记录了我对 LLM Agent 的理解，以及一段与之相关的早期实践经历。技术的演进往往有迹可循，很多”新概念”其实早在我们过往的尝试中就已经埋下了种子。
发表回复