企业官网建设流程全解析

早上刷完知乎技术时间线，今天（2026-09-28）的 Agent / LLM 讨论密度明显比前几天高出一截。OpenAI 的 Codex 命令行智能体、Hermes Agent 在 Obsidian 上的第三方工作台、LLM as Judge 的可靠性之争、AgentPoison 这类红队研究接连出现，几乎每个话题背后都牵着一个一样的痛点：智能体到底能不能从“能跑起来”跨到“值得信任”。这篇日报不打算面面俱到，只挑今天值得展开的技术点拆开讲。适合正在做 agent 开发、准备把大模型接入生产流程的人，也适合刚入门想找 agent 学习路线的新手——我会把工程细节和踩坑经验混在一起写，尽量让不同基础的读者都能看懂。

1. 今日选题解读：Agent/LLM 生态在争什么

1.1 热词拆解：今天的讨论集中在哪几个方向

把今天的热搜词丢进一个词频池里，能明显看出四条主线。第一条是开发基建，agent 框架、agent 架构、agent 框架与编排、agent 开发这些词成组出现，说明大家还在纠结“我的智能体应该用什么姿势搭”。第二条是能力扩展，Agent Skill、agent 记忆、多 agent、agent tool 成组出现，意味着单纯会调用工具的 agent 已经不够看了，社区开始追求可复用的技能包和长期记忆。第三条是生产化，agent 安全、AgentPoison、LLM as Judge、自主容错控制这些关键词的热度说明，很多人已经从“做个 Demo”转向“怎么让它在线上不出事”。第四条是开发者工具链，OpenAI Codex、Hermes Agent、基于 Rust 的 AI Agent、安卓本地跑 GGUF 这类项目，正在把 agent 能力塞进各种意想不到的环境里。

这个结构其实反映了一个行业变化：2026 年的 LLM 基础能力已经非常稳，单纯的“谁家模型强”不再是讨论焦点。大家的注意力从模型本身转移到模型外面的那一圈——工具、记忆、评估、编排、安全，以及“基于 LLM 的单元测试”“用聊天记录精调模型”这类把模型能力揉进工作流的具体玩法。说白了，模型是发动机，但决定一辆车好不好开的，是底盘、悬挂和驾驶员决策逻辑。今天的所有热点，基本都在围绕这个“车架子”打转。

1.2 今日快速情报：几条不展开但值得知道的消息

整理日报时我有个习惯，把今天出现但暂时不值得展开的消息单独列一组，避免占用正文篇幅，也给有兴趣的人留个索引。今天这组算是近期比较有意思的：

• 基于 LLM 的单元测试：热度不低，核心玩法是让模型从需求描述反推测试用例，再拿真实代码补全断言。实际用下来效果不错，但常产生过度断言，需要人肉删减。
• LLM Studio 与 LLM Wiki：前者是图形化的模型微调和评测工作台，后者是一个把团队知识库跟模型检索绑定的协作项目。两者都偏“工具全家桶”，对团队效率有帮助，但对个人开发者来说学习成本偏高。
• Spatial LLM：关键词指向空间理解能力，比如让模型读取点云、地图栅格、室内布局描述。这会辐射到机器人导航和自动驾驶场景，值得关注，但短期不推荐所有 agent 开发者投入。
• Agent 画图：多模态 agent 集成画图能力已不是新鲜事，今天讨论集中在如何让画图 agent 接受“修改其中某个物体的位置”这类细粒度指令，背后是区域编辑和结构化图像生成。
• Agent everywhere：偏产品落地向，讨论的是把 agent 做成嵌入到鼠标键盘、IM、笔记软件里的常驻能力，核心争议点是常驻权限和数据隐私。

我每天汇总时会刻意区分“新闻”和“信号”。新闻是出了一件事，代表当天热度；信号是这件事背后暗示的长期趋势，值得花一周甚至一个月跟踪。上面这几条里，基于 LLM 的单元测试和 Spatial LLM 更像是信号，其余几条更像是新闻。判断标准只有一个：它会不会改变你未来三个月做 agent 的方式。

2. 框架、编排与 Agent Skill：开发者的主战场

2.1 Harness 和 Agent 到底有什么区别

今天有个热词很有意思：harness 和 agent 区别。很多刚开始做 agent 开发的朋友会把这两个词混在一起，因为它们经常同时出现在框架文档里。我用食堂打饭来做比喻：Agent 是那个打饭的学生，harness 是食堂的动线设计，包括取餐台的顺序、窗口怎么分配、餐具回收在哪。学生可以灵活决定先打菜还是先打饭，但动线决定了整个流程能不能顺畅跑完。

