企业官网建设流程全解析

整理这份日报的时候，后台收到的搜索词里，Agent和LLM几乎各占半壁江山。有人问框架选型，有人在排查报错，有人在研究记忆库投毒的论文，也有人折腾安卓8老手机跑GGUF。我把这些问题按热度排了个序，挑出今天最值得看的几条，按“安全研究、框架工具、可靠性工程、模型部署、新词速记”五个模块展开。适合正在做Agent落地的工程师翻一翻，也适合刚入坑的同学当索引用。

1. 今日焦点：两条值得读的深水区内容

每天热词里都会混进来几篇硬核论文和几个被反复讨论的方法论。今天最值得花时间的是两条：一条是AgentPoison的越狱攻击路线，另一条是LLM as Judge的工程化分歧。

1.1 AgentPoison：通过污染记忆库/知识库对Agent做红队测试

今天热词里出现了一篇标题很长的论文：AgentPoison: Red-teaming LLM Agents via Poisoning Memory or Knowledge Bases。我建议所有做Agent安全、做RAG落地的人认真读一遍。

这篇论文攻击的不是LLM本身的权重，而是Agent的记忆模块和知识库。攻击者不需要改模型，只需要在Agent会检索到的知识库里埋入少量精心构造的文本片段。当Agent在执行任务时检索到这些片段，会把有毒内容当作可信上下文吸收，进而被诱导执行攻击者预设的行为。整个过程甚至不需要直接跟Agent对话，属于一种“被动触发”的攻击方式，比传统提示注入更隐蔽。

论文里更值得警惕的一个结论是：攻击成功率对有毒样本数量非常敏感，作者在多个主流Agent基准上做了测试，少量毒样本就能显著提升攻击成功率，同时尽量不影响Agent在正常问题上的表现。这意味着什么？意味着“只要知识库可写，Agent就不可信”不是危言耸听。凡是开放了知识库写入接口、允许用户上传文档再被其他用户检索的Agent应用，都暴露在这个攻击面里。

防御层面，论文给出了一些思路，我补充一点工程上能立刻做的事：

• 知识源分级：把用户上传内容、官方文档、网络检索结果分池存储，不同来源设置不同信任等级，Agent在处理时需要感知来源权重。
• 检索结果二次过滤：不要直接拿top-k片段喂给模型，先做一轮“是否与当前任务相关”的轻量校验，甚至用另一个模型交叉判断。
• 行为审计：对Agent的关键行为（调用工具、读取文件、发送消息）做日志留痕，出现异常指令时能回溯到是哪条知识片段触发的。

我把这条放在今日焦点，是因为它说明Agent安全的重心正在从“提示层”往“记忆层”迁移。你的Agent可以没有漏洞，但你的知识库可以是突破口。

1.2 LLM as Judge：从玩具到工程化，还差几步

“LLM as Judge”今天也上了热词。这个概念本身不新，就是用大模型当裁判，给生成结果打分或者做对比排序，替代一部分人工评测。现在几乎所有Agent项目的评估环节都在往这个方向靠，因为它便宜、快、可批量。但工程化之后，问题比想象中多。

我自己踩过的坑有三个，先说结论：

• 位置偏差：两个答案谁先出现，会影响裁判的判断。A/B顺序换一下，胜负可能就反过来。
• 冗长偏好：裁判模型倾向于给更长的回答打高分，哪怕内容啰嗦。
• 自我偏袒：如果裁判模型本身也是生成模型，它往往对自己生成的风格和内容更友好。

这三个坑放在一起，意味着你不能拿裸的LLM直接当裁判，然后用它的分数当作唯一标准。可行的做法我列一下：

1. 固定Rubric：给裁判模型一个打分表，明确从“事实准确性、工具调用合理性、回复简洁度、最终结果可执行性”几个维度打分，每个维度给锚点描述，而不是让它自由发挥。
2. 多裁判投票：用两到三个不同厂商或不同规模的模型分别评分，取中位数或做多数投票。单一裁判的偏见，在多裁判下会被稀释。
3. 抽样人工复核：每批自动评测里抽5%-10%人工看一眼。不是为了推翻机器分数，而是持续校准Rubric的语义。模型对“简洁”的理解和人类不完全一样，这个偏差只能靠人肉对齐。

