企业官网建设流程全解析

今天的Agent/LLM技术圈相当热闹。我把知乎、GitHub、Reddit几个阵地上关于 agent 和 llm 的热搜词扫了一遍，发现大家关注的点已经从“Agent怎么搭一个demo”，全面转向“怎么把Agent做稳、做安全、能并发、能落地”。这篇日报，我会把这些热搜词按框架选型、核心概念、工程踩坑、安全边界、学习路线几个维度拆开讲，尽量把每个词背后真正值得花时间研究的东西说明白，而不是停留在名词本身。如果你近期在入门Agent开发，或者正在为自己的项目做Agent选型、排障、加护栏，这篇应该能帮你省下不少试错时间。

1. 今日速览：Agent/LLM 圈都在看什么

先把今天的高频词拉一张分类表，这比逐个解释名词有用得多。你会发现，相当一部分热搜词其实是在问同一件事的不同侧面。

日报的筛选逻辑也很简单：只挑能沉淀出方法论的热词，不追跟风词。像“llm是什么”“agent是什么”这类问题，我会直接放到概念部分一次性讲清楚；“codex无法发送消息”“llm request failed”这种报错现场，则放到踩坑章节给排查思路。下面正式开始。

2. 核心概念拆解：LLM 的 token 三要素与 Agent 的本质

2.1 Key/Query/Value：AI 注意力机制到底在做什么

今天有个热词概括得非常传神：“llm的token三个点——key我是谁、query我在找什么、value我能提供什么”。这其实说的是Transformer自注意力机制里的Query、Key、Value三个向量，也是“为什么大模型能结合上下文理解你”的根基。

我用一个生活类比来拆：你去菜市场买菜。query是“我想买什么”（目标），key是每个摊位挂出来的招牌（标识），value是摊位上实际摆着的货（内容）。模型在做的事情，就是拿query去和所有key做相似度匹配，得到注意力权重，再按权重把对应的value加权汇总。通俗讲，模型每次读一个新token，都会“回头看一眼”前面所有token，决定自己该重点关注谁。

对Agent开发来说，理解这一点有三个实际用处。第一是诊断上下文混乱：如果你发现模型“忘事”或者答非所问，很可能不是模型笨，而是你的query写得不够具体，或者关键信息在上下文里被淹没，注意力权重没能正确分配。第二是设计记忆结构：长期记忆该存什么、该用什么形式检索，本质上就是在设计“让模型能高效找到key、取到value”的系统。第三是预估token消耗：自注意力机制的计算量和上下文长度正相关，把上下文塞得越满，推理越慢、成本越高，所以精简prompt不是洁癖，是实打实省钱。

注意：调Prompt时，“你要找什么”定义清楚了，模型才能更准确地从资料里“拿货”。我见过太多人把几百行资料一股脑塞进去，然后抱怨模型不听话——其实模型根本不知道该关注哪一行。

2.2 Harness 和 Agent 到底有什么不同

“harness和agent区别”能上热搜，说明很多人开始接触Agent测试和评测框架了。先说清楚：Harness是被测对象（Agent）的“赛跑跑道兼裁判”，负责初始化模拟环境、向Agent发送任务指令、执行工具调用、收集结果、判定得分。Agent则是“被考核的选手”，它只负责理解任务、规划步骤、调用工具、给出最终回答。

工程视角下，harness的定义还会更宽一点：把LLM循环（loop）、工具注册（tool registry）、记忆接口（memory interface）组装起来的“外壳”也可以叫harness。比如LangGraph里的StateGraph、Spring AI的ChatClient加ToolCalling、ADK里的Runner，本质上都是harness。而Agent本体更强调内置的system prompt、策略、状态机。举个例子：同样一个天气Agent，harness负责统一API格式、配置模型provider、处理流式输出、做重试；Agent只关心“用户问天气，去调用查询工具，再把结果组织成人话”。边界划清楚，代码才不会拧巴。

如果你在写自己的Agent框架，我的建议是：不要把harness逻辑散落在业务代码里。单独抽一层，专门处理“模型调用协议”和“外部工具接入”，这样切换provider或者加新工具时，不会把Agent的核心逻辑搅乱。

2.3 LLM as Judge：用模型审模型靠谱吗

为什么“llm as judge”这么火？因为公开榜单给的是静态指标，但业务场景里大家更想知道“这个模型在我这堆任务上到底行不行”。于是大家开始用更强或更可控的模型当裁判，批量打分。

实践里面有几个关键点：