技术上拆开看，harness 通常指负责承载 agent 运行循环的那层基础设施。它管的事包括：维护上下文窗口、处理工具调用的往返、在 agent 输出格式错误时做恢复、把外部事件转换成 agent 能理解的消息、以及记录完整 trace。而 agent 本身更多指那个负责“下一步做什么”的决策单元，通常是一个模型加提示词，再加上它惯用的工具集。你可以完全手写一个 harness，也可以直接用 LangGraph、AutoGen 这些编排框架来当 harness，然后把自己的 prompt 和工具塞进去。真正写项目时，大多数人纠结的“用框架还是不用框架”，本质上就是“我要自己修多少 harness 的轮子”。

我在实际项目里比较推荐的做法：早期 Demo 直接手写一个 60 行的 run loop，把模型调用、工具分发、结果回填串起来，先确认业务逻辑走得通；等系统复杂度上来了，再把循环交给成熟的编排层。这样你既能理解 harness 每部分在干嘛，又不至于一开始就被框架的抽象束缚住。拿 ReAct 循环举例，最简版本无非就是“让模型给出下一步动作 → 执行工具 → 把结果追加到消息列表 → 再问模型”。这四步你能亲手写一遍，再看任何 agent 框架的文档都会顺眼很多。

2.2 Claude Agent Skills：一种可复用的能力封装

今天社区里“claude agent skills: a first principles deep dive”这篇帖子被反复引用，跟“agent skill 教程”的热度是同步的。Agent Skill 这个概念并不是新发明，但最近因为 Anthropic 在 Claude 里把它产品化，重新引发了一波讨论。本质上看，skill 就是把一组完成特定任务所需的指令、上下文、工具调用模板和相关资源，打包成可以被 agent 直接加载的模块。它比单个 tool 更抽象：tool 是一个可调用函数，skill 是一整套“怎么用这些函数完成一件完整的事”的方法论。

举一个今天被问很多的例子：agent 将网页保存成 markdown 的 skill。如果只是做个 tool，你可能会写一个函数，输入 URL 输出 markdown，很简单。但要做一个 skill，你要考虑的是：先抓取网页还是先看 robots；正文提取时对哪些标签降权；图片是保留链接还是下载本地；链接要不要去重和归一化；最后输出到哪个目录，命名规则是什么。这一串决策放在 prompt 模板里，再配上抓取和转换脚本，打包成一个文件夹，agent 随时可以调用，这才是 tool 到 skill 的层级差异。

如果你打算给自己的 agent 加 skill，我给一个简单可复制的结构。文件夹里放一个 SKILL.md，用 YAML 头部声明 name、description、参数 schema；正文用固定模板写“什么时候用、怎么调用、输出规范、注意事项”；脚本放在同目录下，description 里写清楚入口命令。一个保存网页为 markdown 的 skill 头部大概长这样：

--- name: web_to_markdown description: 抓取单个网页正文并转换为干净的markdown文件，适合做信息收集和笔记沉淀 params: url: string # 需要抓取的完整URL output_dir: string # 输出目录，默认为当前笔记目录 download_images: boolean # 是否把图片下载到本地 ---

实际测试时你会发现，description 写得越具体，agent 越不容易在错误场景里误用这个 skill。比如只说“保存网页”不够，要写“适合正文型内容，不适合需要登录的页面”，模型在遇到不适合的场景时会主动询问或跳过。这是花十几分钟就能见效的调优动作，别偷懒。

2.3 今日工具动态：OpenAI Codex 与 Hermes Agent

今天工具链方面的最大动静，是 OpenAI 的 Codex 从研究预览走向更开放的落地。社区里一句“welcome to codex, openAI's command-line coding agent，sign in with chatgpt”被转得很广，因为它释放了一个明确信号：编码智能体正在成为 CLI 的第一公民。Codex 的工作模式是让你在终端里授权它访问仓库，然后它自己完成读代码、改代码、跑测试、提交 PR 这一连串动作。相比之前在 IDE 里靠人点按钮，CLI 版本更适合放进 CI 里跑，也更容易嵌入到你现有的脚本工作流。比如你可以把它接到一个自动处理 issue 的队列里，模型改完代码之后自动跑一遍单测，接着提交分支，由人来 review。

