Playwright 是一个用于 Web 自动化和端到端测试的开源框架。如果我们将他和LLM结合，就可以实现“自愈”的自动化测试，这样如果UI有了改动框架不再硬性失败而是在检测到失败之后分析当前的 DOM（Document Object Model），基于规则的策略自动恢复出一个能用的 locator。自愈遵循一条严格的三阶段 pipeline。

这就是Context Poisoning —— 即恶意或臃肿的工具描述污染 agent 推理过程 —— 已被 OWASP 列为 LLM 应用的头号漏洞，2025 年已经超过 100,000 个站点被攻击。

RAG 是一个先选内容再做生成的系统；retriever 不搜索文档，它搜索 chunks。chunks 有问题了那么检索还没开始就已经完蛋了，所以我们可以用结构感知切分修这一点，把标题、代码块、警告框保持在一起。

生产里真正有分量的工作流是能批量处理几千份保险理赔、跑完一周的销售触达节奏、跨系统对账等等的复杂工作，而这些是没办法塞进一次对话轮次里。因为他们的处理时间以天为单位，而不是秒。

要做这样一个 AI 助手:能上网查资料、能读写文件、能记住过去的对话,还能在执行有风险的操作前先征询人类的意见。听起来是不是很复杂，其实并不是LangChain 生态里现成的几套工具,把开发时间压到了几个小时。不过这里就多了一个问题：

1M token 上下文设置下，DeepSeek-V4-Pro 的单 token 推理 FLOPs 仅为 DeepSeek-V3.2 的 27%，KV Cache 仅为 V3.2 的 10%；V4-Flash 更激进——FLOPs 10%、KV Cache 7%。百万上下文从演示用 demo，变成了可以日常跑的工作负载。

Graphify 是一个 Python 工具，同时也是一个 Claude Code skill。它把分析工作一次性做完，把所有内容压缩成一张可查询的知识图谱，放到磁盘上。后续查询走图谱遍历，不再重新读取原始文件。项目简介的数字是：在混合语料库上每次查询的 token 量降低 71.5 倍。虽然这个数字是项目方自己测的是否站得住脚还要验证，但是...

ReAct（Reason + Act）架构要解决的问题是开放式研究里最经典的问题。本文要做的是一个 Research Brief Agent：会上网搜索、抓取真实 URL、压缩证据，最终产出一份带真实引用的结构化简报。重点不在于功能，而在于 正确写法——不再依赖那种脆弱的 "Thought: / Action:" 字符串解析。

现在介绍LangGraph 和 LangChain 的文章。每一篇的结论都差不多：简单流程用 LangChain，复杂的用 LangGraph。

这就是我们所说的幻觉，它是一个跨层级的问题：推理参数、系统架构、生成策略、生成后验证、模型训练、持续评估，每一层都有份，所以不能把它当成单点问题来处理。

数据增强是现代机器学习中一个绕不开的环节。在计算机视觉里，不做增强就很难训练出一个好的的模型；在时间序列分类领域，虽然也已经沉淀出一套相对成熟的技术——jittering、scaling、window slicing、time warping、permutation、rotation，还有若干基于模式的变体，但时间序列预测是另一回事。

每一次 LLM 调用都是无状态的。模型读上下文窗口，生成响应然后忘掉一切。这对单轮问答没问题。对下列任何一类 Agent，这都是致命的：保持连续性——"我昨天刚跟人说过这件事，为什么还要再解释一遍？"从交互中学习——Agent 应当知道这个用户的账户、历史问题、首选语言积累组织知识——哪些解决路径能关闭工单，哪些意图预示...

Claude 4.7刚发布不久他的Prompt就已经被Hack出来了，仔细看 Claude 的系统设计会发现一件有意思的事：它不只追求聪明，还在试图约束自身的行为。

RAG 流水线部署完毕、检索正常运行、LLM 按部就班地生成回答、用户也在持续收到响应，这一切看上去运转良好。但有一个问题大多数工程师从来不问：这些回答真的对吗？

Andrej Karpathy在GitHub上发布了一份名为LLM Wiki的文档引起了巨大的关注，一派认为"这不就是多绕了几步的RAG"，另一派已经打开编辑器着手搭建测试。

