ZhangJiqun&191cm&85kg

直接消除单次 LLM 抖动的疑虑，用户看到"3 位评委独立给出 4.2 / 4.3 / 4.1"，比"1 次给出 4.2"可信得多。成本：judge 阶段 token 3 倍（但相比 forward 阶段几乎可忽略）。

介绍了SkillGrad技术针对VOC报告场景的优化方案。主要内容包括： 自研了5个中文提示词，针对VOC报告场景做了深度定制，包含业务约束和输出格式硬约束，防止LLM过拟合。 提供两种优化模式： 仅MD模式：通过backward和step两步显式生成文本梯度，只修改SKILL.md文件 全技能模式：通过edit_files一步直接修改多个文件，适合需要修改代码的场景 展示了两种模式的核心代码实现，对比了它们的关键差异。 通过一个真实案例展示了两种路径的具体优化过程。 该方案实现了对VOC报告质量的有效

SkillGrad评分机制采用1.0-5.0分制，通过对比实际产出与理想产出的差异进行打分。评分基于三大要素：用户问题、理想产出和评分标准，由Judge模块生成分数、差距描述和缺陷点列表。系统支持默认评分标准和自定义标准，通过算术平均聚合多用例分数，并建立学习率护栏确保优化过程分数单调不降。评分结果直接驱动优化决策，帮助开发者定位改进方向，最终目标是使技能产出达到4.5分以上的可用标准。

本文提出一个4步实现Agent优化闭环的方案，核心是利用Langfuse工具链与现有组件快速搭建测试-优化迭代系统。方案将Skill工具集成到Agent Builder，通过Langfuse自动记录对话轨迹(Trace)并存储为测试用例，包含用户输入、实际输出和人工修正后的理想结果。优化阶段通过Python脚本自动执行：用当前Skill跑测试集→调用Judge模型评分→由Optimizer模型生成Skill改进补丁。整个流程可利用现有火山方舟LLM和前端界面快速对接，预计3-4天可完成最小闭环。该方案的优势

介绍了如何将国内大模型豆包接入Langfuse可观测性平台的实践过程，重点拆解了三个关键环节的配置要点和常见陷阱： 凭据配置：需正确设置LANGFUSE_PUBLIC_KEY(项目标识)、LANGFUSE_SECRET_KEY(权限验证)和LANGFUSE_BASE_URL(目标地址)三个环境变量，且必须在导入Langfuse前通过load_dotenv加载。 SDK替换技巧：使用langfuse.openai.OpenAI替代官方OpenAI客户端，保持API兼容性的同时自动上报调用数据，无需修改业务

分布式追踪中的核心概念Span及其应用。Span定义为一次可观测的操作单元，包含名称、时间戳、属性等信息。多个Span通过父子关系组成Trace，形成树形结构。文章以Python代码示例展示了如何通过装饰器创建Span、设置属性，并详细解析了Span的数据结构（名称、时间、状态、属性等）。同时介绍了Langfuse工具中Span的5种子类型及其适用场景，以及Span在性能分析、错误排查和成本计算中的关键作用。最后强调Span是构建完整调用链路（Trace）的基础单元，对复杂系统监控至关重要。

Langfuse是一款开源的LLM工程平台，专门用于追踪、评估和优化大模型应用，已成为LLM开发领域的"标配仪表盘"。它解决了LLM应用从开发到生产中的四大核心痛点：提供全链路可观测性，告别黑盒调试；实现Prompt的版本管理和灰度发布；建立自动化评估体系量化回答质量；支持基于数据集的科学实验对比。该工具特别适合面临成本失控、排障困难、迭代低效等问题的生产级LLM应用团队，支持Python/JS等多语言SDK，可快速集成到现有项目中。作为开源的一体化LLMOps平台，Langfuse在数据安全、功能完整性和

Nginx是高性能HTTP服务器/反向代理工具，用于负载均衡、HTTPS加密等。没有它时需直接暴露后端服务，存在性能弱、端口冲突等缺点。Kubernetes是容器编排平台，管理多机Docker集群，实现故障自愈、弹性扩缩。单机环境无需K8s，徒增复杂度。建议：1）个人内网使用直接用Python原生服务；2）对外开放时加Nginx提升安全性和性能；3）多GPU服务器集群场景再考虑K8s。单服务器部署优先保持简单。