• 一致性检查：让judge模型输出可解析的JSON评分，并且必须给出理由，不能只给一个分数。
• 偏见问题：judge模型会被答案长度、格式、自身偏好带偏。长答案不一定好，所以要先把待审内容做匿名化和脱敏处理。
• 多裁判投票：单个模型当裁判方差大，我这边的习惯是2到3个模型独立打分，不一致的case拉出来人工复核。
• rubric要明确：别让judge自由发挥，给它一套可执行的评分标准，比如“是否覆盖了用户问题中的所有约束”“工具调用参数是否都来自检索结果”这种可检查项。

用一句话总结我对llm as judge的态度：它非常适合做回归测试和批量初筛，但别指望它完全替代人工评估，尤其是涉及安全、合规、主观体验的场景。

3. 工程实战：从选型到踩坑的完整记录

3.1 框架选型：Spring AI Agent、ADK、Rust 系怎么选

今天的热词里，spring ai agent、adk.dev的kotlin在JVM上跑通agent、基于rust的agent框架都出现了。2026年这个时间点，Java/Kotlin生态和Rust生态的Agent工具链都已经成熟了不少，不再只有Python一家独大。

选型逻辑我通常是三步：先看团队技术栈，没人愿意为了一个Agent框架把整个服务重写；再看是否要长连接、流式输出、多模态这些特性；最后看可观测性，比如日志链路、trace功能到不到位。不是哪个框架炫选哪个，而是哪个框架能让你在现有系统里快速跑通最小闭环。

ADK的体验我多说一句：用Kotlin在JVM上跑一个纯粹Agent确实爽，Runner抽象、Agent抽象都做得很干净。但如果你需要非常复杂的tool calling schema嵌套，最好先拿目标模型的兼容性做一轮验证，别等写完了才发现provider不认。

3.2 Agent 怎么扛并发

“ai agent怎么扛并发”这个问题，几乎每周都会出现。Agent不是一个普通HTTP接口，它内部是多轮推理加工具调用，单次会话可能持续几十秒甚至几分钟。所以扛并发的核心思路不是“多线程疯狂调LLM”，而是把Agent的执行过程拆成可水平扩展的单元。

我的实践方案分五层：

• 会话粒度隔离：每个用户请求对应独立的conversation id和run id，防止上下文串场。
• 拆步骤：把Agent执行拆成“规划、执行、反思”三步，只对规划和反思用强模型，确定性子任务用规则或轻量模型处理。
• 队列化：重任务丢进任务队列（Redis Stream、Celery、Temporal这类），worker水平扩展，客户端轮询结果或走SSE推送。
• 限流与退避：模型provider都有每分钟token数限制和并发限制，客户端要做令牌桶限流，遇到429走指数退避。
• 状态外置：把Agent的memory、工具结果放进Redis或Postgres，而不是进程内变量，否则一扩容就丢状态。

实测下来，真正吃掉并发的不是LLM推理本身，而是“等待外部工具返回”和“长上下文重算”。所以我会缓存工具结果、精简prompt、给每轮工具调用设超时。这三个动作带来的收益，往往比盲目加GPU机器大得多。

3.3 本地模型部署：安卓跑 GGUF、LLM Studio 怎么玩

“安卓本地运行gguf格式llm软件，支持安卓8”和“llm studio”这两个热词，指向的是同一个需求：在没有稳定网络或对数据隐私要求高的场景里，本地跑模型。

GGUF是llama.cpp系使用的量化格式，对移动端来说，关键是量化等级和上下文长度。我的建议是：

• 优先选Q4_K_M量化文件，体积小、效果损失可控。
• 安卓8这代设备内存普遍不大，建议模型参数控制在3B到7B，上下文长度从2048起步调。
• 用llama.cpp的Android构建或者支持GGUF的App，具体以App的release说明为准。
• 模型文件别放外置SD卡，IO速度会拖累推理。
• 安卓8对NEON指令集支持有限，推理速度会比新机型明显慢，老机型跑小模型就好。

LLM Studio这类桌面客户端，本质是“模型文件加配置加对话界面”的集中管理器。我最常用的功能是它提供的OpenAI兼容本地接口，直接对接自己写的Agent。调试tool calling的时候，不需要反复烧API额度，先本地跑通再切在线模型，效率高很多。

3.4 高频报错排查：Codex 沙盒、Provider rejected schema、Execution terminated

今天热搜里三个报错现场，我逐个给排查思路。

第一个是“codex无法发送消息，显示更新agent沙盒”。这大概率是沙盒环境失效，或者镜像版本太旧。常规做法：先尝试重启会话、重建沙盒；再检查磁盘空间、网络连接、环境变量；如果在CI里跑，把沙盒镜像固定到明确版本，别用latest。沙盒这种基础设施，不固定版本就是在给自己埋雷。

