Agent与LLM工程实践：从Tool到Skill的架构演进与安全加固

最近社区里关于 Agent 和 LLM 的讨论密度明显又上了一个台阶，尤其是"Agent 到底是什么""Skill 和 Tool 有什么区别""Harness 是干什么的"这类基础问题被反复问起。说实话，这轮讨论质量比前几个月高不少，至少大家不再停留在"Agent 能帮我写邮件"这种 demo 层面，而是开始认真琢磨架构、记忆、安全和评估这些工程问题。这篇日报式的整理，就是基于 2026-09-28 这一天的技术热词和社区讨论，把真正值得关注的东西挑出来，按主题拆开讲清楚，并补上我自己的实操理解和踩坑记录。

1. 热度解读：Agent 圈子里大家都在折腾什么

1.1 Agent 还是 LLM？两个关键词的边界正在加速模糊

最近热搜词里 Agent 和 LLM 几乎永远同时出现，这不是偶然。很多人把 Agent 理解为"会调用工具的 LLM"，但实操中你会发现这个边界越来越模糊。LLM 本身在做推理和生成，而 Agent 是把推理结果变成一连串动作的执行器。现在主流做法是拿一个大模型做"大脑"，配上工具调用、记忆模块、任务规划层，就拼出一个 Agent。

但真正值得关注的趋势是：Agent 不再只是 LLM 的包装。越来越多的 Agent 框架开始引入独立的状态管理、重试机制、子任务编排，甚至专门的动作空间。也就是说，LLM 只是其中一个组件，而不是全部。前两天有人问"AI Agent token 是什么意思"，其实指的就是 Agent 在运行过程中消耗的 token 总量——包括上下文输入、工具返回结果、多轮推理链上的所有 token。这个指标直接影响成本和响应延迟，做 Agent 的人一定得盯住。

我个人的判断是：未来半年，讨论的重心会从"Agent 能做什么"彻底转向"Agent 怎么稳定地做完一件事"。后者才是工程问题，也才是真正值钱的部分。

1.2 Harness、Skill、Tool：这三个词为什么最近总被一起提起

"Harness 和 Agent 区别"这个问题这次也上了热词榜。Harness 这个词最早是从语言模型评测里来的，指的是包裹在模型外面那层"控制框架"——它负责输入输出格式约束、工具调用循环、异常处理、日志记录，类似给 Agent 套了一层机械臂和运维系统。Agent 是逻辑核心，Harness 是让它可靠运转的外骨骼。

Skill 和 Tool 的区分也很实用。Tool 是单个具体能力，比如"搜索网页""执行 Python 代码"，接口固定、职责单一。Skill 更像是一个可复用的能力包，可能包含多个 Tool 的调用序列、提示词模板、参数默认值，甚至内置了一段执行逻辑。Claude Agent Skills 那篇 first principles 文章之所以被疯转，就是因为作者把 Skill 抽象成"带上下文的工具组合"，而不是简单的一层封装。理解这个区别，你在设计 Agent 时就不会把一堆 Tool 的调用逻辑全塞进 system prompt——那只会让上下文爆炸，而且极难维护。

2. Agent 开发学习路线与框架选型

2.1 初学者怎么切入 Agent 开发

每天都有人问"Agent 开发学习路线"，我给出的建议一直是三步走。第一步，先把一个裸的 LLM API 调明白，搞清楚 system prompt、few-shot、温度参数这些基本概念。第二步，用现成框架写一个能调外部工具的 Agent，体验完整调用循环。第三步，开始自己设计记忆和编排逻辑，把框架的手动挡换成自动挡。

这个顺序很重要，因为太多人一上来就扎进框架源码，结果被抽象概念淹没了。你在命令行里调一次 Claude 或 GPT 的 API，理解"模型输入输出都是文本"这一事实，远比背二十个框架概念有用。等你能写一个 Python 脚本让模型调用一次自定义函数，再去看 Agent 框架，那些概念会自然对号入座。

至于语言选择，Rust 写 Agent 的热度上升得很明显，原因无非是并发能力强、内存可控、单二进制分发方便。但我不建议初学者从 Rust 起步，Python 生态的迭代速度仍然最快。等你能用 Python 把一套 Agent 完整跑通，再评估要不要为性能和部署成本迁到 Rust。

2.2 主流 Agent 框架与编排思路