介绍了HTTP端口80与8080的区别，以及常见的代码部署方案。 端口区别部分： 80端口是HTTP协议默认端口，浏览器访问不带端口的网址时会自动连接80端口 8080是常用的替代端口，普通用户可直接使用 端口使用规则包括数值范围、不可重复占用、防火墙配置等 代码部署方案部分： 轻量同步方案（rsync/SCP/SSH可视化工具） Git驱动部署（WebHook自动部署/GitHub Actions） 容器化部署（Docker/Docker Compose） 生产级工具（Ansible/Jenkin

文章详细介绍了如何从空白服务器部署并运行一个基于沙箱隔离的Agent技能（skill）。首先澄清了沙箱的三个层次概念：OS级沙箱（如Docker）、Agent平台沙箱（工作目录隔离）和Python环境沙箱（venv）。然后分五个步骤指导部署：1）安装系统依赖和Python环境；2）创建Python虚拟环境；3）配置环境变量；4）通过三步流水线（下载数据→生成报告→写入清单）进行冒烟测试；5）最终将技能集成到Agent系统中。文章特别强调了沙箱的路径约束和文件隔离要求，并提供了具体的命令行操作示例和

Python CLI运行环境由4层构成：Python解释器、第三方库、环境变量和CLI参数。本项目通过以下方式实现环境配置： 依赖管理：使用requirements.txt集中声明依赖项，通过venv虚拟环境和pip安装 环境变量：采用自定义.env文件加载器，优先使用系统环境变量，支持临时切换 模块导入：动态修改sys.path使同级模块可直接import CLI参数：使用标准argparse处理命令行参数 在Cursor/VSCode中的具体操作步骤： 选择Python解释器（推荐虚拟环境）

Agent 技能体系中「执行 Python 代码/CLI 命令」的实现原理，将其分为三个层次：声明层、管控层和执行层。通过两个示例详细展示了具体实现： 本地 Python 执行技能：基于 LangChain 工具规范实现，使用临时文件和子进程执行代码，包含参数校验、超时控制和结果结构化处理。 生产级 Docker 沙箱 CLI 执行技能：采用 Docker 容器实现安全隔离，包含危险命令拦截、资源限制和自动清理机制。每次执行创建临时容器并配置严格的隔离规则（禁用网络、限制内存/CPU、只读文件系

一套提升工单分析系统能力的14项技术方案，重点解决当前存在的分析深度不足、数据样本小、根因推测为主等问题。方案分为A、B两类：A类直接提升分析深度，包括RAG/GraphRAG知识检索、统计显著性分析、LLM评估闭环等；B类优化系统能力，如结构化输出保障、多模态处理、Agent工作流等。作者推荐优先实施"千台故障率统计+RAG检索+成本排序"三项最具性价比的改进，其中前两项无需额外模型即可快速见效，能显著提升分析质量和决策价值。整体方案注重证据支撑、统计验证和闭环反馈，旨在将当前推测型分析升级为数

介绍了LLM中RAG技术的完整流程案例，主要分为知识组装和Prompt指令两个部分。在知识组装阶段，通过domain_knowledge.py按业务域分类合并知识条目，并优先采用profile自定义条目。在Prompt指令阶段，通过llm_sections.py将知识列表转换为带标题的Prompt文本，并明确使用规则。最关键的是在Prompt中提供详细的推理链指令，指导LLM结合工单事实和知识库进行四步分析：提取事实、反推机理、定位根因、给出整改方案。完整调用链展示了从知识存储、组装、合并、下发给LLM

介绍了在Cursor中通过Markdown文档（SKILL.md）指导任务执行的机制。文档作为"计划书"而非脚本，其执行流程分为三部分：1)由AI解析依赖关系确定执行顺序并替换占位符；2)通过Cursor终端工具执行具体命令，保持会话状态；3)通过退出码、输出标志和产物文件三重验证确认完成。与cron自动触发相比，手动模式需要AI实时推理顺序且可能需人工审批命令，但核心判断逻辑相同。整个过程结合了AI的概率性推理与工具的确定性执行，强调文档清晰度对降低错误率的重要性。

本文分析了LLM（大型语言模型）应用中三种不同的命令执行方式：生成命令（A）、结构化工具调用（B）和返回自由JSON/文本（C）。A方式灵活但安全性低，直接输出shell命令；C方式结构化但灵活性差，需自行解析JSON；B方式结合两者优点，通过结构化工具调用实现安全高效的操作。文章还介绍了其他技术如JSON模式、受限DSL等，并根据不同场景推荐适用方案。最后指出当前仓库中存在两种执行路径：shell命令依赖外部环境执行，而结构化工具调用通过LangChain框架实现，后者更规范安全。