LLM as Judge是当前Agent评测成本最低的方案，但它适合做“筛选”，不适合做“定论”。筛选出明显好坏的结果没问题，临界样本必须人工复核。这跟代码Review是一个道理：自动检查工具负责拦住低级错误，但最终上线前得有人拍板。

2. Agent框架与工具链：今天问得最多的一组问题

热词里关于框架的讨论非常密集，最集中的几个点是：Harness和Agent到底什么关系、ADK在JVM上怎么跑起来、Spring AI Agent怎么用、Codex命令行Agent适合谁、Hermes Agent在Obsidian里怎么搭。

2.1 Harness 和 Agent 到底有什么区别

“Harness和Agent区别”这个热词能上榜单，说明很多人和我当初一样，被这两个术语绕晕了。先说我的结论：

Agent是“会思考的循环”，Harness是“套在Agent外面的运行与测试装置”。两者不在一个层级。

Agent的核心是一个大模型加工具集，再加一个循环：模型根据用户请求决定调用哪个工具、观察工具返回结果、再决定下一步动作，直到认为任务完成。这个循环本身可以独立存在，你可以写一个几十行的Python脚本实现它。

Harness则更像是一个“舞台”。它负责管理工具注册、模型调用配置、上下文窗口、日志追踪、评测指标采集、并发调度。同一个Agent，换一个Harness跑，行为可能完全一样，但可观测性、稳定性、并发能力完全不同。

用生活类比来说：Agent是演员，Harness是剧组。演员负责演，剧组负责灯光、场记、盒饭、意外处理。你只请演员来演，他也能演，但一旦出了错场、忘词、设备故障，没有剧组兜底就乱了。

实际选型时，我的建议是：

• 如果你只是做玩具项目或验证想法，不需要Harness，直接写循环就行。
• 如果你要对接多个模型供应商、要记录完整trace、要做自动化评测、要处理并发，那就必须上Harness，否则后期维护会非常痛苦。
• 注意区分“Agent框架”和“Agent Harness”。LangChain这类偏编排框架，提供了很多Agent组件；而LangSmith、LangFuse这类偏Harness，重点是观测和评测。两者不冲突，但别指望框架自带完整的评测能力。

2.2 三个值得试的上手路径：ADK、Spring AI Agent、Codex

今天热词里出现“adk.dev 的 Kotlin 快速上手，在 JVM 上跑通一个 Agent”，说明JVM生态的开发者也在找Agent入口。Google的Agent Development Kit（ADK）同时支持Python和Java/Kotlin，如果你日常写Kotlin或Java，那这套工具的体验会比较自然。

JVM上跑通一个Agent的路径并不复杂，大致三步：

1. 用Gradle或Maven把ADK依赖加进项目，网上有很多官方示例模板可以直接克隆。
2. 定义一个Agent，给它起名字、指定模型、写一句系统指令，再注册一个或多个工具方法。工具方法就是一个普通函数，比如查天气、算订单金额，只要能被框架识别成tool。
3. 启动REPL交互模式或者直接通过API调用，输入一句自然语言，Agent会自动决定调用哪个工具，然后把结果组织成回复返回。

整个流程跑通大概就是一杯咖啡的时间。背后的机制是：框架把你的工具函数转成LLM能识别的JSON Schema，模型在对话过程中看到工具定义后，决定是否调用、传什么参数、怎么处理返回值。

Web后端的主流选择则是Spring AI Agent。如果你已经在用Spring Boot，加一套Agent能力不需要引入太多额外依赖，核心思路是：把LLM客户端封装成一个Bean，通过工具方法注解实现Tool Calling，再配合Prompt Template做用户输入到模型输入的转换。

Spring AI最强的点是它在Java生态里与现有事务、数据库、监控体系整合非常顺。我自己试下来的感觉是，项目里已经有Spring Boot体系时，用Spring AI做Agent会比自研一套调用链省一半时间。

再就是热词里那个“Welcome to Codex, OpenAI's command-line coding agent”。Codex是OpenAI推出的命令行编码Agent，通过ChatGPT账号登录后，它能在本地仓库里完成读取代码、修改文件、执行命令、提交改动这一连串工作。和前面说的框架式Agent不同，Codex走的是“Agent即终端助手”的路线，适合处理代码库里的机械化改造任务，比如批量重构、补测试、修编译错误。