框架这块现在不是"选哪个"的问题，而是"知道每个框架的侧重点"的问题。有的框架侧重任务规划，适合流程相对固定的自动化场景；有的框架侧重自由对话和多工具并发，适合研究原型；还有一类轻量级框架只提供 Harness 层，几乎所有的编排逻辑都留给你自己写。选型的判断标准主要有三个：一是你对调用链路的可控程度要求，二是社区维护活跃度，三是是否支持你需要的那几个关键工具。

我在实际项目中倾向于"框架只做 Harness，业务逻辑自己做编排"。原因很简单：框架内置的编排逻辑一旦复杂起来，出了问题非常难排查，而 Agent 系统本身就是最容易出隐蔽故障的系统之一。你把工具调用规则、重试策略、记忆读写这些事掌握在自己手里，虽然在初期会多写点代码，但后续迭代和 Debug 的体验完全不一样。

2.3 从零搭一个"能干活"的 Agent 需要几步

这里给一个最小可跑的方案。选一个支持工具调用的模型 API，定义一个函数列表，里面放两三个工具，比如"计算器""网页检索""读取本地 Markdown 文件"。模型在回复中会输出一个结构化工具调用请求，你的代码负责解析它、执行函数、把结果以 role=tool 的消息追加回去，再让模型基于结果继续推理。这个"模型尝试调用工具，带结果回来继续推理"的循环，就是 Agent 的核心引擎。

跑通这个最小循环后，接下来要加的是三样东西：任务上下文管理（记录目标、进度、已完成步骤）、错误重试策略（工具超时或返回异常时的处理）、以及输出校验（防止模型输出格式漂移）。这三样才是 Agent 从"能跑"到"能干活"的关键，也是所谓"自主容错控制"的雏形。工程上的可靠 Agent 系统，本质上就是在这三层做加固，而不是一味堆模型推理能力。

3. Agent 记忆与上下文工程：从"失忆"到"靠谱"

3.1 记忆的分类与工程实现

Agent 记忆这个话题最近讨论量很大，主要原因是大家发现，没有记忆的 Agent 做多轮复杂任务时会反复犯同样的错。记忆在工程上一般分三层：短期记忆是当前会话内的上下文窗口，工作记忆是任务执行过程中的中间状态和中间结论，长期记忆则是跨会话持久化的知识，通常存在向量数据库或结构化存储里。

实操中最容易翻车的其实是"什么该记、什么不该记"。很多人一开始会把所有对话记录和工具结果全部塞进上下文，结果 token 消耗暴涨，而且无关信息会严重干扰模型判断。我的做法是给记忆加"标签"和"有效期"：任务目标、完成状态、关键决策理由属于必须持久化的；临时工具输出、中间推理过程属于短期记忆，任务结束就清理。另外，记忆写入时要顺带做摘要，用一次模型调用把长对话压缩成几条要点，再存进长期记忆库，比直接存原文可靠得多。

3.2 聊天记录模型精调：被低估的杠杆

"使用聊天记录模型精调 LLM"这个热词背后是一个很实在的需求：你有一个 Agent 系统在真实运行，积累了成千上万条人机对话记录，这些记录里有大量"用户如何表达需求、模型哪一步答错了、用户怎么纠正"的真实样本。拿这些数据做有监督微调，模型在特定场景的表现会比通用模型明显提升。

需要注意，精调用的聊天记录不是原始日志直接丢进去。必须先做清洗：去重、过滤低质量回复、把涉及隐私的信息脱敏、标注哪些回合是用户明确不满的。如果数据里混入了大量失败的中间步骤，模型会把那些错误模式也学进权重里，效果反而更差。我见过一个项目，精调之后工具调用格式错误率从 8% 降到了 1.5%，就是因为训练数据里只保留"最终成功路径"的对话片段。这个项目的教训是：数据质量对精调效果的影响，比模型大小和训练轮数都大。

3.3 元评论残留（Meta-comment 残留）是怎么回事

"LLM 元评论残留"是个很刁钻的问题，但做 Agent 的人迟早会遇到。它指的是模型在某些输出里夹带一些本不该出现的"内心独白"或"元评论"，比如在回复中间突然写一句"我应该先调用工具获取最新数据再回答"——这本来是模型推理过程中的话，却混进了最终输出。

这种残留对普通对话影响不大，但在 Agent 场景里是致命的，因为下游可能用正则或者结构化解析去提取模型输出字段，一句多余的评论就能让解析失败。常见原因有三个：训练数据里混入了思维链内容、prompt 里同时要求"先思考再回答"和"直接输出结果"导致模型边界混乱、解码策略采样温度过高导致输出漂移。解决办法是：在 prompt 里用明确的输出格式约束，必要时用输出解析层兜底，把不符合预期格式的回复自动重试一次。