第二个是“llm request failed: provider rejected the request schema or tool payload”。这是工具调用参数不符合provider要求，常见原因有这么几类：工具名重复或包含非法字符；参数JSON Schema里写了不存在的类型；function call返回的参数不是合法JSON；部分provider对工具数量有上限。排查顺序我一般是：先把原始请求体打出来，用python -m json.tool校验一遍JSON；再逐个减少tools数量做二分定位；最后对照provider文档检查schema格式。这个报错十有八九是“多写了一个逗号级别”的粗心问题，但定位起来很费时间，所以一定要先看原始请求。

第三个是“agent execution terminated due to error”。这是执行器统一抛出的兜底异常。建议把每一步（plan、act、observe）的日志结构化，记录step_idx、tool_name、error_msg、traceback。如果用的是LangGraph或ADK这类框架，打开tracer或者回调，能直接定位是哪一步把执行链打断。

注意：遇到这类通用报错，千万别只看最后一行。Agent链路里的错误往往发生在中途的工具调用，末尾的“terminated”只是执行器告诉你“整体挂了”。

4. 安全与边界：AgentPoison、内容审计与 Agent 红线

4.1 记忆投毒与红队测试

热词里那条“agentpoison: red-teaming llm agents via poisoning memory or knowledge ba”是篇值得认真读的研究。它做的是：通过污染Agent的长期记忆或知识库，诱导Agent在后续会话里执行攻击者意图。原理并不复杂——Agent拿到外部文件、网页时，如果直接写入记忆或进入检索库，恶意内容就会被当作“可信知识”用。红队做的事情，就是构造高仿正常文本的毒样本，让检索系统召回它，再让它影响Agent的规划。

防护实践上，我比较推荐四件事：

• 检索库权限分级：外部内容要标记来源，低信任来源单独建索引，不允许直接进入核心记忆。
• 记忆写回前做语义审核：用安全分类器或LLM-as-judge过一遍，再决定是否写入长期记忆。
• 输出执行前加工具白名单：即使Agent被带偏，也不能调用敏感工具。
• 定期审计：记录“哪条记忆被写入、被谁召回、最后导致了什么动作”，出问题才能复盘。

大多数人对Agent安全的理解还停留在“提示词注入”，但记忆投毒更隐蔽，而且几乎不需要攻击者参与实时对话，危害面更大。做Agent产品的团队，建议把“记忆写入审计”当成常规需求来做。

4.2 内容安全与应用边界

“支持nsfw llm有那些”这类热词，本质是内容安全策略问题。我不展开讲具体模型，因为这类需求一旦涉及对外服务，就不是“哪个模型能说”那么简单了。凡是面向公众的AI应用，工程上都应该具备三层能力：输入侧内容分类、输出侧安全过滤、可配置的红线策略。不建议直接拿无过滤模型裸奔，尤其是面向公众的场景。

产品要合规、稳定、可信，就必须把“模型能生成什么”和“产品允许输出什么”分开。技术上，安全分类器加对齐训练加输出过滤是标配。你在调研相关模型的时候，优先看模型提供方是否明确说明内容安全策略、是否允许商用、是否能接入下游审核。别只看演示效果，要看它的边界设计。

4.3 给 Agent 加护栏的工程实践

“agent安全”这个词背后真正有用的东西，其实是护栏设计。复制以下四条基本够用：

• 最小权限：Agent只拿完成任务所需的权限，别给它全局shell。
• 工具白名单加二次确认：删除、转账、发送消息这类敏感操作，必须有人类介入确认。
• 超时与预算：给每条链路设置token预算和步骤上限，防止失控死循环。
• 审计日志：输入、中间规划、工具调用、输出全部落日志，出问题能完整复盘。

为什么很多人不敢把Agent真正接到生产环境？缺的就是这层护栏。技术演示可以“裸奔”，上生产必须“穿盔甲”。

5. 学习路线与资源清单：从入门到上手

5.1 Agent 开发学习路线

“agent开发学习路线”“ai agent搭建”“agent 开发 教程”这几个热词说明大量人正在入门阶段。我推荐一条五阶段路线：

阶段一：理解LLM基础。搞清楚token、上下文窗口、API调用方式、system/user/assistant三种角色消息。不需要会推导注意力公式，但得知道什么是上下文窗口溢出。

阶段二：理解Agent循环。自己动手实现一个最小Agent：目标加工具加循环。比如做一个能查文件、能搜网页、能算数的命令行小工具，手工写循环，不依赖任何框架。