我的看法是：Codex这类工具解决的是“个人开发者生产力”问题，ADK/Spring AI解决的是“把Agent嵌进你的业务系统”问题，诉求不同，不用纠结二选一。你要是只有一台电脑一个仓库，想快速体验Agent写代码的爽感和翻车现场，装个Codex就够了。

2.3 Hermes Agent：在Obsidian里跑Agent的第三方工作台

热词里有一个“Hermes Agent Obsidian”和“Hermes Agent 第三方工作台”，好几个同学都在问这个。如果你关注Obsidian插件生态，这个话题确实值得看一眼。

Hermes Agent是一类把LLM Agent接入Obsidian笔记系统的第三方工作台，核心是让Agent能直接读写你的笔记库。它的价值在于：你的笔记不只是给人看的资料，而是能被Agent当作“记忆”和“知识库”来调用的资源。

我实际体验下来的安装过程大概是这样的：

1. 先确认你的Obsidian版本支持外部插件，然后把Hermes Agent的插件目录放进.obsidian/plugins/下，重新加载Obsidian即可在社区插件列表里看到它。
2. 在插件设置里配置模型端点、API Key和默认模型。建议把上下文窗口设置得小一点，因为笔记库内容很容易把上下文撑爆。
3. 配置Agent可访问的笔记范围和目录权限，只开放它需要的文件夹，不要给它全库访问权限。
4. 建一个专用笔记作为“操作台”，在笔记里以对话或指令块的形式调用Agent，让它对指定笔记做摘要、找关联、生成卡片。

这里有一个容易踩的坑：Agent在笔记库里搜索时，会把大量不相关的笔记片段拼进上下文，既浪费token，又降低回答质量。我建议先让Agent用文件名和标签做一次粗筛，再决定要不要读正文，而不是上来就全文检索。

另外，笔记是个人数据库，把Agent接进来，等于把个人数据交给第三方模型处理。建议优先接本地模型或私有化部署的模型接口，别把含敏感信息的笔记直接送到公网API。这不是保守，这是基本的数据边界意识。

3. 可靠性工程：让Agent从“能跑”到“能扛事”

热词里有一条特别醒目：“面向LLM智能体的自主容错控制，构建可靠AI系统的工程实践”。这几乎是每个Agent项目从Demo走向生产都会撞上的墙，今天专门展开说。

3.1 自主容错控制：给Agent装一层“安全带”

Agent在生产环境里最大的问题不是“不够聪明”，而是“不可预期”。模型可能改口、工具可能超时、外部API可能返回脏数据，任何一个环节出错，整套流程就可能崩掉。所谓自主容错控制，核心不是让Agent不犯错，而是让它在犯错时能自愈、降级或者兜底。

我的工程实践是把容错分成四个层级：

这里贴一段我常用的简化版容错外壳，逻辑不复杂，但实测很稳：

def run_with_guard(agent, task): for attempt in range(3): try: result = agent.run(task, timeout=60) if validate_output(result): return result logger.warning("output invalid: %s", result) except TimeoutError: logger.warning("attempt %s timeout", attempt) except ToolExecutionError as e: # 让Agent感知到工具错误，并改用备用方案 result = agent.run( f"上一步工具执行失败：{e}，请改用备用方案继续", timeout=30 ) if validate_output(result): return result return fallback_reply(task)

这个模式的关键点有两个：一是要给Agent一个“感知错误并重新规划”的机会，而不是出错就直接返回失败；二是所有重试都必须有次数上限，避免Agent陷入死循环，无限烧token。我见过最惨的一次线上事故，就是一个工具返回了异常格式，Agent反复重试了40多次，账单直接爆掉。

另外一个容易忽略的点是“输出校验”。LLM返回的结果不一定符合你的预期结构，比如你要JSON它却回了Markdown，你要字段名order_id它却写了orderId。我现在的做法是：给每个Agent的输出定义一个JSON Schema，模型返回后先做校验，不合格就带着校验错误信息让它重新生成，最多给两次机会。这样能拦住大部分“看起来能用实则解析必挂”的输出。

3.2 Agent怎么扛并发：先找瓶颈，别盲目加机器

“AI Agent怎么扛并发”这个热词背后，是一个常见的误解：以为Agent扛不住并发是模型不够快，其实瓶颈往往在别处。

Agent一次请求的消耗路径比普通API长得多：模型要思考、要调用工具、工具要等外部响应、模型还要继续思考。这意味着单次请求的耗时可能是几十秒，QPS一旦上来，线程池、连接池、token预算、外部API限流，每个环节都会爆。