要理解向量搜索先要弄清楚为什么需要向量数据库，关系型数据库处理结构化数据得心应手。所谓结构化数据就是那些具有固定列的表格数据，比如说：姓名、年龄、薪资、日期。这类数据精确匹配查询很简单："Age > 25"或"Name = Subham"就能拿到想要的结果。

推荐系统不是单一算法而是一条流水线，每个阶段在不同约束下解决不同的问题。多数入门实现把所有事情塞进一步：算相似度。但生产级系统需要做关注点分离，分别管控质量、速度和行为。

2023 年"Prompt Engineering"无处不在；到 2025 年中"Context Engineering"成为了主流；而 2026 年 4月反复提及的词是"Harness Engineering"。这三个术语描述的是同一问题在不同深度上的结构。搞清楚它们各自的边界，是眼下最有实用价值的认知框架。

向量数据库存储 Embedding，也就是文本、图像或音频的数值表示，并在查询时检索语义上最接近的结果。RAG 系统正是基于这一机制运作。本文对比三个主流方案，每个都附有 Python 代码，均来自实际在生产环境中使用三者的经验。三种选择：Pinecone 用于生产级规模，Chroma 用于本地原型开发，Weaviate 用于混合搜索。

Claude Code、Cursor、GitHub Copilot 这类 AI 编码 Agent 在单次会话中表现出色，但每次新会话都从零开始。没有连续性，也没有"上次遇到过类似情况"的判断力。

常用的三种缩放器各有适用场景：StandardScaler适合近似正态分布的数据，也是最常见的选择；MinMaxScaler将值压缩到0和1之间，适合神经网络；RobustScaler基于中位数和四分位距（IQR）而非均值，在数据中存在明显异常值时更为稳健。

单个智能体的专业化程度有上限，真正的工作需要团队：一个角色接收订单，一个检查库存，一个安排生产，一个验证质量。ADK 的编排模式：SequentialAgent、ParallelAgent、LoopAgent可以将多个智能体组合成工作流，流程只定义一次，状态在智能体之间自动传递，故障由系统托管。本文讲介绍每种模式的适用场景、状态的流转机...

是个黑盒，而且这个黑盒藏了一个代价很高的问题，每一个解码步骤它都从头开始对整个 prompt 做一次完整的注意力计算。每一个 token 都是如此。注意力的开销以 O(N²) 的速度随序列长度增长，在小规模下完全察觉不到，一旦上了真实负载就会出现问题。

向量数据库的核心任务是对文本或其他非结构化数据生成的 Embedding 做相似性搜索。时间戳、文档类型、所有权一类的上下文约束，一般以外部过滤器的形式在向量搜索前后进行。多数场景下这一架构运作正常，但当上下文信号需要参与排序就会有问题。本文分析传统向量数据库架构的过滤与检索机制，并介绍 Aspected 的 Aspect ...

生产环境中真正烧钱、拖慢体验的环节不是训练、是推理。自回归的方式一次只产出一个 token，每个 token 都要完整走一遍模型所有层的前向传播。70B 参数的模型在 H100 上运行，每个 token 对应 700 亿次乘累加运算，而 GPU 大部分时间都在等内存搬运数据，真正用于计算的比例很低。

Pandas 代码写得越多，越容易陷入一种惯性：用 apply() 逐行处理，用循环拼接结果，用 groupby 加 merge 绕一大圈完成本可以一行解决的操作。代码能跑结果正确，但行数膨胀、性能也大打折扣，审查时也让人读得费力。

检测 Prompt 注入和越狱攻击的方法，大多建立在系统可以访问对话日志这个前提上。但是如果设计一个系统，每段对话只处理一次以提取特征，不保留原始文本可以吗？：

多 Agent 流水线在每一次演示中都表现正常。但是到了生产环境，它可能在第四步之前就悄悄积累了三个错误决策，最终输出自信、流畅但是完全错误。并且最后没有人发现问题，因为根本没有信号可以捕捉链条末端只剩下一个看起来干干净净的结果。

它不依赖固定的手工检索流水线或静态指令，而是学到一套策略：推理过程中的特殊 Token 可以触发检索动作。每一步，模型生成一个动作 Token——继续内部推理、经

Agentic 工作流普及以后，LLM 开始被频繁用于迭代优化机器学习模型：提出配置方案、观察实验结果、逐步改进决策。表面上看这像是推理，但一个根本问题悬而未决：系统性能的提升，究竟源于推理能力，还是源于输入端信息的改善？