Neal's Notes

从零构建论文背单词 Agent：LLM vs Agent vs 半自主

Properties1
tagspodcast, agent, blog

14分钟阅读

摘要：本文从一个真实的个人需求出发——「背论文里出现的高频学术词汇」——对比了 LLM 直接交互、全自主 Agent、以及半自主可控系统设计三种实现路径。我们讨论了 Agent 的核心能力（规划、执行、反思、记忆）与 LLM 的本质区别，并进一步探讨了在软件工程视角下，如何将「全自主」收敛为「半自主」：通过控制上下文环境（单词、论文）来实现可控性与智能性的平衡。最后，我们提出了一个从「全文本 + AI 实时检索」到「结构化语料 + 小模型蒸馏」的渐进式实现思路。

1. 背景：从一次「动嘴」的论文精选说起

这周末我花了大概十几二十分钟，用 MiniMax 的 Agent 功能做了一个 arXiv 论文精选的小前端。页面很简单：选择日期、定义关键词、调用 arXiv API 搜索论文，然后让 Agent 帮我翻译中文摘要和中文标题。整个过程中我一句代码都没写，只是和 Agent 交互，告诉它我要什么，它自己写代码、自己运行、自己调试，最后部署出一个能用的网页。

dudu学姐的观察：虽然你一句代码都没写，但你能清楚地告诉它「并发设置成 20」「帮我做一个测试 API 链接」，这说明你脑子里是有一个系统设计的。Agent 帮你执行，但架构还是你在想。

这个体验让我意识到：有了 Agent 之后，我们的工作流程正在发生变化。以前你想做一个论文精选工具，要么用别人的网站（但需求有 diff），要么自己写几百行前端后端代码。现在，动动嘴就能出一个能用的东西。

但随之而来的问题是：当需求变得复杂一些，比如「背单词」这种需要长期记忆、定时提醒、个性化词表的需求，LLM 和 Agent 的区别到底是什么？

2. 核心内容：从 LLM 到 Agent 的三种范式

2.1 LLM 模式：无情的回答机器

如果我们用 LLM 来背单词，交互是这样的：你发一个 prompt 说「我要背 apple 这个词」，AI 回复你「apple 的意思是苹果，a 像苹果的形状，p 和 p 像两只小手……」然后你再发「背 pear」，它再回复你 pear 的记忆技巧。

这个过程的本质是：每一轮交互都是独立的，上下文完全由用户手动提供。站在 AI 的角度，它收到的是用户输入的文本，回复完全基于聊天历史。你没法控制它的回复格式、交互形式，也没法让它记住「昨天背了哪些词、明天该复习哪些」。

LLM 就是一个无情的执行者：你要什么，它就给你什么。它不会主动思考「这个任务需要拆解成几步」，也不会自己去查资料、验证结果。

2.2 全自主 Agent 模式：从规划到反思

Agent 和 LLM 的本质区别在于：Agent 有自主权，它会把一个模糊的需求拆解成多步骤的计划，然后自己去执行、观察、反思、迭代。

回到背单词这个需求。如果我跟 Agent 说「帮我记一下这几篇论文里比较重要的单词，同时每天提醒我复习」，Agent 需要：

  1. 理解任务：它得先搞清楚「这几篇论文」是哪些，需要去搜索、获取论文内容
  2. 规划：它需要制定一个 AI 自己的 todo list——先查论文、再提取单词、然后设计复习计划
  3. 执行：调用工具（比如字典 API、日历 API）、自己写代码、自己运行
  4. 观察与反思：每一步执行完后，检查结果是否符合预期。如果找不到论文，它需要自己反思、调整策略，而不是直接回来找你
  5. 长期记忆：它需要记住你第一天背了哪些词、哪些是生词、第二天该复习什么——这超出了对话历史的范畴

整个过程就像是一个「乙方」：你只负责提需求，它自己搞定所有事情，最后通知你结果。而且它不只是今天通知你，明天还会主动提醒你复习。

dudu学姐的观察：你描述的这个 Agent 其实涉及多个 AI 角色协作——一个负责查论文、一个负责总结、一个负责日历提醒。它们各司其职，但对你来说是一个黑盒。

2.3 半自主模式：软件工程视角下的可控 Agent

全自主 Agent 听起来很美好，但如果你要把它做成一个真正的产品（比如一个背单词 App），问题就来了：完全自主意味着不可控。