我建议按这个顺序排查：

1. LLM网关是否做了连接复用：每次新建连接握手开销巨大，必须走HTTP连接池。
2. 上下文构建是否合理：如果每次请求都把大量历史记录塞进上下文，不仅慢，还费钱。把记忆做成分层：短期对话记忆、摘要记忆、长期知识库，按需取用。
3. 工具调用是否可并行：如果Agent一次决策要读三个数据源，让三个工具调用并行执行，而不是串行等待。这四个工具串行要15秒，并行只要5秒。
4. Agent会话是否有状态隔离：并发场景下最怕一个用户的状态串到另一个用户。每一个请求必须绑定独立的会话上下文或Agent实例，不能共享可变状态。
5. 削峰手段有没有：用户量上来时，先把请求放到消息队列，用worker池消费，给用户一个“任务已受理”的反馈，而不是硬抗瞬时流量。

再补充一个运维层面的建议：给Agent的每一次运行加上trace和指标，记录模型调用耗时、工具调用耗时、token消耗、重试次数。没有这些数据，你根本不知道瓶颈在哪，只能靠猜。我自己就是把“工具调用耗时”单独统计出来，才发现有个慢SQL拖垮了整个Agent，跟模型一点关系都没有。

3.3 两个高频报错排查实录

热词列表里有两个非常具体的报错原文，都是生产环境高频出现的，单独拿出来说。

第一个报错：llm request failed: provider rejected the request schema or tool payload.

这个报错我最近遇到不止一次，字面意思是模型供应商拒绝了你的请求，觉得你的Schema或工具载荷不合法。排查路径我按概率排序：

1. 工具定义JSON Schema有误：最常见的是某个参数忘了标type，或者required引用了不存在的字段。把组装好的tools直接打印出来，用JSON校验工具过一遍。
2. 供应商对工具数量或复杂度的限制：有些网关一次只允许传少量工具，或者不支持特别复杂的嵌套对象。试着先传一个最简单的工具，如果能跑，再一个一个加回来，定位是哪条定义触发了拒绝。
3. 字段格式不兼容：比如部分供应商要求additionalProperties必须是false，有些则不允许这个字段出现；有些要求所有参数都必须写description，漏了可能被拒。这类问题需要对照供应商API文档逐项核对。
4. 绕过框架直接测试：把最终发给供应商的payload抓出来，用curl直接post过去，看是不是框架在做转发时改坏了请求结构。

第二个报错：agent execution terminated due to error.

这个报错一般不是模型本身的问题，而是Agent执行器内部遇到了未捕获的异常。最常见的原因有三个：工具函数抛了异常没有catch住、工具返回了无法序列化的对象（比如Python对象直接return给模型）、上下文窗口溢出导致执行器崩溃。

我的排查方法是先开trace，看执行器是在哪一步终止的。如果是工具调用后崩的，那就在工具函数外层包一个try-catch，把异常转成一段可读文本返回给模型，让模型知道这个工具没成功，而不是让执行器直接抛出。如果是序列化问题，检查工具返回值是不是纯JSON可序列化的数据类型。如果是上下文溢出，就要做摘要压缩或者限制历史轮数。

这个报错最容易引起连锁反应：执行器一崩，整个用户会话就断了，用户可能就再也收不到结果。所以生产环境里一定要在执行器最外层加一个兜底catch，返回“系统繁忙”之类的降级文案，保证用户永远能看到一个响应，哪怕是失败响应。

4. 模型、精调与本地部署的实战记录

今天热词里模型相关的内容也不少，我挑三个最值得说的：Spatial LLM是什么、安卓老机器怎么跑GGUF、用聊天记录精调模型有哪些门道。

4.1 Spatial LLM：给模型装上“空间脑”

“Spatial LLM”今天就挂在热词榜上。这个概念听起来玄，其实落地场景非常具体：让大模型具备空间理解能力，能处理坐标、方向、布局、尺度关系。

传统的LLM对空间几乎无感。你跟它说“把杯子放在桌子的右上角，离边缘5厘米”，它只能理解语义，但换算不了坐标。Spatial LLM类模型则是把空间表示（坐标、边界框、深度信息）融入了训练，让模型可以直接输出位置参数或者理解3D场景描述。

应用方向现在主要在三个地方：