另一条线是 Hermes Agent。今天热搜里 Hermes Agent 官网、hermes agent 安装、hermes agent 第三方工作台、hermes agent obsidian 扎堆出现，说明这个项目正处在用户快速扩张的阶段。Hermes Agent 给我印象最深的是它对“工作台”的理解：它不是只给你一个聊天输入框，而是把任务列表、文件变更、工具输出、运行记录组织在一个侧边栏式的界面里，有点像给 agent 装了一个驾驶舱。很多人问 Obsidian 里的第三方工作台怎么用，其实思路很简单，把 Obsidian 当成 markdown 的编辑器和知识库，Hermes Agent 负责在后台执行任务，再把结果写回笔记，形成一个“输入想法-自动执行-沉淀笔记”的闭环。

我实测下来觉得，这类工具初期最实用的场景不是替你写代码，而是帮你做信息整理。比如你丢给它十几个网页链接，让它抓取正文、去重摘要、自动生成一篇带二级标题的 markdown 汇总笔记，它通常能比你自己手动复制粘贴快得多。前提是你把 skill 或者指令模板写好，并且给足输出目录的权限。别一上来就让它全自动操作你的 git 仓库，先让它干点低风险的活，建立信任感。

3. 安全、评估与容错：Agent 进入生产的三个坎

3.1 AgentPoison：记忆中毒攻击的威胁模型

安全相关的热词里，AgentPoison 今天讨论度不低。原因很简单，它攻击的不是模型权重，而是 agent 的记忆和知识库，这让很多人第一次意识到 RAG 并不天然安全。AgentPoison 的核心思路是红队视角，往 agent 会检索的记忆文档里投放经过特殊构造的文本，让 agent 在读取这些“知识”时被引导执行攻击者想要的操作，比如修改某个重要文件、跳过权限校验，或者泄露存在上下文里的敏感信息。

这和传统提示词注入的差别在于，注入不再依赖用户当前这条消息，而是藏在历史记忆或外部知识库里，被称为“持久化注入”。工程上最让我担心的一点是，很多 agent 框架默认信任所有检索回来的内容，把向量数据库里的片段直接塞进上下文，这就等于让攻击者拿到了一个长期后门。防御角度，我建议至少做三件事：给每条记忆记录来源和可信度标签；对检索内容做离线的敏感指令检测，比如发现内容里带有“忽略之前的指令”“执行系统命令”这类模式就降权；关键操作一律要求二次确认，不让 agent 直接执行由记忆内容推导出的高危动作。这三层听着基础，但在今天的生态里已经能挡住绝大多数已知的投毒路径。

3.2 LLM as Judge 与元评论残留问题

LLM as Judge 现在几乎是做 agent 评测的标准姿势，但今天知乎上有个讨论戳中了很多人的痛点：用大模型给大模型打分时，出现了“LLM 元评论残留”的问题。所谓元评论残留，就是 judge 模型在产出评分时，把自己的思考过程、系统提示语、甚至对被评测模型的偏见带进了最终评价文本里。比如你让 judge 给两个回答排序，它却在输出里点评“这两个回答都只覆盖了浅层知识”。这句话如果被当作结论使用，整个评测就失去意义了。

我的经验是，用 LLM 当裁判，最关键的是限制它的输出空间。不要让它自由发挥写评语，而是把评分维度拆成离散选项，比如相关性、完整性、安全性各打 0-5 分，并且要求它必须按 JSON 格式返回，禁止输出 JSON 之外的任何解释。其次要做评测盲化，被打分的模型输出不要附带模型名和 prompt 元数据，否则 judge 容易被品牌效应带偏。最后，建议定期抽样做人工复核，把 judge 明显误判的样本收集起来，写进 judge prompt 的 few-shot 例子里。这个迭代成本很低，但能把评测准确率从“看个大概”拉到“可当回归基线”。

3.3 构建可靠 Agent：自主容错控制的工程实践

“llm 智能体自主容错控制：构建可靠 AI 系统的工程实践”这个热词背后，其实是每个 agent 从原型走向生产都要面对的三座山：模型会崩、工具会挂、编排会乱。自主容错不是说让 agent 自己重试几次就行，而是要建立一整套异常处理链路。我常用的骨架：调用任何外部工具之前先生成 plan，plan 里标注每步的前置条件和预期结果；工具返回后先做 schema 校验，字段缺失立刻终止这一步，而不是继续往下跑；遇到错误时把错误原文、模型输出、相关 trace 一起打包进回退指令，让模型在少一轮试错成本的前提下修正；最关键的是全链路日志，每一条 tool call 都记录下来，否则出问题时你根本没法复盘。