阶段三：框架与工程化。把手工循环迁移到框架里，学习工具注册、记忆接口、并发处理、可观测性。

阶段四：评估与安全。看公开榜单是怎么设计评测集的，自己搭一个几十条case的评测集，做回归测试，学习红队测试的基本思路。

阶段五：深入方向。multi-agent协作、spatial/多模态、本地部署、领域Agent，按兴趣选一个深耕。

为什么我反复强调“先手工实现再迁移框架”？因为只有手写过循环，你对harness到底替你做了什么才会有体感。很多人直接上框架，遇到问题连“是框架的问题还是我配置的问题”都分不清。

5.2 热门工具巡礼：Hermes Agent、Obsidian 插件、Agent Skills

热词里hermes agent反复出现（hermes agent obsidian、hermes agent第三方工作台、hermes agent安装），我理解它属于一类开源Agent工具箱，可以和Obsidian这类个人知识库打通，把vault变成Agent可读的知识来源。安装通常分三步：拉取源码或插件包、配置LLM的API端点、把vault路径挂载给Agent。如果你在找“怎么让Agent读我自己的笔记”，这类工具值得一试，注意选活跃维护的版本，别用停更分支。

“claude agent skills: a first principles deep dive”讲的是Agent Skills，也就是把任务技能封装成可复用模块：一份SKILL.md说明触发场景和步骤，加上若干脚本或提示词模板。好处是Agent不用每次重新推理一遍流程，直接按技能模板执行。这对应“agent skill教程”热词——Skill设计的关键是职责单一、触发条件清晰、步骤可验证。我见过把“写邮件”和“做PPT”塞进同一个Skill的反面案例，最后谁都没做好。

另外，llm wiki这类项目本质是把零散的LLM概念建成本地维基，配合Obsidian或Notion用，适合做个人知识管理。我的建议：任何新框架出来，先别看demo炫不炫，先跑一遍最小可复现的tool calling链路，再决定要不要深入。

5.3 榜单怎么读：公开榜单与模型选择

open llm leaderboard这类公开榜单，指标很多，MMLU测知识、GPQA测深度推理、BBH测组合推理、IFEval测指令遵循。选模型的正确动作不是“榜单谁高选谁”，而是：

• 先确认许可和API价格，排除不可商用的。
• 在与你业务接近的评测集上自测，比如你做的客服Agent，就准备一百条真实客服问题来跑。
• 最后做线上AB，用真实流量和业务指标说话。

榜单只能当筛选器，不能当圣旨。我遇到过好几个“榜单刷得高，实际业务一用就崩”的模型，原因就是榜单数据和真实场景分布差太远。自建评测集这一块投入，建议放在任何模型选型之前。

6. 今日快问快答：热词里的高频疑问一次说清

把剩下的一些零散热词用问答形式统一回复一下。

• agent画图：让Agent调用绘图工具或多模态模型，关键在把用户模糊需求转成可执行参数（prompt、尺寸、风格），画完最好还能自评修补一轮。
• agent记忆：分三层设计。短期看上下文窗口；长期用向量库或结构化记忆；工作记忆存当前任务状态。别把所有历史一股脑塞进上下文。
• spatial llm：空间大模型，处理3D场景理解、机器人导航、AR交互。今年一个明确方向是“把坐标和场景图作为token喂给模型”，让Agent具备空间推理能力。
• pi agent、presonl agent：都指向个人助理类Agent，核心是权限和数据隐私。这类Agent能接触你的日程、通讯录、笔记，安全边界不做好就是灾难。
• agent anywhere：本质是把Agent封装成轻量运行时或插件，部署到浏览器、移动端、IDE、本地终端。先做好一套核心逻辑，再去适配各端能力。
• 基于llm的单元测试：LLM生成单测、补断言、分析测试意图都可以，但别让模型自己写测试自己通过，要有独立断言或人工抽查。
• 使用聊天记录精调llm：可行，但聊天记录不等于黄金数据。要先清洗，筛掉低质量、语义含糊的对话，统一system格式再做SFT。
• agent ransack：这类“对Agent上下文做全面排查”工具，解决的核心痛点是脏上下文和隐藏状态。跑一遍排查，往往能发现你没想到的“记忆污染”。

今天日报里提到的每个热词，你几乎都能把它扩展成一个周末就能跑通的小实验：手工写一个Agent循环、用LLM Studio起一个本地模型、给记忆加一道语义审核、在评测集上跑一次llm as judge。我的最大感受是，2026年的Agent生态已经从“名词爆发”进入“工程收敛期”，信息差越来越少，拼的是谁先把细节踩透。多跑代码，少刷热词，比什么都管用。