• 机器人操作：从自然语言指令直接生成机械臂的目标位姿。
• 室内导航：把“走到沙发右边”翻译成具体的路径规划目标。
• AR/空间计算：理解真实场景中的物体布局，辅助虚拟内容摆放。

如果你做的是这几个方向的项目，关注Spatial LLM会比通用LLM有更直接的收益。但目前这类模型普遍比较重，部署成本高，大多数还停留在研究或demo阶段，适合提前跟进，别急着上生产。

4.2 安卓8上跑GGUF：本地LLM部署的另一条路

“安卓本地运行GGUF格式LLM软件，支持安卓8”这个热词，应该是某个用户在寻找老手机上跑本地模型的办法。这事我折腾过，结论是可行，但期望值要摆正。

先说一下GGUF是什么。它是llama.cpp项目推出的一种模型量化格式，把大模型压缩成普通手机CPU也能跑的形式。在安卓上跑GGUF，本质上是把llama.cpp编译成安卓可执行文件，再加载量化后的模型文件。

针对Android 8（API 26）这类老系统，我的建议方案有两个：

方案A：装现成的GGUF推理APK

社区里已经有一些开源的安卓模型运行器，支持导入GGUF文件并在本地运行。老机器优先选轻量级APK，注意看要求的系统版本是不是在Android 8之上。装上之后，找一个1B到3B参数的Q4_K_M量化模型，文件大小大概在1到2GB之间，导入后就能对话。实测下来，3B模型在Android 8的中端旧机上生成速度大约每秒几个token，能用，但别期待流畅。

方案B：Termux + llama.cpp手动编译

如果你愿意折腾，Termux可以在Android上提供一个Linux环境，然后从源码编译llama.cpp。大致命令如下：

pkg install git cmake git clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build && cd build cmake -DCMAKE_BUILD_TYPE=Release .. make -j4 ./llama-cli -m ~/path/to/model.gguf -p "你好"

这个方案的优点是灵活，可以自己调参数；缺点是要花上一个下午，而且Android 8上编译可能会遇到工具链兼容问题。如果主要是想体验本地模型，我建议直接选方案A。

运行的时候有几个必调参数：-c控制上下文长度，老手机建议设1024或2048，别设太大否则内存直接爆；-t控制线程数，别超过CPU核心数；温度建议0.7左右。模型跑起来之后，一定要关掉网络再试，确认它真的不联网，这样才能保证隐私。

4.3 用聊天记录精调LLM：少走弯路的注意事项

“使用聊天记录模型精调LLM”这个热词，指向的是一个正经需求：把手里的真实对话数据转成训练集，精调一个更贴合自己场景的模型。

聊天记录确实是很好的训练素材，但直接用原始聊天记录去训练，效果会很差。我建议的流程是：

1. 清洗数据：去掉时间戳、已撤回消息、系统提示、广告、重复内容。最重要的是去掉所有个人身份信息，手机号、微信号、地址、姓名，全部打码或删除，这是红线。
2. 构造对话格式：把聊天记录转成标准的messages格式。系统提示词固定写角色设定和行为规范，用户消息放真实提问，助手消息放理想回复。如果聊天记录里有多轮，保留完整上下文，但要注意截断长度。
3. 补充负样本：只拿真实对话训练，模型会学会你的回答风格，但不会知道你讨厌什么。要额外构造“不该这么答”的样本，或者在系统提示里明确禁止行为。
4. 用LoRA或QLoRA精调：不建议全参数微调。全参数微调成本高、容易灾难性遗忘，LoRA只训练一小部分参数，效果好得多，还能在消费级显卡上跑。
5. 评估要留一手：不要拿训练集里的对话来评估，要把一部分数据单独留出来当测试集。另外，用LLM as Judge跑一轮批量评分，再人工抽看，能发现很多意外问题。

JSONL训练数据格式大概是这样的：

{"messages":[{"role":"system","content":"你是某电商客服助手，回复要简洁专业。"},{"role":"user","content":"订单三天没发货怎么办？"},{"role":"assistant","content":"请提供订单号，我来帮您查询物流状态。"}]}

一个容易翻车的地方是：聊天记录里经常会有“机器翻译味”的回答，比如客服话术里充斥着“很高兴为您服务”“感谢您的理解”。这些模板词会被模型学过去，导致精调后的模型回复很僵硬。清洗时建议把这类套话统一替换成自然的口语表达，或者直接删掉。