本文通过写字楼模型形象类比Web部署概念：服务器相当于写字楼，IP是门牌号，域名是招牌名，端口是房间号，进程是办公团队，Nginx是前台，HTTPS证书是加密通道。文章强调区分服务器的硬件和软件含义，解释端口的作用及常见用途，并分析开发环境中的端口配置。 在开发流程方面，提出使用Cursor分六个阶段推进项目：需求分析、搭建骨架、小步迭代、调试、提交协作和部署。重点强调一次只做一个功能并即时验证的纪律性，以及利用现有代码作为参照物提高开发效率。 部署部分详细说明前端从开发服务器转为静态文件的过程，后端生产环

什么是代理代理就是**中间人**：请求不直接从 A 到 B，而是 A → 代理 → B。对方看到的是代理，不一定直接看到真正的发起方或真正的服务方。

技能（Skill）本质上是提示词工程的延伸，但又超越了单纯的提示词。虽然技能的底层实现仍是条件触发的提示词注入，但其核心价值在于工程化能力：渐进式上下文加载、代码兜底确保准确性、参数化复用、组织经验沉淀、可验收测试等。技能将提示词与软件工程结合，通过模块化、版本控制、自动化校验等手段，解决了纯提示词难以维护、易出错、难复用的问题。当技能足够成熟时，用户甚至无需再编写复杂提示词，只需简单指令即可触发完整的处理流程。提示词工程的终极目标，正是通过技能实现"无需重复编写提示词"的自动化解决方案。

本文从工程实践角度对比了Skill与多Agent两种AI应用范式的本质区别与适用场景。Skill范式通过硬编码DAG流程将决策固化在代码中，LLM仅在被点名的环节参与，具有高确定性、低成本、易调试等特点；多Agent范式则将决策分散于多个LLM的运行时交互，灵活性高但代价是token成本激增、结果不可预测。作者提出"Agent-of-Skills"的混合架构建议：用薄层Agent做接口决策，厚Skill工具处理核心逻辑，既保持流程稳定性又获得参数调优的灵活性。文章强调在报告生成等SLA敏感场景中，应优先采用

TextGrad框架如何借鉴深度学习思想，通过自然语言处理优化系统提示词。该框架将提示词设为可优化变量，让大语言模型(LLM)扮演三个角色：预测模型生成结果、裁判模型评估错误并给出改进建议、优化器根据建议重写提示词。实现过程包括：1)定义提示词变量；2)模型预测并比较正确答案；3)生成文本形式损失反馈；4)反向传播改进建议；5)优化器在约束条件下更新提示词；6)测试新提示词并择优保留。实验显示，仅1轮迭代就使分流准确率从83%提升至94.87%，验证了该方法的有效性。

控制平面（大脑，管控整个集群）1. **etcd**：集群唯一数据库，存所有集群状态、配置数据2. **kube-apiserver**：唯一入口，所有操作（创建服务、删Pod）都走它，权限校验3. **kube-controller-manager**：各类控制器，负责保证实际状态=你定义的期望状态（容器挂了就重建）4. **kube-scheduler**：调度器，决定把容器调度到哪一台服务器节点

**为什么是里程碑**：这是 Nature 主刊上首篇专门做"LLM 幻觉检测"的方法学论文，也是牛津 OATML（Yarin Gal 是贝叶斯深度学习和不确定性估计的领军人物）把**经典贝叶斯不确定性**理论**成功迁移**到 LLM 自由生成场景的代表作。

表征工程（RepE）通过直接读写大模型中间层的残差流实现"脑机接口"式干预，其科学性基于线性表征、叠加性和因果控制三大假设。该领域经历了从探针观察到向量编辑的发展，SAE技术成为特征解耦的关键工具。当前面临非线性表征干预、控制可信度和因果验证等挑战，但RepE为大模型安全性和可解释性提供了新路径，结合提示词压缩技术有望重塑大模型推理架构。SAE作为核心工具，能解析叠加特征，实现模型思维的透明化控制。