4. Agent 安全与可靠性：别让你的智能体被投毒

4.1 AgentPoison：通过记忆与知识库投毒的红队攻击

这次热词榜里的 AgentPoison 是一篇相当有分量的红队研究，核心攻击路径是通过污染 Agent 的记忆库或知识库来劫持行为。原理其实不复杂：Agent 在检索记忆或外部知识时，会把检索到的内容当作上下文交给模型。如果攻击者能在知识库里埋入精心构造的恶意文本——比如一段看起来很正常、但包含隐藏指令的内容——模型就可能把这段内容当作新的行为准则来执行。

防御思路也相对清晰。第一，知识库写入权限必须严格管控，尤其是共享知识库和开源数据源；第二，检索结果在进模型之前，要做独立的内容安全过滤，不能直接信任；第三，对 Agent 的关键动作（比如调用外部工具、修改配置文件）设置权限校验，别让模型自己在无监督状态下执行高风险操作。这里我多说一句：很多小团队在做 Agent 时完全没有安全预算，就这么把知识库直接挂到了公网上，这等于把自己的智能体大门敞开。

4.2 自主容错控制：构建可靠 AI 系统的工程实践

"识的 LLM 智能体自主容错控制"稍微有点绕，核心意思其实就是：让 Agent 在出错时能自己发现问题并恢复，而不是直接崩溃或给出错误结果。工程上落地无非是几种手段——输入输出校验、执行过程监控、分级重试、以及决策回退到人工审批。

我分享一下自己的容错分层设计。第一层是格式校验：模型输出如果不满足预期结构，直接重新生成，最多重试三次。第二层是行为校验：设置规则引擎，检查 Agent 是否在尝试执行危险操作，比如删除文件、调外部付费接口等，命中就拦下。第三层是结果一致性校验：如果一个任务的执行结果明显违背初始目标——比如用户要的是"汇总报告"，Agent 却生成了代码——就触发任务回滚，重新规划。这套机制可以让 Agent 的失败率明显下降，代价是开发和调试成本更高，但做生产级系统，这笔投入省不了。

4.3 "LLM request failed"这类故障的排查思路

热词里出现"llm request failed: provider rejected the request schema or tool payload"，这是调用模型 API 时特别常见的报错，含义是服务端拒绝了请求，原因通常是 JSON Schema 格式不合法、工具参数里的类型定义与模型要求不匹配，或者某个字段值超过了最大长度限制。

排查路径一般是这样的：先把请求体完整打印出来，到 API 平台里直接试一遍，看是不是必填字段缺失。如果工具定义是程序生成的，检查一下 JSON Schema 里的 $ref 引用有没有形成循环引用，这个坑我踩过几次，一旦有循环引用，模型服务端的解析直接失败。再一个容易忽略的是"模型版本与工具调用能力不匹配"，并不是所有模型参数都支持 function calling，或者不同版本对工具数量的上限不一样，量一多请求也会被拒。我的建议是，这类报错不要只看日志尾行，要把请求体保存下来做单元测试，一次性把格式问题清零。

5. 工具链与本地化部署实战

5.1 本地跑 LLM：GGUF 格式和安卓端实测

GGUF 格式现在基本是本地 CPU/GPU 推理的事实标准，它把模型权重、分词器、元数据打包成一个文件，配合 llama.cpp 系推理后端可以直接跑。这次热词里"安卓本地运行 GGUF 格式 LLM"说明移动端本地推理的需求正在起来，涉及到的核心指标有三个：模型量化等级（Q4_K_M 这类）、上下文窗口大小、以及设备内存上限。

我的实测感受是：在同时支持安卓 8 的设备上，跑 7B 级别的量化模型，体验大概能做到"可用但不流畅"，纯 CPU 推理生成速度在 3-5 token/s 之间。如果任务不复杂，比如做笔记整理、短文本分类，这个速度够用。但千万别指望手机端本地模型能做复杂 Agent 任务，一是上下文窗口撑不住，二是工具调用链路对延迟太敏感。移动端本地 LLM 的现实价值是隐私敏感场景和弱网环境，这一点要想清楚再决定投入多少精力。

5.2 LLM as Judge：让大模型当裁判的正确姿势

"LLM as Judge"已经是评测 Agent 和 LLM 输出质量的主流方法。核心思路是用一个大模型当裁判，给被测模型的输出打分。它的前提假设是：裁判模型有能力区分回答质量高低。但这个假设不总成立，尤其是被评测内容和裁判模型本身能力领域高度重合时。