5. 新词观察与问答速记

日报的最后一部分，留给今天的热词新面孔和几个短平快的问答。做日报时间长了你会发现，很多热词其实信息密度很低，但偶尔也会有几个词提前暴露下一个趋势。

5.1 今天冒出来的几个新词

“Agent Anywhere”这个词，目前看到的信息还没有收敛到一个明确的单一产品上，更像是“随处运行Agent”这类思路的代号。值得关注的方向是：Agent不再局限于对话框里，而是可以被调用到任意业务流程节点，比如浏览器里、IDE里、IM机器人里。如果这个趋势成立，那Agent框架的抽象层会越来越厚，因为要适配的环境越来越多。

“Pi Agent”今天也上了热词，但信息比较散，我没有确认到能直接推荐的项目。如果你正在查这个词，我的建议是先确认你说的是哪个“pi”：是某个个人智能体项目，还是数学常数相关的工具链，或者是某个仓库的缩写。方向不同，完全不是一码事。我自己的处理方式是先把这类未证实的词放进观察列表，等有更明确信息再下结论。

“Agent Skill”则值得多说一句。这个概念和插件类似，但思路更偏“给Agent一套专家级的标准操作流程”。一份Skill通常包含说明文档、示例、脚本或模板，告诉Agent在什么场景下按什么步骤做事。今天热词里有一篇“Claude Agent Skills: A First Principles Deep Dive”，我建议对Agent能力扩展感兴趣的读者找来看。它解释了为什么把技能外置而不是写死在模型里：因为模型能记住的“操作手册”极其有限，而技能包可以把操作手册放在模型需要的时候再去读取。这跟人类用SOP手册是一个道理，没人能把所有流程背在脑子里，但需要时会去翻手册。

5.2 问答速记：LLM单元测试、Agent画图、还有几句实在话

热词里有“基于LLM的单元测试”，我用一句话概括我的实践：LLM适合做“测试生成器”和“测试评价器”，不适合直接断言结果对不对。生成器负责读源码、看注释、生成测试用例；评价器负责看生成出的用例是否覆盖了主要分支、断言是否有意义。但最终测试能不能通过、覆盖率有没有达标，仍然要跑在真实的测试框架里。LLM生成的断言很容易出现“幻觉断言”——看起来在断言，实际上什么都没检查。

“Agent画图”这个热词也高频，我简短说一下实现路径：把绘图能力封装成一个工具，这个工具内部调用绘图模型API，接收Agent传来的风格、尺寸、主体描述参数，返回图片URL。难点在于迭代闭环：Agent自己是“看不见”生成出来的图的，所以它很难判断图好不好。常规做法是再接一个图片理解模型或人类反馈，把“这张图构图歪了”这个信息转化成文字，返回给Agent再做第二轮出图。

最后，关于“支持…LLM”那类搜索词，今天有几条涉及内容合规问题，本日报不展开讨论也不做推荐。我的原则很简单：分享技术可以，但触碰安全底线和公序良俗的方向一概不碰，这一点没什么可商量的。类似的合规边界，在做Agent内容生成类功能时尤其要注意，尽量在系统层就做好内容过滤，别把问题留给模型随机发挥。

6. 日报之外的闲谈

今天日报编到这儿，按惯例说点题外话。

我自己的筛选标准一直很简单：能落地的优先，能引发讨论的次之，纯标题党一概不收录。像AgentPoison这种论文，虽然离生产环境还很远，但它提醒我们一件非常现实的事：当Agent开始大规模读记忆、读知识库，数据源的信任边界就必须提上日程。以前做API只需要防输入注入，现在做Agent还得防“记忆投毒”，安全模型整个都不一样了。

最后再分享一个小习惯，算是我做Agent工程以来的切身教训：给Agent的所有外部输入，包括检索回来的文本、工具返回的数据、甚至是上一轮的对话历史，都过一遍“这真的是当前任务该信的内容吗”的轻量校验。不用很复杂，一个几行字的判断就能拦住很多事故。我做AgentPoison相关的防御实验时也发现，很多被污染的片段，第一眼看上去都极其合理，但一旦追问“这个信息是谁写的、是否经过验证”，就会露出破绽。

今天的日报就到这里。明天同一时间，继续把值得看的东西按这个标准筛一遍，有用的拿来说，没用的直接略过。