企业官网建设流程全解析

早上在技术社区看到一个帖子：“Agent 到底是不是又一轮概念炒作？”底下吵了几百楼。吵到最后基本都集中在一个点上——大家说的 Agent 根本不是同一个东西。今天的热搜词里，agent框架、agent记忆、agent安全、harness和agent区别同时冒出来，恰恰说明这个领域已经过了“拿个 Demo 证明 LLM 能调用工具”的时期，开始进入分层成熟的深水区：有人做编排，有人做记忆，有人攻防，有人在兜可靠性。这篇 Agent / LLM 技术精选日报，就是按这个思路把今天值得看的内容分成五块来拆：框架选型、可靠性工程、安全攻防、工具链落地、学习与排错。每一条除了讲清楚是什么，还会给出我自己的判断和可以直接复用的实操方案，不掺水。

1. 今日风向：从热搜词看 Agent 生态的五个变化

1.1 热搜词背后的技术分层

热搜词天然是大家焦虑和好奇的投影。我今天把几十个词归了一下类，发现可以很清楚地分成五层：框架层（agent框架与编排、spring ai agent、adk.dev kotlin）、架构层（agent记忆、claude agent skills、harness和agent区别）、安全层（agent安全、agentpoison）、工程层（ai agent 怎么扛并发、自主容错控制）、应用层（安卓本地运行gguf、hermes agent obsidian、agent画图）。

这个分层本身就是信号：生态已经从“一颗 LLM 走天下”，变成了一整套需要各司其职的技术栈。下面这张表可以帮你快速对号入座，看看自己当前关心的问题属于哪一层，该去查哪类资料。

我习惯用这张表来过滤信息：如果你问的是“哪个框架好”，那属于框架层的选型问题；如果你问的是“Agent 老是不听指挥”，那多半是架构层或工程层的问题。问对层次，找答案的效率能翻倍。

1.2 三个值得在意的信号

第一个信号是可靠性取代 Demo 成为主战场。AI agent 怎么扛并发、自主容错控制、agent execution terminated due to error 这类词的热度，说明大家已经不再满足于“能跑通”，而是开始问“生产环境能不能扛住”。这和前些年后端领域“从能跑变成能扛”的路径一模一样，是技术走向成熟的必经阶段。

第二个信号是记忆和技能正在被标准化。agent记忆、agent skill、claude agent skills 密集出现，说明架构层的概念开始收敛。记忆不再是某个框架的自创功能，技能（skills）也在变成跨框架的通用描述方式，后面细说。

第三个信号是运行边界在扩张。安卓本地运行 gguf 格式 llm、hermes agent 挂在 obsidian、agent anywhere、spatial llm 这些词，说明 Agent 不只在云端 API 后面跑，也开始往终端、笔记工具、本地算力甚至物理空间上渗透。部署形态越多元，工程问题的复杂度就越高，这也是为什么我今天把可靠性和安全单独拿出来讲。

2. 框架选型与 Agent 架构：先分清 Harness 和 Agent

2.1 Harness 和 Agent 的区别：很多人第一步就混了

我见过最多的认知混淆，就是把 Agent 和它的运行框架混为一谈。简单说：Agent 是那个“做决策的大脑”，它由大模型、系统提示词、记忆、工具调用能力组成；而 Harness 是承载这个大脑的“外壳与骨架”，负责控制循环、事件调度、上下文管理、错误处理、状态持久化这些脏活累活。

类比一下：Agent 是司机，Harness 是车。司机负责看路、判断、变道，车负责提供转向、刹车、仪表盘和安全气囊。你换个司机（换模型），车不用重造；你换辆车（换 harness），司机也能接着用。概念分开之后，很多工程问题就有了清晰归属：“Agent 乱说话”是大脑的问题，得从提示词、模型选型、记忆管理入手；“流程跑到一半崩了”是骨架的问题，得从 harness 的重试、超时、状态恢复机制入手。

今天热搜里问“harness和agent区别”的人不在少数，我建议所有刚开始做 Agent 的人先把这层窗户纸捅破。不然后面调 bug 的时候，你会一直在错误的一层找原因，事倍功半。

2.2 ADK Kotlin 快速上手：在 JVM 上跑通一个 Agent

adk.dev 被搜上热词，说明不少人想在 JVM 环境里快速验证 Agent。Kotlin 版本的 ADK 思路其实很简单：把 agent 定义成“配置 + 工具集 + 模型回调”，剩下的控制循环由 SDK 接管。