假设你告诉 Agent「帮我找强化学习的论文」，它可能给你搜回来几千篇，消耗大量 token，而且结果不一定是你想要的。这时候，我们需要第三种方案：半自主 Agent——把一部分环境写死，一部分交给 AI 自主决策。

从软件工程的角度，人类角色需要分成两类：

  • 用户：只关心体验，底层的设计对用户无感知
  • 开发者：需要设计一个「既聪明又稳定」的系统

那么，在背单词这个场景里，用户最想控制的是什么？我们梳理出两个关键变量：

  1. 单词：用户不想让 AI 发散地推荐几百个单词，而是希望控制「我想背哪些词」
  2. 论文：用户不想让 AI 随便搜几千篇论文，而是限定「我只想学这几篇」

这两个变量构成了 Agent 的环境（context）——人和 Agent 共享的、可控制的上下文。在这个环境之外，AI 可以自主发挥：怎么提取单词、怎么设计复习计划、怎么生成记忆卡片。

我的判断：半自主模式的核心思想是——把「用户想控制的」写死，把「用户不在乎的」交给 AI。这样既保留了 Agent 的智能性，又保证了产品的可控性。

3. 反思：从「结构化数据」到「AI 自主检索」的范式转换

在讨论背单词系统的具体设计时，我们遇到了一个经典的「鸡生蛋还是蛋生鸡」问题。

第一种思路（传统工程化）：从左到右，先把数据源（PDF、网页）做预处理（分词、分句），然后做 NLU（自然语言理解）提取单词、段落、语境，再设计数据结构存储，最后做 UI/UX。这个思路的卡点在于：总结需要 AI，但 AI 总结很贵（token 消耗大），所以你得先筛选出值得总结的内容，而筛选又需要 AI 帮忙。

第二种思路（AI 自主检索）：从右到左，先不管数据结构，直接把所有文本（txt/json）存下来，用 grep 做关键词检索。用户查一个词，直接返回它在哪些句子里出现，然后让 AI 实时处理上下文。聊天时，AI 自己去全文里定位相关信息。

dudu学姐的观察：第二种思路听起来很「野」，但它其实对应了最近一篇论文的思路——让 AI 自己去查环境、自己找上下文，而不是人先把上下文准备好。我们算是手搓出了这个想法。

我的反思：这两种思路其实代表了两种不同的设计哲学。第一种是「人先把上下文准备好，再给 AI」，第二种是「AI 自己去环境里找它需要的上下文」。对于个人快速原型，第二种明显更快——你不需要花大量时间设计数据结构，直接全文本 + AI 实时检索就能验证核心功能。但如果你要上线一个高并发、高吞吐的服务，第一种的规范化和资源控制是必须的。

我们的结论是：先用第二种思路快速验证需求，拿到切分好的语料后，再回退到第一种思路做工程化——比如用这些语料做 embedding 强化、蒸馏一个小模型，实现低成本的在线服务。

4. 展望：Agent 系统设计的未来方向

从这次讨论中，我看到了 Agent 系统设计的几个趋势：

  1. 从「全自主」到「半自主」的收敛：未来的应用不会是完全写死的软件架构，也不会是完全放飞自我的 Agent，而是两者的中间态——环境由人和 AI 共享，人控制关键变量，AI 自主执行其余部分。

  2. 基础模型越强，LLM 和 Agent 的 gap 越小：当模型足够强大时，它天生就是一个 Agent——你给它一个模糊指令，它自己会拆解、规划、执行。到那时，LLM 模式和 Agent 模式的界限会越来越模糊。

  3. 系统设计依然不可缺失：即使 AI 能帮你写代码，如果你对背后的数据源、想控制的变量没有清晰思考，很容易被 AI 牵着走，搞出一坨乱七八糟的东西。一个优雅的设计，小应用写得简洁优美，大应用撑得住高吞吐高并发。

我的判断：背单词这个需求虽然简单，但它完美地展示了 Agent 系统设计的核心矛盾——智能性与可控性的平衡。未来，随着 Agent 能力的增强，这个平衡点会不断移动，但「人控制什么、AI 自主什么」这个问题，将始终是系统设计的核心。

我们下一步的计划是：先手搓一个粗糙版的原型，用「全文本 + AI 实时检索」的方式验证查询功能，然后再逐步工程化——设计数据结构、做 embedding、蒸馏小模型。如果大家有想讨论的，欢迎在评论区留言。

References

关系图谱

反向链接