**大模型的安全机制只认识“人类语言”对应的正常向量。软压缩为了省空间，造出了一种模型没见过的“外星向量”。这种外星向量虽然能传递信息，但完美绕过了模型的安全检查，导致模型变笨（对齐失效）或者变坏（被越狱攻击）。**

文章摘要： 提示词压缩（Prompt Compression） 旨在解决大模型长上下文处理中的算力与成本问题，通过信息冗余削减提升效率。其演进经历了软提示、硬压缩、学习式压缩和任务感知蒸馏四个阶段，核心挑战包括位置编码敏感性、分布外灾难和KV语义不透明。未来方向为可解释的软压缩与表征工程结合。 表征工程（Representation Engineering, RepE） 通过直接干预模型中间层的残差流向量，实现对大模型行为的精准控制。其基础为线性表征假设、叠加性和因果控制三大支柱，发展脉络从探针观察到向量编

全局工作空间理论 (Global Workspace Theory, GWT) 最早由认知科学家 Bernard Baars 在 1980 年代提出，是目前主流的意识理论之一。它用一个"剧场"比喻大脑：后台有大量并行、无意识的专用模块（视觉、听觉、记忆、语言等），各自默默运转，彼此隔离；舞台中央有一束狭窄的聚光灯——这就是"全局工作空间"；只有被聚光灯照亮的信息才会被广播给所有其他模块，被"意识"到、被口头报告、被灵活组合用于推理。

探讨了语言模型激活向量干预范式的演进。传统方法（如ITI、CAA等）采用固定方向向量进行干预（h' = h + α·v），但研究发现这种单一方向仅能解释15%的位移方差。通过实例分析（如真实性引导、情感调节等场景），作者揭示了固定方向会导致数学能力下降、过度拒绝等问题。 新范式提出上下文自适应变换，包括三种实现方案： 查询路由动态组合多个子空间向量（CD-MSRE采用） 输入依赖的线性变换矩阵 多头门控机制（类似MoE） 核心突破在于认识到语义变换本质是高维分散的，需要根据输入内容动态调整干预方向和强度

**2026年大模型技术全景速览：闭源与开源阵营集体升级，形成明显代差。OpenAI GPT-5.5、Anthropic Claude 4.8和Google Gemini 3.5等闭源旗舰在基座重训、多智能体架构和原生多模态等方面取得突破；开源阵营中DeepSeek V4、Qwen 3.5等首次接近闭源天花板，提供高性价比选择。文章重点推荐了7类可本地部署的开源模型（如DeepSeek-R1、Qwen 3.5系列），并给出Ollama和llama.cpp两种部署工具的硬件适配方案，最后通过四个典型场景展示了

Anthropic团队提出了一种名为Jacobian Lens（J-lens）的新工具，用于探测语言模型内部的"可被言说却未说出口"的表征子空间（J-space）。研究发现，J-space的行为与神经科学中的"全局工作空间理论"惊人地相似，具备可言说性、灵活可用性、广播性和容量有限等特征。通过实验验证，J-space确实承担着模型内部的"工作记忆"功能，能够影响后续推理却不一定会体现在输出中。这一发现对AI可解释性、安全性和意识研究具有重要意义，为理解模型"内心活动"提供了新视角，同时也为未来Agent设计

通过一个简化示例（3维隐藏层和4组对比提示）详细解释了如何在大语言模型中实现「事实性表征增强」。核心流程包括：构造事实/非事实提示对，计算隐藏向量差值，通过PCA提取主方向（如(0.33,0.67,-0.67)），并将其以可调强度α叠加到初始隐藏状态（如从(0.5,0.3,0.2)增强到(1.5,2.3,-1.8)）。该方法通过向事实方向偏移隐藏表示，显著提升模型输出的真实性。文中还阐明了协方差矩阵的特征分解与PCA降维的关系，指出主成分分析本质是提取数据变化最大的方向。整个过程将高维隐藏空间（实际数千

这篇文章通过一个学生成绩的简化案例，直观解释了PCA（主成分分析）的核心思想与应用方式。作者用5名学生的数学、物理和体育成绩构建3维数据矩阵，经过中心化处理后计算协方差矩阵，提取出最大特征值对应的主方向向量(0.55,0.60,-0.58)，将其解释为"理科综合能力↔体育偏向"轴。这个例子生动展示了PCA如何从多个样本中提炼出最主要的共同变化模式，而非简单平均。文章最后将该案例与事实性论文研究进行类比，说明两者都运用PCA从多维数据中提取最具代表性的主方向向量，从而捕捉数据中的关键结构特征。全文通过具体数值

