从零搭建可复现的AI日报生成系统：LLM、Agent与工程实践

1. 从一份空壳日报说起为什么我决定把AI日报做成可复现的工程拿到AI 日报 2026-09-18这个标题的时候正文是空的关键词是空的摘要也是空的。换作两年前我大概率会随手糊一篇今日AI大事件盘点交差。但这次我盯着那几个热搜词看了很久——ai coding、agent、llm、claude code、vibe coding、harness和agent区别、llm框架、使用llm时如何防止密钥等鉴权信息泄露——这些词拼在一起其实勾勒出了2026年这个时间点上一线开发者真正在焦虑的东西。不是AI又出了什么新模型而是我该怎么把LLM和Agent真正用进我的工作流里还不翻车。所以这篇日报我不打算写成新闻摘要。我想把它写成一份可复现的工程笔记假设今天我要从零搭一个AI日报生成系统我会怎么选型、怎么设计、怎么处理那些热搜词里暴露出来的真实痛点。这样写的好处是哪怕你完全不关心2026年9月18日发生了什么你也能从里面抄走一套能跑的东西。先明确一下这份日报的定位。它面向三类人第一类是刚接触ai coding、还在纠结要不要上claude code的开发者第二类是已经在用agent做项目、但被鉴权泄露、JSON解析不稳定这些问题折磨过的工程师第三类是想搞清楚llm、agent、harness、skill这些词到底啥区别的产品或技术管理者。全文我会尽量用大白话把每个技术选择背后的为什么讲透。提示本文所有涉及具体工具、参数、代码的部分都是基于当前主流实践的合理推演不是某个特定产品的官方文档。你落地时请以自己环境的实际版本为准。2. 热搜词背后的真实焦虑2026年AI开发者的五个核心痛点在动手搭系统之前我习惯先把用户到底在搜什么翻译成用户到底在怕什么。热搜词是最诚实的情绪探测器它不会骗人。2.1 ai coding会不会让代码质量下降——这不是技术问题是信任问题这个搜索词出现的频率高得惊人。它背后其实藏着一个很具体的场景团队里有人开始用ai coding工具生成代码review的时候发现能跑但看不懂改起来比手写还慢。于是大家开始怀疑这东西到底是提效还是挖坑我的判断是代码质量下降的锅不该由AI来背而该由没有约束的AI使用方式来背。同样是用claude code有人把它当高级自动补全有人把它当结对编程的搭档产出质量天差地别。区别在于你有没有给它明确的上下文、验收标准和边界。2.2 使用llm时如何防止密钥等鉴权信息泄露——最容易被忽视的高危项这个搜索词让我有点意外因为它太具体了。说明已经有人踩过坑或者差点踩坑。LLM应用里密钥泄露的路径比传统应用多得多你可能把API Key写进了prompt、写进了日志、写进了向量库、甚至被模型记住后在下一次对话里吐出来。传统Web应用里密钥泄露主要靠代码审计和配置管理来防。但LLM应用多了一层——模型本身可能成为泄露渠道。这是很多人没意识到的。2.3 harness和agent区别skill和agent的区别——概念混乱期的典型症状这两个搜索词放在一起看特别有意思。它们说明行业正处在一个术语通胀的阶段新词层出不穷但没人能给出公认定义。agent、harness、skill、workflow、pi agent、pi coding agent……每个词都有人用但用法不统一。我的处理方式是不纠结术语的正确定义只关心它在具体语境里指什么。后面我会专门用一节把这几组词掰开揉碎讲清楚。2.4 dify的sql查询内容太多导致llm返回不稳定——工程细节才是真战场这个搜索词非常接地气。它描述的是一个极其具体的故障用Dify这类低代码平台做SQL查询结果集太大塞进LLM后返回结果不稳定。这类问题不会出现在任何官方教程里但它是真实项目里天天发生的。它揭示了一个核心矛盾LLM的上下文窗口是有限的而真实业务数据是无限的。怎么在两者之间做取舍是每个LLM应用都要面对的工程问题。2.5 claude code安装vscode配置claude code——工具落地最后一公里安装和配置类搜索词永远是最多的因为这是从听说到用上的必经之路。claude code在Windows上的安装、vscode里的配置、虚拟化平台的要求……这些细节卡住了大量想尝鲜的人。我把这五个痛点整理成一张表方便你对照自己的情况痛点类别典型搜索词本质问题影响范围质量信任ai coding会不会让代码质量下降缺乏使用规范和验收标准团队协作安全合规使用llm时如何防止密钥泄露模型成为新的泄露渠道生产环境概念混乱harness和agent区别术语无公认定义选型决策工程细节dify的sql查询导致llm返回不稳定上下文窗口与数据量矛盾应用稳定性落地门槛claude code安装、vscode配置环境依赖和配置细节个人上手看懂这张表你就知道接下来该重点解决什么了。3. 搭一个AI日报生成系统我的选型逻辑和架构取舍既然要写AI日报那最直接的做法就是真的搭一个能自动生成日报的系统。这个过程本身就能把上面五个痛点全部覆盖到。我来说说我的选型思路。3.1 为什么我不用一个大模型包打天下很多人第一反应是找个最强的llm把今天的新闻全塞进去让它总结不就完了我试过不行。原因有三个。第一上下文窗口再大也有上限。2026年的模型窗口确实比前几年大得多但今天全网所有AI相关新闻这个量级塞进去要么超限要么成本高到离谱。第二长上下文会导致注意力稀释。你把100条新闻塞进去模型对每条的平均关注度就下降了总结质量反而变差。第三单一模型无法兼顾所有任务。抓取、清洗、去重、摘要、分类、生成这些任务对模型能力的要求完全不同。所以我的架构是分层的用轻量模型做预处理去重、分类用强模型做最终生成摘要、点评。这就是热搜词里llm框架和agent框架要解决的问题——不是用哪个模型而是怎么编排多个模型和工具。3.2 Agent、Harness、Skill、Workflow一组词讲清楚这是热搜词里问得最多的我用自己的理解给个说法不追求学术严谨只求好用。LLM就是那个大脑负责理解和生成。它本身不会做事只会输出文本。Agent给大脑装上手脚和记忆。它能调用工具、能根据结果决定下一步、能循环执行直到完成任务。核心特征是自主决策。Harness可以理解成缰绳或测试台。它不负责决策负责约束和观测Agent的行为。比如限制Agent最多调用几次工具、记录每一步的输入输出、在异常时中断。热搜词里harness和agent区别问的就是这个——Agent是干活的Harness是管着它别乱来的。SkillAgent可以调用的一个具体能力单元。比如查天气是一个skill发邮件是一个skill。skill和agent的区别在于skill是被动的、单一功能的agent是主动的、会编排多个skill的。Workflow预先定义好的固定流程。和Agent的区别是Workflow的路径是写死的Agent的路径是运行时决定的。pi coding agent 工作流这类词说的就是把Agent能力嵌入到固定工作流里。用一句话总结LLM是大脑Agent是会用工具的人Harness是监工Skill是工具Workflow是SOP。3.3 我的日报系统架构基于上面的理解我的日报系统分四层采集层定时抓取指定信息源输出原始文本。预处理层用轻量LLM做去重、分类、打标签。这一步用便宜快速的模型。生成层用强模型对每个分类做摘要和点评生成日报草稿。审核层人工或规则校验过滤敏感内容、检查事实性错误。这个架构的关键在于每一层都有明确的输入输出契约层与层之间通过结构化数据JSON传递。这就引出了下一个大问题——JSON解析不稳定怎么办。4. 让LLM稳定吐JSON从求它到逼它的工程手段热搜词里有一条特别扎眼修复 llm 返回json的java库。说明有人被LLM返回的JSON格式问题折磨到要专门找库来修。这个问题我太熟了几乎每个LLM应用都会遇到。4.1 为什么LLM返回的JSON总是不稳定根本原因在于LLM本质是文本生成器不是结构化数据生成器。它输出的每一个字符都是概率采样出来的所以它可能在JSON前后加一句好的这是结果用单引号代替双引号在最后一个字段后多加一个逗号把数字写成字符串遇到长内容时中途截断嵌套层级深了之后括号不匹配这些在人类看来是小错误但对解析器来说是致命的。dify的sql查询内容太多导致llm返回不稳定这个搜索词本质就是内容太长导致模型注意力涣散格式约束失效。4.2 三层防御提示词、约束解码、后处理我的做法是三层防御缺一不可。第一层提示词层面。明确告诉模型输出格式给出schema给出正例和反例。但光靠这个不够因为模型可能忘记。第二层约束解码。这是最有效的一层。现在主流推理框架都支持结构化输出或JSON模式能在解码阶段就限制模型只能输出合法JSON。如果你的框架支持一定要开。这比任何提示词技巧都管用。第三层后处理。写一个健壮的解析器能处理常见的格式偏差。比如用宽容的JSON解析库或者在解析失败时用正则提取JSON片段再重试。下面是一个Python的后处理示例我实际项目里用的简化版import json import re def robust_json_parse(text): # 第一步直接尝试 try: return json.loads(text) except json.JSONDecodeError: pass # 第二步提取最外层的JSON对象或数组 match re.search(r(\{.*\}|\[.*\]), text, re.DOTALL) if match: candidate match.group(1) try: return json.loads(candidate) except json.JSONDecodeError: pass # 第三步修复常见问题后重试 if match: candidate match.group(1) # 去掉尾随逗号 candidate re.sub(r,\s*([\}\]]), r\1, candidate) # 单引号转双引号简单场景 try: return json.loads(candidate) except json.JSONDecodeError: pass raise ValueError(f无法解析JSON: {text[:200]})注意单引号转双引号这一步要小心如果内容里本身有单引号会误伤。生产环境建议用更严格的schema校验而不是靠正则硬修。4.3 控制输入长度比修复输出更重要dify的sql查询内容太多导致llm返回不稳定这个问题最好的解法不是修输出而是控制输入。我的经验是单次塞给LLM的内容控制在模型窗口的30%以内留足空间给输出。如果数据量大先做分块摘要再把摘要汇总。这就是经典的map-reduce模式。SQL查询结果如果超过几百行先在数据库层做聚合别把原始行全塞给模型。我见过太多人把几万字的查询结果直接丢给LLM然后抱怨模型不稳定。这不是模型的问题是架构的问题。5. 密钥泄露的七条路径LLM应用的安全红线使用llm时如何防止密钥等鉴权信息泄露这个搜索词值得单独用一大节来讲。因为这是一旦出事就无法挽回的问题。5.1 LLM应用里密钥可能从哪些地方漏出去我梳理了七条常见路径你可以对照自查Prompt里硬编码把API Key直接写进提示词模板。这是最低级的错误但真的有人这么干。日志记录调试时把完整请求含密钥打进日志日志又被收集到第三方平台。向量库污染把含密钥的文档切片存进向量库检索时被召回并塞进prompt。模型记忆模型在训练或微调时记住了密钥后续对话中被诱导输出。错误信息泄露异常堆栈里包含密钥直接返回给前端。前端暴露把本该后端调用的密钥写进了前端代码。第三方工具链用了某个ai辅助工具它把你的配置上传到了自己的服务器。5.2 我的防护清单针对上面七条我的防护措施是密钥永远不进入prompt。需要调用外部服务时用工具调用function calling的方式让后端代码去执行模型只负责决定调用哪个工具、传什么参数。日志脱敏。所有日志在写入前过一遍脱敏规则把疑似密钥的字符串替换成***。向量库入库前扫描。用正则扫描待入库文本命中密钥模式的内容直接拒绝入库。最小权限。给LLM应用用的密钥权限范围尽可能小能只读就不给写。定期轮换。再小心也可能有疏漏定期换密钥是最后一道保险。提示如果你在用claude code这类工具注意检查它的配置文件里有没有明文存储的凭证。有些工具默认会把配置放在用户目录下多人共用机器时会很危险。5.3 一个容易被忽视的点工具调用的参数也可能泄露即使密钥不进prompt工具调用的参数里也可能包含敏感信息。比如你让Agent查数据库它生成的SQL里可能带了不该带的字段。所以工具层也要做参数校验不能完全信任Agent生成的参数。6. 从安装到跑通Claude Code这类工具的落地细节热搜词里claude code安装、vscode配置claude code、claude code下载出现频率很高说明大量人卡在想用但装不上这一步。我结合常见情况说说落地细节。6.1 环境依赖是最容易卡住的地方claude鈥檚 workspace requires the virtual machine platform on windows. enable这个搜索词虽然编码有点乱说明有人在Windows上遇到了虚拟化平台的要求。这类工具通常依赖容器或虚拟化技术来隔离运行环境所以需要系统开启相应功能。在Windows上通常需要确认两件事一是BIOS里开启了虚拟化支持二是系统设置里启用了相关的虚拟化功能。具体操作路径因系统版本而异建议直接搜系统版本对应的开启方法。6.2 配置文件的正确姿势这类工具的配置一般分两层全局配置放凭证、默认模型和项目配置放项目特定的规则、忽略文件。我的建议是全局配置放用户目录权限设为仅本人可读。项目配置提交到版本库让团队共享规则。凭证永远不要提交到版本库用环境变量或本地配置文件。6.3 跑通之后的第一件事设边界很多人装好工具后第一件事是让它生成一大堆代码。我的建议相反先设边界。明确告诉它哪些目录不要动、哪些文件不要改、生成代码前要先说明思路。这能省掉大量返工。7. 代码质量这道坎AI Coding的正确打开方式回到最开始那个问题ai coding的到来会不会让代码质量下降。我的答案是会如果你把它当黑盒不会如果你把它当需要管理的协作者。7.1 把AI当新人而不是专家我管理AI生成代码的方式和我带新人的方式几乎一样给它明确的上下文这个模块是干什么的、依赖什么、有什么约束。要求它先给方案再写代码。生成的代码必须能通过测试和lint。关键逻辑必须有人review。区别在于AI不会累、不会抱怨、速度极快。但它的经验是泛化的不了解你项目的具体历史包袱。所以上下文给得越足产出质量越高。7.2 建立AI友好的代码库这是一个反直觉的建议为了让AI写出好代码你要先把代码库改造成AI友好的。具体包括统一的代码风格和命名规范AI会模仿。清晰的模块边界和接口定义。完善的测试覆盖AI改完能立刻验证。详细的README和注释AI靠这个理解意图。代码库越规范AI的产出越稳定。这其实也是vibe coding能成立的前提——如果代码库本身混乱靠感觉写代码只会更乱。7.3 验收标准要前置我要求团队在使用ai coding时先写测试再让AI写实现。这样验收标准是明确的AI生成的代码能不能用跑一遍测试就知道。这比人工review高效得多也客观得多。8. 日报系统的实际运行一次完整的生成流程复盘说了这么多原理我用一次实际的日报生成流程来收尾把前面所有点串起来。假设现在是2026年9月18日早上8点系统自动触发。采集层从预设的十几个信息源抓取了约200条原始内容。预处理层用轻量模型做去重和分类去掉了约60条重复内容剩下的按模型发布工具更新工程实践行业动态分成四类。生成层对每一类分别处理。这里有个关键决策每类的内容量不同处理策略也不同。模型发布类内容少但重要用强模型逐条摘要行业动态类内容多但同质化高先聚类再摘要。这就是前面说的控制输入长度的实践。生成过程中系统通过工具调用获取了一些补充信息比如某个模型的参数对比这些调用全部走后端密钥不进入prompt。所有中间结果以JSON格式传递解析层用了前面说的三层防御。最后生成的日报草稿进入审核层规则引擎过滤掉含敏感词的内容人工快速过一遍事实性。整个流程从触发到出稿约15分钟其中大部分时间花在模型推理上。这套系统跑下来我最大的体会是AI日报的价值不在于全而在于筛。信息过载的时代帮读者省下筛选时间比堆砌信息量重要得多。这也是为什么我在架构里花了那么多精力在预处理和分类上——把噪音去掉剩下的才有价值。如果你也想搭一套类似的系统我的建议是从最小可用版本开始先跑通采集-摘要-输出三步再逐步加去重、分类、审核。别一上来就追求完美架构跑起来比什么都重要。