一个典型的容错循环骨架：

async def run_agent_loop(initial_state): state = initial_state for attempt in range(3): try: plan = await model.plan(state) for step in plan.steps: result = await call_tool(step) validated = validate_schema(step.expected, result) if not validated.ok: raise ToolOutputError(step.name, validated.detail) state = merge_state(state, result) return state except (ToolOutputError, ModelOutputError) as e: state["error_feedbacks"].append( f"attempt {attempt}: {str(e)}\nlast trace: {state['trace'][-5:]}" ) if attempt == 2: return {"status": "failed", "state": state} return {"status": "failed", "state": state}

循环外面还要加一层超时熔断。单次 agent run 超过 90 秒就发告警并转人工，因为大多数真实任务里，一个 agent 卡住带来的损失远大于它多跑几分钟可能带来的改善。灵活性是好东西，但要给灵活性加上护栏。

4. 学习路线与轻量落地：新人怎么跟上节奏

4.1 从 Agent 基础到多 Agent 的路线图

今天热搜里同时出现了 agent 学习路线、agent 开发学习路线、agent 框架、llm 框架、agent 项目，显然有一大批人正准备入坑。我按自己带过人的经验，把路线压缩成五个阶段。第一阶段是念清楚协议，搞明白 token、上下文窗口、function calling 这几个概念，能自己用 provider 的 API 完成一次带工具调用的对话。第二阶段是手搓最小循环，不依赖框架，把“模型出提议-解析工具调用-执行-结果回填”写出来。第三阶段开始选编排层，这时候再去看 LangGraph、AutoGen，或者直接读成熟 agent 项目源码，你会发现自己已经能读懂大部分设计取舍。第四阶段做记忆和评估，给 agent 加短期会话缓存和长期向量记忆，同时用真实的错误 case 建一个 eval 集。第五阶段再碰多 agent 和复杂技能编排，因为协作复杂度和定位问题的成本都是指数级上升的，没有前四阶段的底子容易翻车。

每个阶段都配一个能拿得出手的小项目，会比单纯刷课有效得多。例如第一阶段做关键词提取小工具，第二阶段做本地文件自动分类器，第三阶段做带工具调用的问答机器人，第四阶段做带长期记忆的个人知识助手。重点是让每个项目都留下可复用的代码块和踩坑笔记。很多框架文档写得云山雾绕，但你带着具体问题去读就会豁然开朗，这也是我建议先手写循环再碰框架的核心原因：你已经有“该往哪个接口塞什么东西”的直觉了。

4.2 基于 Rust 的轻量 Agent 初体验

“基于 rust 语言 ai agent”今天也有不少讨论。Rust 在 agent 领域的吸引力主要来自三件事：编译期就把一部分类型错误挡住，运行时内存安全，二进制体积小到可以直接部署到边缘设备。代价是生态相对年轻，很多 Python 里一行搞定的东西要自己写。我的建议是，如果是为了学习和探索，用 Rust 写一个单文件 agent 很值，能让你把整个流程刻在脑子里；如果是要快速迭代业务，还是用 Python 生态更划算，除非你已经对内存占用非常敏感。

一个最小 Rust agent 的思路：用 reqwest 调 LLM API，用 serde 定义工具输入输出的结构体，main 循环里不断维护一个 Vec ，拿模型的 tool_calls 去匹配一个函数注册表。整个过程没有太多魔法。写完一次之后，你再看任何 agent 框架的源码都会觉得亲切，因为你会发现它们本质上都在做同一件事：维护消息历史、执行工具、把结构化的输入输出理顺。Rust 只不过用类型系统把这些约束提前到了编译期。

4.3 在旧安卓手机上跑 GGUF 大模型

热点里有一个比较实在的：安卓本地运行 gguf 格式 llm 软件，支持安卓 8。GGUF 是现在本地推理最通用的模型量化格式，把神经网络权重量化成 4-bit 甚至更低的精度，让模型能在手机、小盒子这类设备上跑起来。如果你手头有一台安卓 8 的老手机，完全可以把它改造成一个离线小助手。

步骤不复杂。第一步先确认安卓版本和内存，至少 4GB 内存运行 1B 模型比较稳，2B 到 3B 模型则需要 6GB 以上。第二步在手机上下载支持 GGUF 的推理客户端，安装后用转换脚本或直接下载现成的 GGUF 模型文件。第三步把模型文件放进手机存储，在客户端里加载，注意把 system prompt 改成简短版本，因为本地模型的指令遵循能力相对弱。第四步实测速度，通常量化后的 1B 模型在老旧手机上能跑到每秒 5-8 token，用来做摘要或分类勉强够用，但别期待它能做复杂对话。