摘要： 本文解析了Gemini API缓存机制的使用细节。脚本未使用原生system_instruction字段，而是将所有内容塞入contents数组的user消息中。"系统提示词"（不变的模板）和"用户提示词"（变化的对话数据）在逻辑上区分，但API层都作为user角色处理。缓存机制通过预存模板文本的KV cache，后续请求只需发送对话数据，显著减少token消耗和延迟。虽然使用system_instruction可能更语义化，但对缓存效果无实质影响。

本文分析了Gemini语言模型在工单处理场景中的两种缓存机制表现。数据对比显示：显式缓存（主动注册模板）可实现84-90%的token级命中率，通过cached_content直接引用预存内容；而隐式缓存（自动前缀匹配）由于并发请求和模板拼接方式导致命中率接近0%。成本分析表明，显式缓存在大规模处理时可节省30%以上费用，但小批量场景因存储费可能更贵。技术实现上，系统通过累加服务端返回的usage_metadata统计缓存token占比，显式缓存需额外计算存储成本。最终结论指出显式缓存通过精准注册可稳定获得

Cursor的全权限模式，本质是把“安全控制权”完全交还给用户。对于熟悉AI行为、能把控代码风险的开发者来说，它能把AI编码的效率提升一个量级——从“一步步指导”变成“全自动交付”；但对于新手、或者处理重要项目时，多一层弹窗确认，就多一层安全垫。

探讨了提升LLM API调用效果的多种技术方案，涵盖工单打标和报告生成两大场景。在工单打标方面，提出批量工单多维度标注、零样本/少样本提示、检索增强分类和半自动化预标注管线等方法，显著降低成本并提升效率。报告生成方面，介绍了多角色智能体、Agentic RAG框架、大小模型协同和多模态图文生成等方案，适用于不同复杂度和准确性需求的场景。这些方法均基于通用LLM API，无需微调，可直接落地，适用于企业级生产环境。

LLM API缓存创建耗时分析及优化策略 摘要 LLM API缓存创建平均耗时3-4秒（5000 token模板），E-COMMERCE类型缓存创建最慢达12秒。主要耗时在Prefill阶段（占95%），即对模板进行KV张量计算。当前实现因全局锁导致12个缓存串行创建耗时42秒，若改为并行创建可缩短至4秒。优化策略包括：1）并行预热所有可能缓存；2）跨批次复用有效缓存；3）仅对高频类型创建缓存。通过优化，可显著降低缓存创建时间，使后续调用节省2-3秒Prefill时间。

Gemini 3 Pro降本实录：利用上下文缓存减少LLM调用成本 本文分享了如何通过Gemini的Context Caching功能，将GD智能标注系统的API成本降低三分之一。系统每天处理数千到上万条客服工单(GD)，使用Gemini-3.1-pro进行两级分类，但90%的提示词内容是重复的。通过将固定不变的前缀模板缓存到服务端，后续调用只需发送变化部分和引用指针，使得输入token成本降至原来的25%。文章详细介绍了上下文缓存的实现原理、计费机制，并提供了Python代码改造方案，包括懒创建缓存、线程

Vertex AI的缓存机制分为显式缓存和隐式缓存两种。显式缓存需要开发者主动创建并管理缓存内容，通过API明确指定要缓存的内容和TTL，保证缓存命中但需支付存储费用。隐式缓存由系统自动识别高频重复内容进行缓存，无需开发者干预且免存储费，但命中率不可控且生命周期短。实际案例显示，显式缓存能稳定节省70%以上的推理成本，而隐式缓存命中率可能低至0.4%。建议对固定内容采用显式缓存，临时性内容则可尝试隐式缓存。

本文测试了LLM API调用中启用提示词缓存（PROMPT_CACHE_ENABLED）的实际效果。通过10条真实数据测试发现：启用缓存后API输入token费用降低86.5%，总费用节省31.9%，但小批量处理时间增加65%主要由于缓存创建阻塞。分析表明，批量越大节省比例越接近38.5%上限，1000条以上数据可稳定节省38%费用。建议优化方向包括：预热创建缓存、调整TTL设置、跨批复用缓存以及设置数据量启用阈值。该方案在大批量数据处理时能显著降低成本，但小批量任务可能因存储费和创建等待反而增加耗时。