跑通一个最小 agent 大概分四步：引入依赖；定义 agent 并绑定模型；注册工具函数；启动会话跑一句 query。代码骨架长这样（以你拉到的 SDK 版本为准，这里为了讲清思路做了简化）：

val agent = adk.agent { name = "demoAgent" model = "openai/gpt-4.1" // 取决于你配置的 provider tools += listOf(::queryWeather, ::readFile) } val session = agent.newSession() val reply = session.run("杭州明天适合穿什么出门？")

重点不是背 API，而是理解三件事：模型用哪个、给 agent 暴露哪些工具、上下文怎么传递。这三件事想清楚，换任何框架都能快速上手。

在 JVM 上跑 Agent 的好处很实际：能和现有 Java 服务共用一套基础设施，用 Spring 管理工具实例、用 Redis 存会话状态、用已有监控体系盯调用链。今天另一条热词 spring ai agent，其实是同一个诉求的另一种解法——它把 agent 塞进 Spring 生态，工具函数标一下注解就能被模型调度。如果你在纯 Java 技术栈的团队里推 Agent 落地，这两条路都比另起炉灶平滑得多。

2.3 Rust 系 Agent 与“轻量优先”的工程哲学

Rust 系 Agent 的讨论今天也上了榜。大家聊 Rust 不是图语言时髦，而是图它三个硬指标：启动速度快、内存占用可控、并发模型扎实。Agent 如果要做成常驻进程、边缘部署或者高频工具调用，解释型方案会出现明显的资源浪费。

一个 Rust 写的 agent 二进制可能只有 10MB 上下，启动时间毫秒级，对冷启动敏感的调度场景非常友好。代价是开发周期长、生态相对薄、招人成本高。我的建议是：如果 Agent 是你产品的外围能力，用 Python 或 TypeScript 快速迭代；如果 Agent 是产品的核心引擎，且对延迟和成本极度敏感，值得认真考虑 Rust。

2.4 Agent Skills：从 Claude 的第一性原理说起

今天 claude agent skills 相关的深度文章被转得很猛。skill 这个概念，本质是把“这个 agent 会做什么、怎么做”封装成一段可复用的声明式能力，而不是把逻辑硬编码进提示词。

第一性原理地看：Agent 真正需要的是“知道自己有哪些能力、在什么条件下该调用什么能力”的元认知。Skills 就扮演这个索引。比如你有一个“PPT 生成 skill”，定义里写清楚触发条件、输入格式、输出规范，agent 在遇到“帮我做一份汇报材料”时，就知道该加载这个能力而不是自己乱编。

今天另一条 agent skill 教程的热度，说明不少人已经开始在自己的框架里搭这一层。我的经验是：定义 skill 时最忌讳写得像小说，触发条件、输入 schema、输出 schema、失败处理四件事写清楚就够了，多了反而是噪音。

3. 可靠性工程与安全：可靠 AI 系统不是靠抖机灵

3.1 自主容错控制：别再写裸的“重试三次”

今天有一条非常硬的实践经验贴，讲 LLM 智能体自主容错控制，标题直译就是“构建可靠 AI 系统的工程实践”。很多人在生产里跑 agent 之后第一个崩溃点，就是发现错误率根本压不住：模型偶尔输出非法 JSON，工具偶尔超时，上游偶尔限流。

如果容错就写一个 for 循环重试三次，那跟没写差不多。工程化的容错需要分四层做。

第一层是输入 schema 校验。模型输出进来先按 JSON Schema 校验，不合格就带着错误信息回灌给模型让它自纠，而不是直接崩溃。第二层是工具调用层，每个工具都要有超时、重试、熔断，并且是独立预算，一个工具被限流不能拖垮其他工具。第三层是编排层，每一步落一个状态快照，崩了可以从上一步恢复，而不是整个任务重来。第四层是兜底层，用看门狗监控整个 Agent 循环有没有死锁或无限循环，超过步数上限直接终止。

这四层里我特别想强调编排层。Agent 的执行链路是有状态的长流程，如果每一步的结果都存了快照，那么任何一步失败都可以“断点续跑”。这是把 Agent 从玩具变成生产级系统的分水岭。今天热搜里那条 agent execution terminated due to error，绝大多数时候就是兜底层把陷入死循环或资源耗尽的执行熔断了。先看日志里循环了多少轮，比瞎猜“模型智商不够”靠谱得多。

3.2 AgentPoison：当恶意内容藏进记忆和知识库

安全方向今天被 agentpoison 这个话题带起来了。研究方向是用红队视角验证 LLM Agent 的记忆和知识库投毒风险：攻击者不直接碰模型，而是在知识库、记忆模块或检索语料里预埋精心构造的片段，等 agent 检索时被“带偏”，从而诱导出错误决策。

这和传统提示词注入不一样，它走的是 RAG 链路，更隐蔽，更难被发现。理解这类攻击不是为了去学攻击手法，而是为了建立防御：第一，检索源要分级做可信度管理，不可信来源的内容只能作为参考，不能参与关键决策；第二，重要操作增加二次确认，让用户或人工介入把关；第三，对检索结果做一致性校验，同一个问题多个来源回答矛盾时，要能触发告警。

再过半年，agent 安全大概率会成为和 Web 安全一样常规的工程议题。现在就开始把“来源可追溯、变更可审计”这种习惯养起来，成本最低。

3.3 AI Agent 怎么扛并发：瓶颈不在代码，在编排

“ai agent 怎么扛并发”是今天出现频率很高的提问。答案比大多数人想得朴素：瓶颈几乎永远不在 Agent 自身的代码，而在三处——LLM 服务的限流与延迟、工具调用的外部依赖、以及有状态会话的存储。

扛并发第一原则是把 Agent 做成无状态 worker：对话历史和上下文放到 Redis 这类外部存储，worker 实例随时可以水平扩容。第二原则是排队而不是直接死扛：外部模型服务有 RPM 和 TPM 限制，直接并发打上去只会得到一堆 429，正确的做法是任务进队列，worker 按预算消费，用消息队列的积压量来做背压。第三原则是每个工具调用都要有超时和熔断，一个外部 API 挂了不能拉着整个 agent 陪葬。

可以把 Agent 服务想象成餐厅出菜口：厨师（模型）做菜速度固定，客人（请求）再多也不能让厨师同时炒十个菜，只能排队、按序出菜。厨房里每个灶台还要装保险丝，一个灶台短路不能烧了整个厨房。这套设计做完，扛几千路并发不是什么玄学，就是朴素的事件驱动加水平扩展。

4. 工具链与落地场景：从命令行到口袋里的模型

4.1 Codex CLI：OpenAI 把编码 Agent 塞进了终端

OpenAI 的 Codex 命令行编码 Agent 这两天的热度一直在涨，用 ChatGPT 账号登录就能在终端里让它在仓库里干活。对开发者来说，这意味着基于 Agent 的编码助手从网页聊天框进入了一个更自然的形态：直接在仓库目录下跑，它自己读代码、定位问题、生成修改、跑测试，全程留在终端里。

我的实测感受是，这类 CLI Agent 最适合三类活：陌生仓库结构梳理、跨文件重构的初稿、测试代码补齐。但别指望它直接交付可上线的完整功能，它给出的 diff 必须人工 review。把它当结对编程的 junior 伙伴，而不是当甩手掌柜，效率提升反而最明显。

4.2 Hermes Agent + Obsidian：把笔记变成 Agent 的工作台

Hermes Agent 这两天的教程热度和 obsidian 的组合一起涨。这个组合的逻辑很有意思：Obsidian 里存的是你的笔记、知识库、任务清单，Hermes Agent 通过插件把笔记目录变成 agent 的上下文来源，既能检索已有笔记回答问题，也能把 agent 生成的产出写回笔记。

本质上是用本地知识库给 agent 做记忆外挂，隐私性比丢到云端好得多。搭建不复杂：把 Obsidian 本地库挂成 agent 的工具（读 vault、写 vault、搜索），然后在系统提示里写明 vault 目录结构和写作风格规范就行。

第三方工作台的陆续出现也值得关注，说明这已经不只是一个个人玩具，而是有人在拿它搭私人知识工作流。注意备份策略要提前定好，agent 批量写笔记的能力很强，一旦写错方向，恢复比手工编辑麻烦得多。

4.3 安卓本地跑 GGUF：纯本地推理的另一条路

安卓本地运行 GGUF 格式 LLM 软件这个话题，背后是“Agent 不一定要在云端跑”的趋势。GGUF 是目前本地推理事实上的通用格式，llama.cpp 生态的模型基本都提供 GGUF 版本。

在安卓上跑，优先找支持量化模型和 GPU/NPU 加速的推理应用，模型优先选 4bit 量化（比如常见的 Q4_K_M 级别）。7B 级别的模型在 8GB 内存的设备上勉强能跑，体验离云端 API 还有差距，但胜在完全离线、延迟稳定、数据不出设备。如果你是做垂直场景的个人工具，比如本地笔记助手、离线翻译，这条路值得留个心眼。

今天的 agent anywhere 这个词，其实就在描述同一个趋势：Agent 的运行边界正在从云端 API 扩散到手机、PC、车载甚至更小的设备上。我判断未来一年，“跑在哪里”会和“模型选哪个”一样成为架构决策的必答题。

4.4 Agent 画图与多模态能力

“agent画图”能上热搜，说明多模态方向也开始往 agent 形态迁移。多模态模型让 agent 不只输出文字，而是能调用绘图模型、图像编辑工具生成图片。

做这类 agent 的时候，重点不是调一个画图接口，而是把用户意图拆解成三层：绘画提示词生成、参数选择、出图后校验。用户说“可爱的猫”和“赛博朋克风格的猫”差距巨大，意图解析做不好，出图质量就完全不可控。多模态也是 spatial llm 这类研究方向能落地的载体，未来 agent 在空间理解、地图导航、物理世界交互上的应用，想象力比单纯聊天大得多。

5. 学习路线与常见问题速查

5.1 Agent 开发学习路线：别一上来就学编排

关于 agent 学习路线、agent 开发学习路线的搜索一直不少，可见新人入口的焦虑还在。我给一个不绕弯的路线，分四阶段。

第一阶段先搞懂 LLM 本身：token 是什么、上下文窗口怎么回事、function calling 的 schema 怎么定。第二阶段做单 Agent：把工具注册、记忆挂载、错误重试跑通。第三阶段才考虑多 Agent 与编排：搞清楚什么时候该拆子 agent，而不是单纯加提示词。第四阶段补工程课：评估体系、可观测性、安全、成本控制。

很多人一上来就学编排框架，结果连单 Agent 都还没跑稳，这是最常见的弯路。另外，今天 llm wiki 这类整理型资源也被大量转发，新手可以按图索骥，但别被资料淹没了动手时间——跑通一个最小 agent 比读十篇文章都管用。

5.2 今天重复率最高的三个问题

把今天社区里反复出现的报错和疑问整理成一张速查表，直接对照着排查。

第一个报错是今天评论区出现最多次的。遇到它别急着怀疑模型，先看是不是 harness 层的兜底熔断被触发：循环超过步数上限、某个工具重试耗尽、会话存储超时。把这些参数调大不一定对，关键是看日志确认它在哪一步终止的。

第二个报错是我自己踩过无数次的坑。模型端到端调用工具时，payload 必须严格符合你注册的函数 schema。最常见的翻车点是枚举值写错、必填字段缺了、数组里嵌套了非法值。建议在注册工具之前先用 JSON Schema validator 自检一遍，并把模型的原始 payload 打进日志，排查时会省很多时间。

第三个问题来自刚入门的朋友。token 是模型处理文本的最小单位，一个中文词大概对应 1 到 2 个 token。Agent 比普通聊天耗 token，是因为每次工具调用都要把“对话历史 + 工具返回结果”重新发给模型。控制 token 的核心手段就是精简上下文：只带最近几轮、按需检索记忆、工具返回做截断。

5.3 聊天记录精调、LLM 单元测试与 LLM as Judge

今天还有几条技术向内容值得单独提。第一条是使用聊天记录精调 LLM：把真实用户会话转成训练样本，能让模型更贴合你的产品语境。但直接拿原始聊天记录训练会翻车，必须做数据清洗——去隐私、去低质量回复、统一格式、做角色对齐。

第二条是 LLM 单元测试和 LLM as Judge。用 LLM 生成单元测试用例很顺手，但断言逻辑最好还是人来写，或者再叠一层 judge 模型做语义评估。要注意 LLM as Judge 不是银弹，它有自己的偏好和位置偏差：同一个回答在两组答案里换一下顺序，评判结果可能就不一样。做评测时要固定模板、多次采样取多数票，别拿单次结果当结论。

整理完今天这一堆信息，我个人的体会是：Agent 领域现在最稀缺的不是新框架，而是能回答“崩了怎么办、贵不贵、能不能并发、数据安不安全”的工程答案。热搜词里工程向提问变多，说明行业正在从兴奋期进入建设期，这对认真做事的人是好事。最后分享一个我一直在用的整理方法：遇到问题先判断它是结构性问题还是参数性问题——框架选型、架构设计属于前者，值得花整块时间想清楚；报错、参数、超时属于后者，直接查文档验证就行。这个分类习惯能帮你省掉大量没意义的纠结。明天这份日报继续更新，我会接着挑能直接落地的内容写。