这类实验对生产的价值在于逼你思考资源边界。等你在手机上跑过模型，你会对 token 预算、量化精度损失、上下文长度限制有很直观的体感。以后设计服务端 agent 时，你会自然记得“能少传的上下文绝不多传”，坑会少踩很多。

5. 今日踩坑记录与环境报错速查

5.1 Agent execution terminated due to error

这个报错今天出现频率很高，形式是 agent 跑着跑着突然被环境杀死，错误信息长这样：“agent execution terminated due to error.”。我排查过几次后发现，多数情况不是 agent 逻辑写错了，而是运行时资源或状态出了问题。常见原因有三个：一是单个工具调用超时，框架默认把整个 run 标记为失败；二是上下文超过模型限制，provider 直接拒绝继续；三是 agent 内部出现了无法解析工具返回值的异常，循环没法继续。

遇到这个报错，我的排查顺序是：先看日志里最后一次 tool call 是什么、耗了多久；再检查当前上下文折算出的 token 数；最后确认工具返回的 JSON 是否符合预期。如果是超时，就把超时时间调大或者给该工具加独立超时；如果是上下文超限，就要给会话做摘要压缩，把不重要的消息合并成一条 overview；如果是返回值异常，需要在 tool 返回后加一层 try-except 和 schema 校验。别一上来就重跑，重跑大概率复现，先看日志。

5.2 LLM request failed: provider rejected the request schema or tool payload

另一个高频报错是“LLM request failed: provider rejected the request schema or tool payload.”。这句话直译是 provider 拒绝了你传过去的请求 schema 或工具负载。我见过的大部分场景都指向同一个问题：你发给模型的工具参数格式和模型 API 要求的规范不一致。比如某 provider 要求工具参数必须是 JSON Schema 类型，你却直接传了一个 Python dict；或者 max_tokens、top_p 这些参数里塞了个 null 值；还有一种情况是 tools 数组为空，但请求体里仍然带了一个空的 tools 字段，导致部分后端直接报错。

排查的时候我会先做减法和加法。减法是把所有非必需参数删掉，只保留 messages 和 model 再发一次，确认接口通不通；加法是把工具定义一项一项加回去，每加一个就发一次请求，直到找出触发拒绝的那个字段。实测下来，这种问题九成是类型不匹配，改好后端序列化逻辑就好，和模型本身没有关系。

5.3 Agent token 与记忆的配合：减少残留、延长可用长度

最后说一个和 token 相关的日常经验。很多人问 ai agent token 是什么意思，其实很简单，token 是模型处理和生成文本的最小单元，agent 的每一次工具调用、每一段记忆读取都会消耗它。所以 token 管理就是 agent 的成本管理。在实际项目里，我的习惯是给每条记忆做个原始记录和摘要版本，读取时只把摘要放入上下文，需要细节时再触发一次检索。另外，定期压缩会话，很多框架都支持把旧消息总结成一条 summary，把冗长的工具输出放进本地文件，上下文里只放路径。

这套做法配合上面 5.1 和 5.2 的报错案例，能明显减少“LLM request failed”和“Agent execution terminated”的出现频率。token 逻辑理顺之后，agent 的可用上下文长度相当于变长了几倍，虽然物理窗口没变，但单位里装的信息密度提高了。如果再把“基于聊天记录精调模型”的思路用上，把历史对话定期沉淀成训练数据，agent 的个性化程度也能慢慢上来，属于耗时不长、越滚越有价值的投资。

最后：整理日报之外的几点体会

今天这一轮内容刷下来，我最大的感受是，Agent 和 LLM 的牌桌已经换了玩法。去年大家还在比谁能把 agent 跑起来，今年比的是谁能把 agent 管住、度量清楚、在出错时快速收敛。你如果只在 demo 里见过 agent，不妨按我上面第 4 节的路子走一遍；如果已经在生产环境里被报错和 token 成本折磨过，那第 3 节和第 5 节的内容应该能给你一点抓手。

最后再分享一个小技巧：把每一天遇到的 agent 报错，无论多小，都记进一个 markdown 速查表，字段只写“错误原文、触发场景、根因、修复步骤”。几个月后你就是团队里排查 agent 问题最快的人，这张表的价值会远超你收藏的几十篇教程。今天的日报就到这里，明天有新热点再接着拆。