今天的Agent/LLM技术日报我按知乎的习惯来——不把热搜词全列一遍只挑出真正值得花时间看的几个方向agent开发、agent框架与编排、agent安全、LLM本地部署与精调。这些词背后其实都是同一件事大模型正在从“聊天玩具”变成“能干活的系统”而任何系统都绕不开三个问题怎么搭、怎么防、怎么跑得稳。这份内容适合正在做AI应用开发的工程师、想从Prompt工程往Agent工程进阶的算法同学以及被“Agent”概念绕晕、想搞清楚落地路径的产品和技术负责人。我会尽量把每个话题拆到可以直接动手验证的程度也会把搜热词时看不到的坑位标出来。1. 当日热词雷达Agent与LLM集中在哪些方向上1.1 从热词看行业风向的三个信号把今天这批检索词放在一起看能明显分出三条线。第一条是“框架与架构线”包括agent框架、agent架构、harness和agent区别、spring ai agent、adk.dev的Kotlin上手。搜这类词的人多半已经过了“LLM是什么”的阶段正在纠结选型想知道自家业务到底该用哪套脚手架、Agent内部的分工怎么划。第二条是“安全与可靠性线”包含agent安全、agentpoison红队、自主容错控制、以及那条很典型的报错——LLM request failed: provider rejected the request schema or tool payload。这组词特别能说明问题Agent项目一旦跑进生产系统稳定性就不再是“模型回答得好不好”而是“整套链路扛不扛得住意外”。第三条是“部署与数据线”比如安卓本地运行GGUF格式LLM、使用聊天记录模型精调LLM、LLM as Judge。搜这些词的人关注的是成本、隐私和评测——说白了就是不想把每件事都寄托在云端大模型API上想把一些环节攥在自己手里。如果把三条线合并起来看今天最值得关注的信号是大家已经不满足于“能跑通Demo”开始把Agent当成真正的软件工程来做。框架、安全、部署、评测这些都是传统软件工程在LLM时代的对应物。谁先补齐这几块短板谁就能把Agent从玩具做成服务。1.2 我给不同角色读者的阅读优先级今天热词太多信息密度不一我按读者身份给一个优先级建议。如果你刚接触Agent建议按这个顺序读先看第2章的harness与agent区别、记忆分层接着直接跳到第5章抄一个最小实现亲手跑通一次“带记忆的Agent循环”再回来补概念会比倒着读顺很多。如果你已经在生产环境维护Agent重点看第3章的安全与容错、第6章的报错速查表这两块几乎是线上事故的重灾区。如果你更关心成本与隐私第4章是为你准备的GGUF本地部署和聊天记录精调可以帮你把高频的、敏感的内容从云端请回本地。有几个热词我另外说明一下。agent ransack看起来像Agent相关技术实际上是一个老牌的本地全文检索工具跟AI Agent没有直接关系搜索时注意别混。presonl agent和pi agent信息太少没看到权威资料之前不建议调研大概率是某个垂直场景的闭源项目或社区玩具。支持nsfw llm有那些这类词我这边不展开这个方向上合规风险和内容质量风险都很高正经项目里基本用不上。2. Agent框架与编排从跑通Demo到可控生产2.1 harness和agent的真正区别今天热词里有一组“harness和agent区别”看起来基础但我觉得恰恰是很多人框架选型纠结的根源。一句话说透Agent是那段“思考-决定-行动”的模型循环而Harness是围绕这个循环的全部工程外壳——工具注册、上下文构建、错误处理、权限控制、日志追踪、计费统计统统算harness。我常用的类比是Agent是发动机Harness是底盘、变速箱、刹车和仪表盘。发动机单独也能转但只有装进车里、接上油路电路、配上刹车才敢开上路。很多人在LangChain、LangGraph或者自研框架里写了一堆代码其实90%都是在写harness真正留给模型“决策”的部分可能不超过几十行。这不是坏事恰恰是工程化的标志。但你必须能分清哪段逻辑是给模型加能力的哪段逻辑是防止模型乱来的。分不清的话出问题时你会不知道该调prompt还是该调代码。理解这个区别对选型也很有帮助。选框架时先看它替你做好了哪些harness能力再看它是否允许你替换或绕过这些能力。过度封装会限制你排查问题的空间封装不足则什么都要自己造轮子。我现在的习惯是复杂业务选成熟框架简单场景直接写原生API核心决策逻辑永远自己维护。这样既不会在冷启动时被框架拖累也不会在生产期被框架卡脖子。2.2 hermes agent把笔记库变成智能体记忆今天热词里连续出现了“hermes agent obsidian”“hermes agent安装”“hermes agent 第三方工作台”说明这个项目是今天的一个关注点。Hermes这个系列在开源圈子里通常指代可本地部署的Agent实现常见玩法是把Obsidian笔记库作为知识底座让Agent能“翻你的笔记”来回答问题。这类项目的核心思路其实很值得学习与其把记忆交给一个黑盒向量库不如让Agent直接面对你已经整理好的结构化笔记。安装这类工具的一般流程是拉取项目代码、配置模型API密钥、指定Obsidian笔记库路径、启动本地服务然后在Obsidian插件里或在工作台里与它对话。结合“第三方工作台”这个热词你会看到有人把它接入微信、Telegram、Slack之类的聊天工具本质是加了一层消息桥接聊天工具收到消息转发给Agent服务Agent拿到消息后决定是检索笔记、调用工具还是直接回答最后把结果发回聊天工具。我自己的实践经验是把个人笔记库变成Agent记忆比直接堆向量库更可控因为笔记本身是有结构的有标题、有文件夹、有双链。做这类项目时给Agent的检索指令建议写具体一点比如“先从标题匹配再读正文摘要最后才做全文检索”。这个顺序能大幅减少无关笔记的干扰。另外一定要给检索工具加上返回条数限制否则一条query把几百条笔记塞进上下文token会爆得很难看。2.3 Claude Agent Skills的第一性原理热词里有“claude agent skills: a first principles deep dive”我顺着这个思路讲讲Skills到底解决什么问题。Agent Skills这类概念在Anthropic系Agent生态中出现得比较多本质上是把“你希望Agent在某些场景下具备的执行能力”封装成一个个独立的技能包每个技能包通常包含一份说明文档和若干可执行的脚本或工具定义。为什么要这种设计第一性原理是上下文成本。System Prompt不可能无限长把所有领域知识都写进去既贵又容易让模型抓不住重点。Skills的思路是“用时才加载”Agent遇到一个任务先判断需要哪个技能再动态把对应说明与工具取出来使用。这就像你出远门不需要背一整本书遇到问题翻对应的那几页就行。对开发者的启发在于不要再把Agent的Prompt写成一本百科全书。把高频、高价值的能力拆成可复用的技能包每个技能包保持内聚做什么、什么时候用、需要哪些工具、有哪些失败处理。这样既减少了上下文占用也让Agent的能力边界变得清晰可测。团队协作时不同人负责不同技能包版本管理也更干净。2.4 ADK Kotlin在JVM上50行跑通一个Agent热词“adk.dev 的 kotlin 快速上手在 jvm 上跑通一个 agent”指向的是 Google 的Agent开发套件Agent Development Kit的Kotlin版本。这类多语言SDK的出现对后端和安卓开发者是个好消息你不需要为了做一个Agent去学一套新的Python生态在已有的JVM技术栈里就能把Agent跑起来。Kotlin上手的大致步骤可以这样理解先建一个Gradle项目引入ADK依赖再定义一个Agent实例给它指定模型和工具列表最后丢一句任务进去跑。伪代码看起来会是这样val agent AdkAgent { name reminderAgent model geminiModel(gemini-2.5-pro) tools reminderTool() description 负责创建和查询提醒 } fun main() runBlocking { val response agent.run(帮我查一下明天早上有没有会议) println(response.text) }虽然不同版本的SDK在API细节上会有差异但结构是稳定的定义Agent、挂工具、跑对话。Kotlin另一个天然优势是协程Agent跑长任务时发异步请求、并发执行多个工具在协程模型下写起来比回调地狱清爽太多。如果你本身就是Java或安卓背景想从“调API”升级到“搭Agent”顺着ADK的Kotlin示例走一遍是成本很低的入门路线。2.5 agent记忆的工程落地短期与长期分层“agent记忆”是今天出场频率很高的热词但很多人对记忆的理解还停留在“把聊天记录存下来”。真正的Agent记忆工程至少要分两层短期记忆对应模型上下文窗口内的信息长期记忆则要落到外部存储。短期记忆的管理核心是“剪辑”你要决定哪些内容留在上下文里、哪些内容在对话轮次之间滚动丢弃。长期记忆的管理核心是“索引”你要决定哪些知识值得写入记忆、用什么结构保存、检索时怎么召回。以最简单的长期记忆实现为例可以先用一个JSON文件当存储把每个会话的结构化摘要追加进去。每轮对话开始前先读取文件里与当前问题相关的记录注入系统提示对话结束后把新信息写入文件。跑通这个链路之后再换成向量数据库也不迟——先懂逻辑再上工具。这里我要强调一个容易忽略的点记忆写的质量比读的效率更关键。很多Agent做久了“记忆越来越笨”不是因为检索慢而是因为什么都往记忆里写导致噪声淹没信号。我通常会让模型在每轮对话结束时自己总结“本次对话值得长期记住的三句话”只存这个摘要不存原始对话。这个小小的设计能显著提升长期记忆的信噪比。3. Agent安全与可靠性红队视角和容错工程3.1 AgentPoison往知识库投毒的攻击思路热词“AgentPoison: red-teaming llm agents via poisoning memory or knowledge base”值得所有做RAG类Agent的人重视。AgentPoison这类研究表面看是一种攻击方法实际上是在提醒我们Agent的知识来源不可信时整个决策链都会被带偏。攻击者不需要修改模型权重只需要在Agent会检索到的记忆库或知识库中插入少量精心构造的恶意内容当Agent检索到这些内容时就可能被诱导执行错误操作、泄露内部信息或者做出有害决定。我把它类比成导航软件被“下毒”导航本身没问题但地图上被偷偷改了路口指示司机按指示走就会开进错误的地方。Agent也一样它无法判断检索到的每一条内容是否安全尤其是当攻击文本写得和正常内容高度相似时。防御思路有四个层次第一层是数据源白名单只允许Agent检索可信的、经过审核的文档库从源头缩小投毒面第二层是注入检测在检索结果喂给模型之前用规则或另一个模型扫描可疑指令片段第三层是行为审计对Agent的关键动作发消息、提权、调用外部API记录日志并设置异常告警第四层是人工确认对高风险操作增加一个确认闸门宁可慢一步也不要被带偏一步。RAG不是简单的“检索增强生成”它是一个新的攻击面每一个接入的数据源都是一个新的输入口。3.2 从schema拒错看工具调用稳定性今天热词里有一句完整报错LLM request failed: provider rejected the request schema or tool payload.这句话几乎出现在每个Agent项目的中后期原因非常集中模型生成的工具调用参数不符合API提供方对工具定义的要求。要么是JSON Schema写得不标准要么是工具名称包含了不合法字符要么是参数类型与定义不一致——比如Schema里声明了integer模型返回了floatProvider直接拒掉。遇到这个错误我的排查顺序是固定的。第一步把发送给Provider的完整请求体打出来不要只看错误信息看payload里tools数组长什么样。第二步检查每个tool的name是否只用了字母、数字、下划线和连字符这是最容易被忽略的坑。第三步检查parameters的JSON Schema是否遵循了OpenAI兼容的格式多余的关键字如minLength、pattern在部分兼容接口上会导致校验失败。第四步用最简单的工具定义比如不带任何参数的工具做对照实验逐步缩小问题范围。这个报错教会我一个道理模型本身没问题出问题的是模型和工具之间的“接口契约”。合同写得不严谨执行方就会乱理解。所以我现在写Agent时会把工具定义当成API文档来对待每个参数都写清楚类型和取值范围并且在上线前跑一次“全工具空转测试”确保每个工具在最小合法参数下都能正常响应。3.3 自主容错控制让故障成为可处理输入热词“大模型llm智能体自主容错控制构建可靠ai系统的工程实践”其实指向一个深层问题Agent在真实环境中必然遇到工具失败、网络超时、数据异常系统的可靠性不是靠“期望模型不犯错”而是靠“模型犯错之后系统能撑住”。容错设计的目标是把故障变成一种“可处理的输入”而不是让整条执行链直接终止。我见过太多Agent项目长跑任务莫名其妙失败日志里只有一句agent execution terminated due to error。这种问题的根因几乎都不是模型“变笨了”而是某一环的工具调用抛出了未捕获异常直接把整个Agent循环打崩。解决办法很笨但很有效在每个工具函数的入口和最外层各包一层异常捕获把错误信息转换成字符串返回给模型。比如日历工具超时了不抛出异常让循环死亡而是返回字符串“calendar_api_timeout: the calendar service did not respond within 5s”模型拿到这个错误描述后可以自行决定是重试、换方案还是告诉用户改天再查。除了异常捕获三层控制也值得做好第一层是任务级控制给Agent整个执行链设置最大步数和总时长上限防止死循环和费用失控第二层是工具级控制给每个工具设置独立的超时时间和重试策略第三层是降级控制为关键工具准备替代方案比如日历挂了就生成一个ICS文件让用户自己导入而不是干瞪眼。可靠性不是把故障消除而是让故障发生时体验依然可控。3.4 安全清单部署agent前必须自查的项目与其等线上事故再排查不如把安全检查提前。我列一个部署Agent前必须自查的清单这些都是热词里“agent安全”涵盖的实操点检查项为什么重要最低要求输入注入测试用户的输入可能被当作指令诱导Agent执行越权行为重点测试“忽略之前的指令”类注入工具权限最小化Agent能调用的工具就是它的权限边界工具越多风险越大只挂当前任务必需的工具删除调试工具数据返回过滤工具返回的数据可能包含HTML、代码、敏感字段直接进模型有风险对返回内容做长度限制和敏感词脱敏执行审计日志出问题时唯一能还原现场的就是日志记录每次工具调用的入参、出参、耗时人审闸门高风险操作删除、提权、发通知、花钱不能全自动关键操作前增加审批或确认步骤依赖与权限三方包和运行环境本身可能成为攻击向量锁定依赖版本Agent运行容器不授予宿主机写权限这套清单不是上线前一次性过一遍就结束而是每次新增工具、每次改Prompt、每次接新数据源之后都应该重跑一遍。安全不是一个状态而是一个持续的过程。4. LLM基础设施与精调实战本地部署、评测与token4.1 安卓8老设备跑GGUF模型的选型思路热词“安卓本地运行gguf格式llm软件支持安卓8”让不少想在老手机上离线跑大模型的人兴奋。先说结论安卓8的设备跑得动但别指望跑7B级别以上的模型能流畅。GGUF是一种经过量化压缩的模型格式核心思路是把权重压缩成更小的位宽换取更低的显存和内存占用。对老设备来说选模型的关键不是看参数量而是看量化等级和实际内存占用。我给一个选型参考1B-3B级别、Q4_K_M或Q5_K_M量化的模型内存占用大概在1.5GB到3GB之间适合内存4GB以上的安卓8设备推理速度一般对话场景可用7B级别即便用Q4量化也需要4GB到5GB内存老手机基本会卡死或者触发系统杀进程。所以老设备的正确打开方式是选小模型、选低量化、降低期望值。工具层面支持GGUF的安卓工具通常基于llama.cpp的移动端方案核心逻辑都是加载GGUF文件、用CPU或Vulkan GPU推理。安装之后注意三件事第一把模型文件放到应用能稳定读取的目录不要频繁读写下载目录第二首次加载模型会花较长时间不要误以为死机第三推理时保持屏幕常亮防止后台被系统回收。实测下来这类工具在安卓8上的体验比想象中好但前提是把模型规模控制在设备承受范围内。4.2 如何把聊天记录变成精调样本热词“使用聊天记录模型精调llm”是一种非常实用的低成本定制路径拿真实聊天记录转成训练格式对模型做LoRA或QLoRA微调让模型适应当前场景的口吻、逻辑和知识。这个做法比从零训练便宜很多效果也往往让人惊喜。转化的核心是把聊天记录整理成对话样本标准格式如下{messages:[{role:system,content:你是一个售后服务助手},{role:user,content:我昨天买的耳机连不上蓝牙怎么办},{role:assistant,content:可以先尝试长按耳机触控区5秒进入配对模式然后在手机蓝牙列表里删除旧设备重新搜索。}]}整jsonl文件一行一个样本。实际操作中有三个加工步骤第一是清洗去掉重复句子、广告内容、个人隐私信息第二是切分长对话按主题切成多轮小块避免单条样本过长第三是去偏检查有没有一边倒的倾向性言论避免模型学到不当风格。关于数据量我要打破一个迷信几百条高质量样本就能带来肉眼可见的风格变化微调大数据更容易出现灾难性遗忘。用LoRA跑一遍先把学习率设在1e-4左右跑几个epoch后看验证集loss不要为了“多跑几轮更有效”而盲目过拟合。微调完之后一定要拿没参与训练的真实对话做盲测才能确认模型真的变好了。4.3 LLM as Judge把评测变自动化的关键与陷阱“LLM as Judge”是今天热词里我很想展开的一个因为它看起来好用用起来全是坑。核心思路是用一个强大的LLM去给另一个LLM的输出打分替代人工评测。优点显而易见速度快、成本低、可复现。但直接拿“你觉得这个回答好不好”当prompt评测结果会很飘。几个已被验证的陷阱值得记住。一是位置偏差同一对回答调换顺序LLM的打分可能改变所以对比评测时应该交换顺序测两遍。二是自我偏好用GPT去评GPT的答案往往偏向GPT风格换不同家族模型做评测可以缓解。三是评分标准模糊让模型自由发挥评语不如给它具体的rubric比如“内容是否忠实于给定材料”“是否回答了用户所有子问题”“格式是否清晰”每项单独打分。四是多轮任务不能用单轮pairwise对比要按整个任务轨迹评估看Agent有没有在关键步骤上走错。我给一个小建议LLM as Judge适合做初筛把明显差的答案过滤掉但关键指标、核心功能仍然需要人工抽检。自动化评测的价值不是替代人而是把人的精力集中在少数疑难样本上。4.4 token在agent场景中的真实含义热词“ai agent token是什么意思”对于刚接触Agent的人确实是个容易懵的术语。Token是模型处理文本的最小单位英文大概一个token对应半个到四分之三个单词中文大约一个字可能对应0.6到2个token。API按token计费上下文窗口按token算这些都好理解。但在Agent场景下token的含义要扩大它不只包括用户输入和模型输出还包括塞进上下文里的工具定义、检索回来的知识片段、以及Agent维护的记忆内容。也就是说你每次调用模型的成本是“用户问题 工具定义 检索内容 历史记录 模型输出”的总和。很多Agent项目月账单爆掉不是用户问题多而是工具定义太长、检索内容太多、历史记录舍不得裁剪。控制token的方法有三个方向一是给每个工具写简短的描述别把几页文档粘进系统提示二是检索结果按需截断只保留与问题最相关的前N条每条限制字数三是对话历史做摘要压缩而不是无限累积原始记录。把这三点做了同样功能的Agent成本能降一半以上响应速度还会更快。5. 从热词到可抄的作业三个最小实现5.1 30分钟搭一个带记忆的最小Agent文字讲再多不如自己跑一遍。这个最小Agent的核心诉求是能调用一个工具能记住之前聊过的事情。我用Python加OpenAI兼容接口来演示思路同样适用于其他任何语言和模型服务。先定义工具函数这里用一个简单的“查询今日天气”工具真实项目中换成任何API都一样def get_weather(city: str) - str: # 真实项目中这里调用天气API return f{city}今天多云气温22-28度出门建议带伞。然后定义一个简化的记忆函数用JSON文件存取import json, os MEMORY_FILE memory.json def load_memory(): if os.path.exists(MEMORY_FILE): with open(MEMORY_FILE, encodingutf-8) as f: return json.load(f) return [] def save_memory(entry): mem load_memory() mem.append(entry) mem mem[-20:] # 只保留最近20条摘要 with open(MEMORY_FILE, w, encodingutf-8) as f: json.dump(mem, f, ensure_asciiFalse, indent2)再写主对话循环先加载记忆拼接系统提示再调用模型接口等模型返回工具调用结果执行工具后把结果返回模型最后生成回答并写入记忆。跑通这个循环你会第一次直观感受到“模型决定做什么代码负责执行”的分工。这30分钟的投入比看十篇文章都值。5.2 给Agent加一个Skill把Obsidian变成可查询工具当我们把Obsidian笔记库接给Agent时实际上就是在做一个Skill定义一个工具让Agent能按标题搜索笔记、读取笔记内容。最简实现可以只用两个工具函数。第一个是获取笔记标题列表第二个是根据关键词检索笔记标题返回匹配结果。注意这里的关键技巧是工具返回给模型的应该是“摘要或路径”而不是整篇笔记原文。把整篇笔记塞进上下文会让token翻倍也让模型容易被无关细节干扰。实现方式可以是Agent收到用户问题后先调用search_notes拿到标题列表再调用read_note读取选中笔记的前N行作为上下文。这样既控制了token也让Agent的每一次读取都有明确目的。我自己的Obsidian Agent跑得很稳靠的就是这种“先查标题再读正文”的两步策略。5.3 Agent扛并发的架构套路热词“ai agent怎么扛并发”是一个很现实的架构问题。直接同步调用LLM做长任务一台服务并发量一高就会被拖死因为单个Agent任务往往长达十几秒到几分钟还涉及多轮工具调用。扛并发不是让LLM接口变快而是让系统结构适应慢接口。推荐套路是把Agent改造成“任务队列加Worker池”模型。Web服务只负责接收请求、写一条任务到队列、立刻返回任务ID给前端后台一组Worker进程从队列里取任务执行完整的Agent循环状态更新到Redis前端通过轮询或Webhook查询任务状态。这样带来的好处有两个一是慢任务不会阻塞HTTP请求线程二是可以横向扩容Worker数量来提升吞吐。另一个关键点是幂等性。同一个任务被重复执行两次结果应该一致否则Agent里任何一次超时重试都可能造成重复扣费或重复发消息。做法是给每个任务生成唯一ID在关键副作用动作比如发邮件、写数据库之前先检查这个ID是否已经执行过。并发问题里有一半其实是状态管理问题先把状态机设计清楚并发自然就稳了。6. 今日问题排查速查表与个人避坑心得6.1 终端里的编码AgentCodex类工具怎么用不翻车热词里那句“welcome to codex, openais command-line coding agent sign in with chatgpt to”指向的是OpenAI推出的命令行编码智能体。这类工具运行在终端里能读取仓库、修改代码、执行测试开发者的工作流从“自己动手写”变成“指导Agent写”。但也正因为它能直接操作代码用起来比普通聊天Agent更需要纪律。我的使用心得有三条。第一先让它“读”再让它“改”。给任务之前明确要求它先列出相关文件和它理解的现状确认无误之后才允许动手。这样能避免Agent凭空改错地方。第二每改一步都要求它跑测试。没有测试验证的代码修改和没写没什么区别。第三明确“你不能动什么”。比如“只修改src目录下的代码不碰配置文件不升级依赖”用规则把风险边界划出来。终端类的编码Agent潜力很大但它不是神是一个需要你当项目经理的实习生。6.2 常见报错与排查建议速查表每天都有新朋友踩同样的坑我把今天的多个报错热词整理成一张速查表方便直接检索使用。报错或症状常见原因排查与处理建议provider rejected the request schema or tool payload工具定义JSON Schema不合法或工具生成的参数与定义不符打印完整请求体逐字段检查工具name、parameters类型必要时做最小化复现agent execution terminated due to error某个工具函数抛出了未捕获异常导致Agent循环崩溃给每个工具函数加异常捕获把错误转为字符串返回给模型让模型自己决定降级策略并发一高就超时LLM调用是慢IO同步调用阻塞了服务线程改成异步IO或任务队列加Worker池给每个LLM调用设超时和重试退避上下文爆掉费用飙升工具定义过长、历史记录无限累积、检索内容过多精简工具描述对历史做摘要压缩检索结果限制条数和单条长度记忆越用越笨什么内容都写进长期记忆噪声盖过信号只让模型保存“值得长期记住的摘要”定期清理记忆库GGUF模型在安卓上崩溃或卡死模型参数量、量化等级超出设备内存换更小的模型或更低的量化等级先看运行内存占比再决定6.3 六条个人避坑心得第一条先别急着上框架用原生API写一遍Agent主循环再选型你才能真正看懂框架替你做了什么、掩盖了什么。第二条Agent的安全问题不是上线后才考虑的工具注册表写下的那一刻攻击面就存在了。每次新增一个工具都问自己有人恶意调用这个工具会怎么样第三条每个Agent项目都要有一个固定评测集哪怕只有二十条任务样例没有评测就调优等于闭眼开车。第四条记忆系统做好“写控制”比“读优化”更优先垃圾进垃圾出检索再快也救不了。第五条任何Agent都要给人留一个“拔电源”的按钮无论是任务撤销、步数上限还是人审闸门这个按钮平时不起眼出事时就是救命稻草。第六条也是我今天最想说的每天看热词时别只看热闹把停留在概念层的词转化为一个周五下午能做完的小实验。今天这些热词里我已经把三个加入了实验清单——把Obsidian笔记变成Skill、给安卓8老手机装一个GGUF小模型、用聊天记录精调一个小LoRA。如果你也测了哪个方向欢迎在评论区交换结论下期日报里我会把值得复盘的实验结果放进去。