- 博客(133)
- 资源 (1)
- 收藏
- 关注
RSS订阅原创 给 Agent 做了四层工具选择后，我们才发现监控全是盲点
多层工具选择流水线的失败常以“沉默”形式存在：流程跑通却选错工具，监控看板因置信度被写死为1.0而失效，错误无法被捕获。观测不仅漏报，更主动塑造有偏训练集——仅采集“可疑”样本，导致数据分布失真。修复关键在于：透传真实打分、回灌执行失败与用户纠正反馈、全量采集并修正拓扑过滤。最终，观测必须延伸至执行与反馈期，才能从“安全感假象”变为可行动的闭环。
2026-10-04 18:16:01
149
原创 确定性测试:用录制回放 + 请求指纹闸,让 Agent 系统的 CI 不依赖真实大模型
本文提出通过在模型调用处部署回放 mock，将大语言模型的不确定性隔离，实现 agent 系统中确定性逻辑的快速、零成本、可重复测试。核心在于：分清“测代码”与“测模型行为”两类任务，使用录制回放替代缓存，结合请求指纹闸确保响应不悄悄失准，断言行为属性而非逐字答案，并通过依赖注入实现零侵入。最终构建“大量 mock 单测 + 少量真实集成”的测试金字塔，保障 CI 高效稳定。
2026-09-22 11:41:24
199
原创 为什么我们的符号索引从 134MB 瘦身到 631KB
索引并非越大越好。通过排除大模型已熟知的第三方库，仅保留项目自身符号，索引体积压缩200倍至631KB，检索命中率显著提升，噪声大幅减少。结合符号索引与RAG系统，实现“精准定位”与“语义理解”协同，使LLM高效获取关键代码，真正实现从“找得到”到“找得准”的质变。
2026-09-11 16:27:45
314
原创 工具选择的第三条路：1MB 线性头为何能正面硬刚 1.7B LLM
核心论点：当候选集被软预过滤压到 M=8 时，工具选择本质上是个「语义匹配」问题，不是「推理」问题。BGE embedding + 64 维隐藏层线性头（~1MB）能达到 97.5% 精度，与 Qwen3-1.7B-unified（99.4%）几乎持平，但延迟从 922ms 降到 10ms，且可纯 CPU 部署。
2026-09-06 17:48:02
236
原创 AI 桌面自动化时代，工程师的不可替代性是什么
大模型未改变“精确任务占80-90%”的比例，只改变了任务入口，将“模糊输入→精确输出”的桥接自动化。桌面Agent虽让非技术用户能用自然语言操作电脑，但定义能力边界、设定安全规则、审核风险及承担最终责任仍是工程师的职责。工程师的价值从编写脚本转向架构Agent边界，做安全守门员与系统集成者。
2026-09-05 16:34:44
203
原创 从理论到 CI：AI 编码质量闭环的五道机器把关
面向AI生成代码缺乏人工审查的失控风险，本文提出将两篇方法论落地为五道机器把关：离线eval、变异测试、改测试放宽检测、生成时安全扫描、提示词版本化，均独立于Agent自述、可在CI中证伪。目前四道已完整生效，离线eval
2026-09-05 16:10:17
153
原创 免审的代价：AI 编码里省掉的每一次人眼审查，都要有东西兑换
契约镜像型——契约人审过，测试只是镜像，所以免审Agent 自由编写的——每个文件顶部写一句规则描述，人只扫这句，不逐行读CI 回路补的——必须带红绿证据，非法改断言消红就转人工分层清晰、各有兜底、人不成为瓶颈。写完我自己挺满意。「第2层只审一句描述，真的够吗？「第1层契约镜像，真的能免审吗？「可有些测试确实该改啊——那怎么区分？三个问题，把我三层设计逐个捅穿。这三层犯的是同一个错，而这个错在 AI 编码自动化的每一处"省事"设计里都会重演。
2026-08-31 17:27:35
215
原创 你的 AI 编码到底到 L 几：自动化水平不是看能跑多远，是看失控挡在哪
AI编码成熟度应以失控风险挡在哪道闸门衡量，而非自动化步数。L4精髓在于人工守住合并与架构审批，不追L5。通过编排器+CI回路，构建三道防线：粒度自检、测试分层防假绿、文档漂移自动校验，确保L4稳固。
2026-08-31 17:24:51
410
原创 成本分析与边界：什么时候该用 MRAG，什么时候不用
记忆系统不是免费的。LLM 提取、向量检索、存储成本，每一项都有开销。这篇讲怎么算清这笔账，MRAG（Memory-augmented RAG）什么时候该用、什么时候不该用。
2026-08-26 11:41:46
164
原创 记忆评估与可观测性：怎么证明记忆系统真的有用
上了记忆系统，回答质量提升了吗？Token 节省了吗？投诉减少了吗？没有可观测性的记忆系统等于黑盒。这篇讲怎么量化记忆系统的价值。
2026-08-26 11:40:49
198
原创 遗忘机制：不是 TTL 到期全删，而是重要性加权
摘要： 记忆系统的核心风险不是存储不足，而是缺乏有效遗忘机制。长期记忆无限积累会导致噪音增加、检索精度下降。解决方案基于三维度决策（时间衰减、重要性阈值、访问频率），通过分级处理（先归档降级再删除）和定时任务批量清理。关键参数需适配业务场景（如电商90天归档，医疗180天），并监控记忆块总数、删除计数及召回命中率以确保平衡。遗忘机制比存储能力更能保障系统长期效能。
2026-08-25 21:44:17
556
原创 MRAG 检索融合：知识库 + 记忆的统一召回
RAG 解决了"知识在哪"，但 Agent 仍不知道"用户是谁、发生过什么"。MRAG（Memory-augmented RAG）：检索阶段同时召回知识 + 记忆，让回答真正个性化。
2026-08-25 11:43:26
271
原创 L3 长期记忆：用户画像与记忆提取
"长对话"指轮次多（来回次数多），不是单句长（单条消息长度由消息长度上限截断管控，与对话是否算长无关）。电商客服多在 5-10 轮内解决，故定义长对话阈值为 10 轮：仅当轮数超过 10 时，L3 才启动"每 5 轮"兜底提取；10 轮以内的普通对话靠对话结束 / 高价值意图即可，无需周期性提取。这避免了把"5 轮常态"误称为"长对话"，也防止 L3 高频高成本运行。
2026-08-25 11:42:16
226
原创 L2 短期记忆：让对话摘要跨会话存活
运行时已能在对话变长时自动生成摘要（历史消息超过单轮上下文阈值，例如 2000 token，就触发一次压缩）。但运行时的摘要是临时态——服务重启、新会话开启就丢失。把摘要持久化到 Milvus（带 7 天 TTL），新会话、重启后都能召回，用户第二天来对昨天的事仍有印象。更准确地说：L1 是会话级上下文，不跨会话保留；第二天开新会话时原生 L1 为空。系统会主动召回 L2（最近 7 天摘要）和 L3（用户画像），格式化成固定区块注入当前会话（L1）的 Prompt 上下文。
2026-08-24 21:53:54
171
原创 记忆架构总览：为什么你的 Agent 每天失忆
当用户第 8 次问"我之前的退货进度怎么样了"，而系统回答"请问您要退货吗"——问题不在模型，在记忆层。
2026-08-24 17:42:34
737
原创 代码理解取舍：为什么我们没上 Code RAG
（影响面参考）、以及结构化的符号数据（可作为后续语义索引与影响面分析工具的共享数据源）。换言之，「撞墙再升级」的第一步已经具备地基：真要上语义索引，复用这份 AST 抽取即可，不必从零搭。
2026-08-23 21:33:37
190
原创 自愈执行安全闭环
之前把 monitoring-agent 的自愈闭环收口在「建议 + 审批」：agent 只产出处置建议，写操作经人工确认后才执行，且默认「只建议不写操作」。但「建议」一旦要落地，就暴露出旧架构没覆盖的缝隙：RCA 跑完，少一次请求就留在内存里；谁来批准、批准了什么、执行结果如何，全无留痕——这与「自愈系统必须可审计、可追溯、可恢复」是冲突的。
2026-08-21 17:43:53
197
原创 从 ReAct 黑盒到可视化编排：多步 Agent 流程怎么管
最朴素的 Agent 是一个 ReAct（推理-行动）循环：模型自己决定调哪些工具、按什么顺序、调几次，最后汇总回复。简单查询没问题，但一旦流程变长、步骤之间有依赖、中间还要等人确认，黑盒循环就开始失守。典型失守有三种。第一，跳步漏步：模型读了操作指南却没严格按序执行，比如没查订单资格就直接发起退款。第二，状态丢失：多轮之间需要记住"上一步的结论"，循环本身不保证持久化，重启或超时后流程断片。第三，人工确认难落地：退款这类高后果动作必须等人审批，但黑盒循环里"等"这件事没有原生位置，只能靠临时打补丁。
2026-08-16 11:41:59
199
原创 参数从哪来、何时来 —— 提取时机与平台化 Slot 管理
摘要： 参数可靠性不仅依赖抽取技术（正则/模型），更需关注时机（前置、运行期触发、查询）与管理机制（Slot+硬强制）。前置规则优先，漏检时由模型触发确定性代码补全，最终值存入带元信息的Slot平台统一治理。Slot确保可信值来源可追溯，而硬强制防止模型篡改输出，二者缺一不可。小团队可先用手写逻辑（闭包覆盖+校验），复杂场景再升级为平台化方案（解析管道+Slot生命周期）。核心逻辑：模型仅参与发现，定稿权始终在代码，通过分层控制实现高后果字段的零风险传递。 （字数：150）
2026-08-15 21:40:28
188
原创 参数抽准了，还得“喂“得稳 —— 工具调用的硬强制注入
摘要： 参数可靠性需过两关——上游抽得准（正则+校验+反问兜底）和下游用得稳（防模型篡改）。硬强制通过工具入参切除、闭包覆盖等技术，使关键字段（如订单号）彻底脱离模型控制，确保100%来自确定性抽取。其代价是上游正确性成为单点风险，需配合来源日志、格式校验等补强措施。适用场景需权衡后果严重性与上游可靠性，仅在高风险且上游稳定的字段（如手机号）使用，避免滥用导致灵活性丧失。核心思路是：对关键参数，剥夺不可信主体的写入权比训练其正确填写更可靠。
2026-08-15 21:39:34
178
原创 AI 生成代码的“可解释性债“——当人看不过来，系统会变成什么
摘要： AI编码将代码生成成本趋近于零，但团队理解代码的成本并未降低，导致系统滑向“集体黑箱”。当生成速度远超理解速度时，故障定位、人员交接和安全盲区等问题集中爆发。递进式后果包括测试失效、实现不可读和依赖失控，最终使系统无人能解释。解法并非减少生成，而是将“可解释性”作为核心约束：通过架构边界、测试闭环、分层审查和生成留痕，确保系统即使无人逐行阅读也能保持可解释性。核心在于用工程手段（如契约驱动和机器生成拓扑）弥补人脑带宽不足，避免技术债恶化成不可维护的“黑箱”。
2026-08-13 17:27:08
417
原创 模型路由与级联策略 —— Flash 不够用怎么办？
先用低成本模型处理大部分请求，遇到难的再交给高成本模型。fill:#333;important;important;fill:none;color:#333;color:#333;important;fill:none;fill:#333;height:1em;置信度 ≥ 阈值置信度 < 阈值用户请求计算置信度返回 Flash 结果返回 Plus 结果。
2026-08-12 18:30:06
286
原创 vLLM 推理优化实践
本地推理编排优化：单卡多实例vLLM调优实践 核心发现 在8GB显存的RTX 4070上运行三个vLLM实例（含4.5GB的Qwen3-1.7B FP8量化模型）时，通过配置调优实现： 关键参数：max_num_batched_tokens=4096显著降低medium/long prompt首token延迟43-72% 取舍验证：KV Cache Offloading提升稳定性但增加延迟；Prefix Caching因动态prompt无效；-O2优化在当前小模型场景无收益 硬件适配：vLLM优化本质是显存
2026-08-11 19:36:54
338
原创 用 Agent 模拟多角色用户：对话式 Agent 系统的测试方法论
本文提出用对话式Agent测试对话式系统的核心方法论。测试方需模拟真实用户的多轮对话行为（如追问、歧义表达、情绪变化），而非固定脚本。角色设计涵盖横向职能维度（5类角色）和纵向用户变体（4类消费者），以"能否测出独特系统行为"为细分标准。实现上强调多轮状态管理、自然歧义生成和并发调度，并通过UX指标（回答质量、流畅度等）进行体验评估。该方法突破了传统脚本测试的局限，使系统在真实对话场景中的表现得到全面验证。
2026-08-06 16:11:42
224
原创 Agent 注入检测
摘要：API网关无法完全防御Agent系统中的LLM注入攻击，因注入向量不仅限于用户输入，还包括工具返回污染、多轮上下文毒化等。有效的防御需在LLM网关设置三道防线：输入侧检测（防恶意指令进入）、输出侧检测（防污染内容传播）、工具参数检测（防危险执行）。这三道防线需与合规护栏按特定顺序编排（先注入检测后脱敏），并采用分层检测机制（本地规则+语义模型）。硬注入直接拦截，模糊判定则触发人工审核，形成纵深防御体系。
2026-08-03 20:25:11
162
原创 LLM 业务级可观测
本文探讨了LLM平台健康监控的关键维度，指出传统组件级监控无法覆盖业务层面的核心指标。文章提出LLM平台需要分层监控：基础组件存活监控（如Redis/PostgreSQL）和业务健康监控（token成本、延迟、回答质量）。三大黄金信号包括token消耗异常、P99延迟和回答质量退化，这些指标需要通过网关埋点聚合，并建立专门的业务看板。质量评估需依赖自动化评分和用户反馈，而非探针检测。最后强调业务指标应驱动告警和自愈系统，并列举了已实现的告警规则和看板设计，实现从监控到行动的闭环管理。 （149字）
2026-08-03 20:24:30
196
原创 语义缓存管理
文章摘要 语义缓存是优化LLM网关性能的关键技术，它通过语义相似度匹配而非精确文本匹配来提升缓存命中率，显著降低模型调用成本和延迟。精确缓存仅适用于完全一致的请求，而语义缓存能归一化表达不同但含义相同的问题。缓存层必须部署在网关统一出口，避免业务方重复建设。策略上需区分业务场景（如支付类收紧阈值、客服类放宽），并通过PII检测、TTL过期、知识版本化等机制保障数据新鲜度。缓存键需包含业务标签实现策略分片，同时与成本治理系统联动，实现"命中不计token"的精准成本核算。该设计在提升性能的同时，兼顾了业务差异
2026-08-03 20:23:40
187
原创 脱敏引擎工程化
本文提出了一套高可用脱敏引擎的设计方案，核心是通过结构性设计避免防护层成为系统单点。关键设计包括：1）采用"规则即数据+薄引擎"架构，确保跨语言一致性；2）通过本地缓存和异步刷新机制，消除热路径的网络依赖；3）建立三级规则来源（本地快照、构建基线、中央源），保证服务启动不阻塞；4）实施双层级降级策略，优先保留低成本的正则/字典检测；5）引入规则版本化和灰度推送机制防范错误变更。这些设计使中央规则源仅作为"新鲜度提供者"，其故障不会影响系统可用性，仅延迟规则更新，从而从根本上消除了防护层成为SPOF的可能性。
2026-08-03 20:20:08
174
原创 合规护栏唯一出口
本文探讨了LLM系统中敏感信息（PII）治理的关键问题。核心观点包括： 必须将LLM网关作为数据面唯一出口，实现100%流量覆盖的PII脱敏和护栏保护。 PII治理是跨平面关注点，除网关外还需覆盖日志、trace、缓存、向量存储等平行落点，各落点应共享同一套脱敏引擎。 采用"前置脱敏+后置兜底"的双重防护机制，既防止请求侧泄露，也防范模型返回敏感信息。 将护栏分为PII脱敏（数据修改）和Guardrails（行为拦截）两类，通过LiteLLM中间件链实现。 人在回路仅处理高风险边界case，普通内容通过置信
2026-08-03 20:19:33
499
原创 自动操作回复与自愈闭环
能否让系统自己把 redis 重启了，而不是凌晨叫醒人？能，但前提是「安全边界」先设计好，否则自动化会放大故障。监控的价值不止于「发现异常」，更在于「安全地自动处置」。但自动化处置的第一原则不是快，而是——一次错误的自动重启可能比半夜叫醒人代价更高。
2026-08-02 23:23:09
213
原创 系统健康监控巡检
摘要 本文探讨了分布式系统监控的核心问题：如何将分散的组件健康状态收敛为可推理的拓扑健康矩阵，以区分系统级巡检（存活探测）与应用级可观测（根因分析）。关键设计包括： 职责分离：巡检（/health探活）与可观测（指标/日志/LLM Trace）互不重叠，避免监控流量污染业务计量。 动态服务发现：通过Prometheus自动发现与静态清单结合，实现服务上下线零配置更新。 事件驱动架构：日志由应用主动推送至Loki，监控代理仅在告警触发时被动唤醒分析，降低资源开销。 多通道聚合：指标（Prometheus）、日
2026-08-02 21:50:07
173
原创 成本治理与限流
月底账单爆了，却说不清是哪个租户、哪个接口烧的——这种事在各服务直连供应商时几乎无法避免：token 消耗散落各处、归因无门、限流各自为战。治理要生效，前提是流量先收敛到一道统一卡口。
2026-08-02 21:48:43
181
原创 路由策略与引擎可替换性
摘要： 通过网关层实现LLM后端零切换，业务代码无需感知底层模型变化。核心方案是：网关按模型名路由请求（如local/*走Ollama，qwen*走百炼），对外统一暴露OpenAI兼容接口。关键设计包括：1）模型名作为路由键天然携带语义；2）兼容层实现引擎可插拔；3）故障转移分三级处理（同模型透明切换、跨模型降级告警、全挂快速失败）。架构价值在于将供应商风险转化为可治理的工程问题，通过LiteLLM Proxy实现声明式路由，确保业务连续性同时维持质量底线。
2026-08-02 21:47:38
229
原创 LLM 流量网关
独立扩缩：网关无状态转发层，可水平扩容；shop-agent 占内存，扩缩节奏不同独立发布：改路由策略 / 加供应商 / 调阈值，不动 shop-agent治理完整性：独立部署才能抓全所有服务的流量但独立部署有代价——网关自身成为关键依赖，需要 HA / 多副本。必须配出口网络策略封死 shop-agent 直连供应商。代码级缺网关地址即抛拒启，不再有公网 fallback网络级。
2026-08-02 21:46:50
523
原创 分布式上下文存储与同步：长对话的跨节点状态管理
本文探讨了LLM在分布式部署下的对话状态管理问题。针对上下文窗口有限性和多节点状态不一致的挑战，提出采用Redis作为共享存储的方案：按会话ID分片存储，每条消息截断至4096字符，设置24小时过期时间。系统通过无状态节点集群和负载均衡实现请求路由，每次处理时从Redis拉取历史并裁剪至最近N轮（单条300字）。该架构避免了节点间状态同步问题，通过存储层解耦实现了分布式环境下的对话连贯性，同时通过多级截断策略有效控制token消耗。未来可扩展事件驱动机制实现上下文压缩等高级功能。
2026-07-31 13:22:22
270
原创 Agent 运行时与 Harness：从教科书循环到生产级运行时
生产级AI Agent框架的核心不是简单的"思考-行动-观察"单循环，而是由路由层、多策略执行器和生产守卫构成的三层结构。路由层负责请求预处理和意图分发，执行器针对不同任务类型（自由循环/固定步骤/直接分发）提供专门处理，守卫则通过前置的安全检查、流量控制和状态监控确保系统可靠性。关键创新点包括：递归上限作为循环断路器、状态存档支持人工干预、多执行器按复杂度分级处理，以及将安全与可观测性直接编织进运行时而非事后补救。这种设计实现了从演示原型到生产系统的跨越，解决了LLM调用成本、工具可靠性、用户输入风险和合
2026-07-31 13:05:49
602
原创 Agent 回合执行模型：单回合内的调度
本文聚焦单回合内的执行模型，探讨其作为分布式协调的原子单元前提。核心围绕reactor循环结构展开，提出四个关键约束：1) 循环内设迭代与递归双上限防止死循环；2) 工具调用通过"意图过滤→语义重排→模型确认"三级精选实现并发隔离；3) 通过输入截断和结果计费建立token硬预算；4) 采用分布式锁机制控制重状态流程的并发上限。特别强调金钱类操作需fail-closed处理，置信度不足时必须人工介入。这些单回合内的执行策略为后续多Agent协调、跨节点治理等分布式话题奠定了原子操作基础。
2026-07-30 15:55:03
222
原创 Function Calling 精度主攻：约束解码与微调，两条路治两种病
在工具选择链路里，先用向量化匹配在全集上做软预过滤、取前若干候选，再用 Function Calling（函数调用能力，即让模型按给定工具清单选出并填好参数）在这小批候选上做最终选择——它能稳解"查订单 ↔ 查物流"这类近义混淆，这正是《软预过滤工具选择方案》篇把 Function Calling 放在链路末端的理由。但实测告诉我们两件事。其一，Function Calling 在候选上做选择是"净正收益、并非稳赚"：它会把一批本已选对的近义样本改错，又把一批本来会选错的捞回来，正负相抵才略有盈余。
2026-07-28 17:52:50
491
原创 Agent 系统的测试策略：从单元到端到端
摘要：Agent测试面临三大难点——非确定性输出、多工具依赖和长链路不稳定。为应对这些挑战，需采用分层测试策略：单元测试通过Mock LLM和工具隔离不确定性，专注逻辑验证；集成测试引入真实工具和Stub模型，分离验证工具连通性与模型逻辑；端到端测试采用全链路回归和语义评估（如RAGAS），确保系统级行为正确。Shop-Agent的纠纷协调器测试示范了这种分层体系，通过逐层隔离不确定性实现稳定测试。核心在于将随机性封装为可重复验证的黑盒，兼顾测试效率与覆盖度。
2026-07-28 17:40:04
478
原创 L 规模分层路由：当工具多到几百个，单层检索开始漏人
摘要 本文探讨大规模工具选择场景下的分层路由方案。当工具数量达数百级时，传统单层向量化预过滤会因语义空间拥挤导致召回率下降且上下文过载。核心解法是引入"软域路由"分层结构：先通过轻量级业务域分类（召回率0.48优于功能聚类的0.41）缩小候选范围，在域内复用原有的软预过滤+Function Calling流程。关键设计原则包括：1）默认采用软路由输出多域候选保证误判可逆（弱域命中率0.68 vs硬路由0.52）；2）在超大规模（500+工具）需权衡软硬路由，因软路由召回可能反降（0.29 vs硬路由0.32
2026-07-28 15:38:02
277
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人