用 LLM 当裁判有几个实操要点。第一，给裁判的评分标准必须具体，包含维度、分数锚点、示例，不能只写一句"请打分"。第二，裁判的 prompt 里不能放参考输出太详细的内容，否则会变成"复述题"而不是"判断题"。第三，要对裁判结果做一致性检测——同一个问题打两遍，如果两次分数波动大，说明评分标准不清晰。我一般在项目里会拿少量人工标注样本去校准裁判 prompt，等一致性达到 0.9 以上再放量跑，避免在无效评测上浪费 token。

5.3 用 LLM 生成单元测试：能省力但得设好护栏

"基于 LLM 的单元测试"算是 LLM 在研发效能领域最接地气的落地场景。实际操作就是把函数签名、依赖关系、几个典型输入输出样例喂给模型，让它生成 pytest 或 JUnit 测试代码。效果确实能看：简单函数生成测试的覆盖率能达到 70% 以上，极大节省程序员写重复用例的时间。

但护栏必须提前设好，我踩过的坑主要有两个。第一，模型生成的测试有时包含对内部实现细节的断言，重构代码后测试就直接挂，这种测试的维护成本反而比手写更高。所以生成完一定要人审，把"测试意图"从"实现细节"里剥离。第二，模型会给同一个函数生成风格完全不同的测试，团队里如果没有统一的断言命名和风格规范，测试库会变成大杂烩。我的做法是给生成插件配置一层风格约束模板，让所有测试统一结构，可维护性立刻上一个台阶。

5.4 命令行编码代理：当 Agent 走进终端工作流

Codex 这类命令行编码代理把 Agent 能力搬进了终端，能直接完成"读代码、改代码、跑测试、再提交"的完整闭环。关键在于它不再是一个聊天气泡，而是和 Git、编译器、文件系统直接打交道的执行体。这意味着容错要求提升了好几个数量级——一个错误的代码修改可能导致构建直接挂掉。

我试用下来的体感是：它最适合"机械性重活"，比如批量重命名、跨文件格式统一、补充重复性测试用例，效率提升非常明显。但在需要全局理解架构的改动上，它仍然需要人给出非常明确的边界描述。另外一个经验是，任何传给命令行编码代理的任务描述里，都要明确写上"禁止修改哪些文件、禁止执行哪些命令"这类负面约束，否则它可能会在"完成任务"的目标驱动下做出让你意外的操作。

6. 现场问答与避坑清单：这一轮讨论里的高频问题

6.1 常见问题速查表

结合这次热词榜和社区问答，我整理了一张高频问题速查表，基本覆盖了 2026-09-28 这波讨论的绝大部分疑问。

6.2 这几周踩过的几个坑

第一个坑是过度相信"模型自己的记忆能力"。早期我做过一个 Agent，指望模型靠上下文窗口记住所有中间状态，结果任务一长，模型开始"选择性遗忘"，把已经确认过的信息又拿出来重新问用户。后来改成显式状态管理，每个步骤的结果都写进状态对象，不依赖模型记忆，才彻底解决。

第二个坑是 Agent 的工具返回结果不加长度限制。某个工具返回了一个超长的网页提取文本，直接把上下文窗口撑爆，后续所有对话都变得极其迟钝。现在我在工具层统一做截断和摘要，控制单次返回不超过几千 token，效果立竿见影。

第三个坑和安全相关：知识库里的文档来源没做隔离，导致检索时把不太可信的个人笔记和权威文档混在一起，Agent 被带偏。后来给知识库的每一条数据都加了来源等级标签，Agent 在援引信息时会优先采信高等级来源，问题基本消失。

6.3 "抄作业"清单：从零搭建一个基础 Agent 的工作流

如果你看了这么多还是想直接上手，我这里给一份可复制的清单。第一，用官方 API 跑通一次带工具调用的最小循环，记下返回结构。第二，写两个自定义工具函数，一个做信息检索，一个做数据计算，注册到工具列表里。第三，加一个任务状态对象，存放目标、已执行步骤、下一步计划。第四，补一层输出格式校验，不符合预期的回答直接重试。第五，把多个工具按业务逻辑组合成 Skill，封装成可复用的函数。

这套工作流做完，你对 Agent 的认知会比看一百篇文章都扎实。接下来的方向就看你自己的业务场景：要接更多工具就搞工具生态，要解决多轮一致性就搞记忆，要上线见用户就必须补安全和评测。从 2026-09-28 这个时间节点往回看，Agent 不再是"聊聊天调调工具"的实验品，它正在变成一个需要完整工程体系支撑的生产系统。每一步都踩实，比追任何热点都重要。