微光实验室 · 标签归档
标签: LLM
共 175 篇文章,按主题汇总相关教程、案例、工程实践和阶段性总结。
AGENTS.md 写了以后,怎样判断它真有用?
给 Agent 修一个解析函数的任务,它先安装依赖,再跑全仓构建,构建报错后又花时间修了一个与任务无关的模块。你把“认真验证改动”补进 AGENTS.md,希望下一次更可靠;结果,它只是更认真地重复了这条弯路。
Codex 只读审查的权限边界:任务文件是谁写的?
一次 Codex 审查没有修改仓库代码,却留下了新的任务 JSON。看到这种现象,先别把它判成“只读沙箱失效”。更值得追问的是:文件由哪个进程写入,read-only 又设置在哪一层?
ESP32-S3 Mini 和 C3 Mini 怎么买?从 PSRAM、USB 到一张可核对的采购单
给一台桌面语音终端买开发板:接麦克风和扬声器,用 Wi-Fi 收发音频,再接一块 320×240 彩屏。商品页同时出现“C3 SuperMini”“S3 Mini 8 MB”“S3 N4R2”,都带 USB 接口,似乎只是性能和价格不同。
CLAUDE.md 越写越长,哪些规则该放到子目录?
一个前后端放在同一仓库的团队,最初只在 CLAUDE.md 里写了测试入口和提交要求。几个月后,文件里又出现接口错误码、组件样式、数据库迁移、版本发布、事故恢复。维护者让 Claude Code 改一个按钮的文案...
让 Codex 当反方:把重试风险问到可验证
给一个写入接口补上超时重试,代码可能只多出一个循环。假设单元测试已经覆盖“第一次请求超时,第二次成功”,普通审查也没有留下待处理问题。上线前还有一个值得追问的问题:第一次请求,究竟是没有执行,还是执行成功后响应丢了?
自己做一个 Mini Reviewer:让 AI 审到本次准备提交的代码
你改完代码,执行了一次 AI Review,读完它给出的意见,准备提交。此时有一个比“模型够不够强”更早的问题:它看到的,是你准备提交的那份修改吗? 在复核一个 Mini Reviewer 示例时,我发现正文和附件代码并不一致。
Claude Code + Codex 怎么分工?别把“允许结束”当成“可以提交”
假设你让 Claude Code 修改一个列表接口:不传每页条数时默认取 20 条,显式传入 0 时应返回参数错误。实现完成后,Codex 指出代码把这两种输入混在了一起。Claude 随后回复:“已收到审查意见,接下来处理。
权重装进了 24 GiB,四路 32K 上下文还装得下吗?
模型权重已经加载,短问题也能回答,于是把服务目标改成四路长上下文。接下来遇到的却是缓存不足、请求等待,或者在某个峰值阶段显存不够。第一反应往往是:“权重才占一部分,剩下的显存为什么不够?” 加载成功只验证了当时那笔开销。
Kubernetes、Ray、vLLM 都在调度,它们各自决定了什么?
一台服务器的 GPU 还有空闲,模型服务却在排队。负责容器的人说资源已经给了,负责 Python 运行时的人说任务已经调度,负责推理的人说这一轮还放不进更多请求。三个人可能都没有说错。 问题在于,“已经调度”后面省略了对象。
两台机器跑 vLLM,什么时候才值得引入 Ray?
一套 vLLM 服务从一台机器搬到两台机器,部署方案里往往会顺手加上 Ray。理由也很直接:multiprocessing 管本机,Ray 管多机。 这个判断会让团队过早更换运行时。vLLM v0.28.0 已提供多节点 multiproc...
GPU Pod 已经 Running,为什么扩容还没变成推理容量?
流量升高,模型服务开始排队。扩容已经触发,新建的两个 GPU Worker Pod 也显示 Running,但请求的首 token 等待仍在增长。 这时继续增加副本数,可能只会得到更多正在启动的进程。
Ray 的 remote 调用之后:任务怎样衔接,状态留在哪里
把一批文本的预处理函数加上 @ray.remote,再逐条调用,程序看起来已经“分布式化”。但下面这个循环仍然是一份工作结束,才提交下一份: 即使另一个 Worker 空闲,它也无法提前处理下一条:
CLAUDE.md 引用 AGENTS.md 后,两边真的读到同一套规则吗?
一个团队交替使用 Codex 和 Claude Code。最初,维护者把测试入口、生成目录和提交要求复制到 AGENTS.md 与 CLAUDE.md,各改一次,似乎就完成了兼容。后来测试脚本更名,只更新了前者:
Codex 后台任务结束了,为什么还不能直接接着用?
假设你在 Claude Code 里把一个调查交给 Codex,随后继续修改同一仓库。过了一会儿,你输入 /codex:result,拿到一份输出,准备按里面的建议接着改。 此时最容易漏掉的问题是:拿到的究竟是哪次任务?
TP、PP、DP、EP 如何组合:八张卡,怎样淘汰不合适的配置
八张 GPU 已经到位,模型在四张卡上能启动。接下来,是把八张卡合成一个大副本,还是拆成两组四卡服务? 只看启动日志,两种方案都可能成立。把单请求延迟跑出来,也还不能决定:更快的大副本可能接不住业务高峰;
vLLM 的 token 预算还有余量,为什么请求仍被抢占?
一批语音 Agent 正在持续输出,旁边又来了几个携带长检索材料的请求。服务没有报 OOM,GPU 也还在工作,但用户听到的停顿变长了。此时把 maxnumbatchedtokens 调大,看起来能让长输入更快处理完;
Data Parallel 深入解析:把请求分给真正有余量的副本
两份模型副本都显示“等待请求:4”,轮询路由看起来很公平。可 A 排着四条短问句,B 排着四份长文档。如果按相同 Tokenizer 计数,A 的每条输入是 128 Token,B 是 8192 Token,而且都没有可复用前缀...
Expert Parallel 深入解析:专家分得均匀,负载为什么仍不均
四张 GPU,每张放两个专家,权重占用也接近。配置表看起来很均衡,执行时却可能只有一张卡接下超过一半的专家任务,其他卡先算完,整层仍要等结果回来。 这个落差来自两张不同的表:部署表记录专家放在哪里,Router 的输出记录这批 Token...
Pipeline Parallel 深入解析:模型装下了,为什么 GPU 还在等
模型已经按层分到多张 GPU 上,服务也能启动,监控里却仍有卡长时间空闲。多张 GPU 分摊同一层计算时,要付出归约和同步的代价。如果高频通信跨过了较慢的连接,把整段层放到同一组 GPU,再把中间结果传给下一组,能不能更划算?
小智断网后还能做什么?沿一次唤醒看清设备与服务端的分工
把一台小智放在桌上,说出唤醒词,屏幕发生变化,随后听见回答。对使用者来说,这是一件事;对系统来说,识别唤醒词、接通会话、理解问题、生成语音和驱动扬声器,可能发生在不同位置。 这会带来一个很实际的疑问:如果外网断了,设备还能不能用?
小智首批设备怎样放量?从接入名单到故障后的恢复决定
你已经让一台小智设备完成了语音问答,准备把同一套配置发给办公室里的十个人。最直觉的做法是把十个设备编号填进 allowed_devices,再打开鉴权,觉得这就圈定了首批体验者。
小智服务端怎样组织 ASR、LLM、TTS?先追本次连接实际使用的对象
你给小智服务端改了模型配置,设备仍能连接,日志也有识别文本,但回答不像预期模型,或者文字已经出来,扬声器还没开始说话。此时“ASR→LLM→TTS”只能说明大方向:它没有告诉你,这个设备到底拿到了哪份配置、哪个实例,又在哪个交接点等待。
SGLang 一加并发就出问题,先查显存还是队列
本地问一句、答一句,服务一直正常。接进应用以后,几个人同时提问,有人等很久,有人的请求直接失败。GPU 显存显示已经用了 92%,于是团队准备先把并发调小。 这可能减少失败,也可能把同一批工作推到更长的队列里。
把 SGLang 接进 Agent,查一次订单要走几步
用户问:“我的 ORDER-A 到哪里了?”模型能读懂问题,却不知道此刻的物流状态。它需要先提出查订单请求,让业务程序验证权限、查询订单,再把结果交回模型组织回答。 接入 SGLang 后,这个来回仍然存在。
Tensor Parallel 深入解析:多加 GPU,推理为什么可能更慢
一台机器有 8 张 GPU,模型用 2 张就能装下。接下来把 Tensor Parallel 从 2 调到 8,用户收到回答就会更快吗? 这个问题不能靠显存总量回答。Tensor Parallel(张量并行...
小智的 MCP 工具返回 true,就代表硬件动作完成了吗?
你对小智说“声音调小一点”,服务端调用了音量工具,拿到一段 text: "true"。这时可以回答“音量已经调小了”吗? 先看这个 true 从哪里来。在本文核验的小智固件里,音量工具取出板卡的 AudioCodec...
SGLang 和 vLLM,拿自己的请求测一轮再选
客服模型准备换推理引擎,团队拿来两张跑分图:一边每秒吐出的 token 更多,另一边首字出来更快。负责接入的人仍然回答不了一个问题:同样六位用户进来,到底有几位能及时拿到可用答案? 先看一个贯穿全文的教学例子。
SGLang 回答慢,时间究竟花在了哪里
用户发来一句话,页面过了好一会儿才开始显示;换一个问题,文字马上出现,却一小段一小段地往外挤。这两种“慢”,需要查的地方并不相同。 第一种先看首段内容出现之前发生了什么,第二种要看开始生成之后为什么跟不上。
Agent 的工具没变,SGLang 缓存为什么没命中?
一个客服 Agent 每次调用模型,都带着同一套业务规则和工具说明。你期待第二轮能少算一些,可观察请求时发现,输入依然处理了很久。 先别急着加显存或改调度参数。把发往模型的两份输入并排打开,找最早变化的位置。
让 SGLang 按 JSON 回答,怎样少写一些补救代码
你让模型把客服工单分成“物流、退款、其他”,后端等着读 JSON。它却先回一句“当然可以,分析如下”,再给结果。有时外面包着代码块,有时把约定好的 refund 写成中文“退款”。 于是程序开始去代码块、找左大括号、修字段名。
小智的 MQTT 已连接,为什么还不能说话?从音频通道看协议选择
给小智接服务端时,有一种容易误判的状态:设备已连上 MQTT,控制消息也能往来,扬声器却没有声音。此时如果只盯着“设备在线”,很容易跳到 ASR、TTS 或音频芯片上排查,漏掉尚未建立的音频通道。
从声学信号到工具阻断:实时语音安全决策门的系统设计
摘要:工具调用获得人工批准或签名票据,并不等于它在真正提交时仍然有效。本文把 PROPOSE、AUTHORIZE、COMMIT 拆开,用 SDK Guardrail 覆盖矩阵、结构化确认、权威授权状态、一次性 jti 消费...
9/10 和 900/1000 都是 90%:机器人成功率计算器必须阻止的误判
证据边界:本文是公开统计文献、RoboLab v4 与产品合同的复核,不是已经上线的 AscendLab 工具,也不是机器人生产实验。文中示例由本地公式复算并通过独立内容审核,但不代表工具已经上线或机器人实验已经完成。
第一次用 SGLang:把本地模型接进聊天应用
你已经有一个聊天页面,后端也会调用 /v1/chat/completions。现在想把远程模型换成自己机器上的模型,卡住的地方通常很具体:权重下载完了,谁来把它变成一个能接请求、能连续返回文字的服务?
同一份长文问两次,SGLang 怎样少算一遍
给模型一份长文,先问“付款条件是什么”,再问“违约责任有哪些”。第二次的问题变了,文档没有变。模型还要把整份文档从头处理一遍吗? 如果两次请求在模型输入端共享相同的开头,且对应缓存仍在,SGLang 可以复用已经算过的中间结果。
中文 Prosody-Aware Eval:从四象限样本到可诊断的实时语音评测
摘要:四象限只能说明语料覆盖,不能自动形成单变量实验。本文把同脚本、同说话人的 control/marked delivery 对定为反事实单位,再用四轴 Schema、五层指标、T0—T6 时间线、dry-run 和 160 条 MVP...
一次 generateImage 为什么会变成多次执行:图像 Gateway 的 Job、Attempt、Artifact 账本
开篇:一个 generateImage(),可能不是一次供应商请求 调用方看到一次 generateImage(),供应商侧却未必只收到一次请求。AI SDK 的官方文档明确说明:当 n 超过模型单次生成上限时...
Seedream 5.0 Pro 进入 Vercel AI Gateway:统一入口为什么仍需要能力合同
开篇:值得关注的不是又多了一个模型 2026 年 7 月 11 日,Vercel 宣布 Seedream 5.0 Pro 可通过 AI Gateway 调用,模型 ID 为 bytedance/seedream-5.0-pro...
机器人策略 90% 与 92%:为什么两个百分点通常不足以证明更强
摘要:100 次 rollout 中成功 90 次和 92 次,不能仅凭两个百分点给策略排序。本文从单组区间、差值区间、配对四格、任务层级与功效设计出发,给出一份可在实验前签署、实验后复核的机器人成功率证据合同。
转写完全正确,语音 Agent 为什么还是做错了决定
摘要:同一个实时语音系统可能在诊断题里识别哭腔、恐惧或讽刺,进入多轮业务任务后却继续按文字执行。本文不把情绪标签当真值,而是交付三组配对测试和一条 Voice Evidence Decision Trace...
删掉邮箱后,Agent Trace 仍可能泄露什么:一条可重放脱敏流水线
摘要:生产 Trace 即使删掉邮箱,仍可能通过工具结果、内部文档、secret 和准标识符组合泄密;删得过多又会破坏失败重放。
RoboLab 解读:机器人策略评测为什么不能只看二元成功率
一、同一个 90%,可能隐藏完全不同的机器人 两个机器人策略 A 和 B 在论文或排行榜上都报告 90% 完整成功率。A 在简单抓取上稳定,但无法处理空间关系;B 经常完成大部分步骤,只在最后放置阶段失败。
开放权重之后,为什么 Agent 仍然无法复现:真正缺的是可重放行为证据
一、同样的开放权重,为什么两个 Agent 不像同一个系统 同一个开放模型、同一条用户指令,两支团队做出的 Agent 可能完全不像同一个系统。一支能在工具超时后换路重试、验证外部状态再结束;另一支遇到 403 仍继续编造"操作已完成"。
同一套 Agent Runtime,为什么 Web、Headless 和 Python SDK 仍然不是同一个产品
同一个 Agent Runtime,只要换个 UI、包一层 HTTP 或 SDK,是不是就能变成多个产品? 这句话只对了一半。共享 Agent Loop、Session、Tool Registry 与模型适配器...
h3.c 的 fast 模式到底删了什么:六个计算轴不能混成一个开关
很多推理工具把优化收进一个 fast=true。速度变快后,用户只看到总耗时下降,却不知道程序少算了哪些部分,也不知道画面出错时应该撤回哪个开关。 h3.c 固定版本 8974cc0 把这件事拆得很具体。
把生产 Agent 事故 Trace 变成可重放的回归测试集
封面 01: 退款事故修完又复发, 5 次转化是永久发布门 一、退款事故已修却再次复发 线上 Agent 把退款工具当作查询工具, 重复创建工单, 引用了错误知识库, 团队修完 Prompt 后在工单里写一句"已解决"。
一次 Agent 失败后,到底该改模型、Prompt 还是 Router?
摘要:一条失败 Trace 往往同时暴露模型、Prompt、Router、工具合同和产品逻辑问题。本文给出四步归因顺序,并用 changecandidate 把可推翻的责任面假设、单一主要变化、固定上下文、评测版本和回退门槛绑定在一起。
Claude 已经给文本加水印了吗?真正缺的不是声明,而是逐模型状态
Anthropic 已经公开确认:支持标记的 Claude 模型会把不可见水印嵌入生成文本。这个变化覆盖 Claude API、Claude、Claude Code、Claude Cowork、Claude Tag,以及 AWS...
拆开 Pi Monorepo:改模型、循环、产品和 UI 时,代码应该放在哪一层
团队准备给 Coding Agent 增加一个新 Provider。最省事的做法,是在主应用里直接写认证、请求体转换和流式解析。过两周 Tool Call 格式不兼容,又在同一个目录加一层修补。
看不见的 Reasoning State,为什么不能拥有看得见的工具权限
一次 Agent 工具调用结束后,系统把模型返回的 reasoning、signature 或 encryptedcontent 连同消息一起存进数据库。下一轮换了会话、切了模型,甚至把轨迹发到可观测平台...
262K 跑过,128K 却被脚本拦下:A6000 跑分里的三种失败不能混为一谈
同一个单卡 A6000 服务,较早的超长上下文探针跑到了目标 262K;几个阶段之后,一次目标 128K 的测试却留下了这行日志: 只看数字,很容易得出“连 128K 都失败了,前面的 262K 不可信”或者“KV cache 用满后服务崩...
Pi 为什么故意少做功能:极简 Harness 的收益、代价与复杂度转移
假设团队准备给 Coding Agent 增加规划能力。第一种方案是在核心里加入 Plan Mode:新的状态机、只读阶段、审批按钮、计划存储和执行切换都由产品统一维护。第二种方案只允许模型先写 PLAN.md...
我让 Qwen3.8-27B 真改了一次 Git 仓库:工具调用怎样形成 Agent 闭环
之前测这套 27B 服务时,工具调用已经能返回标准 JSON,工具名和大部分参数也能填对。但那组 Agent 任务运行在内存里的模拟文件系统,没有真正执行 pytest,也没有产生 Git diff。
机器人接入连续语音后,端云架构要改什么
摘要:连续语音进入机器人后,声音停止不等于播放、任务或物理动作同时停止。本文把系统拆成媒体、交互控制、物理动作三个平面,用五类身份、播放进度代理、动作准入和渐进迁移步骤重新建立端云一致性,并明确 IMPLEMENTED...
单卡 A6000 跑 27B FP8:我把“能跑”拆成了五组证据
我在一张 RTX A6000 48GB 上测了一套 27B FP8 的 vLLM 服务。跑分表第一眼很好看:长输出约 23.5 token/s,80 个 JSON Schema 样本全部通过,短时 soak 也是 100/100。
DeepSeek Harness 为什么不用 messages 数组保存一切
很多 Agent 最初只有一个 messages[]:用户消息追加进去,模型回答追加进去,工具结果也追加进去。上下文太长时,删掉前几条或塞入一段摘要。 这个方案很快会遇到一个无法回避的问题:被删掉的历史还需要审计吗?
Email Thread 不是 Agent Session:生产级异步通信网关的状态、幂等与审批合同
发布边界:事件类型、幂等期限与 WebSocket 能力需发布前复核。平台验签和邮件认证不得改写为语义安全、业务授权或端到端幂等保证。 摘要 Inbox、Thread、Message、Draft 与 Webhook 解决邮件如何存在和通知应...
多 Agent 不是多开几个终端:Pi 的 Sub-agent 取舍
三个 Agent 同时进入一个仓库:一个改认证接口,一个补前端调用,一个修测试。十分钟后,它们都说 任务完成了。合并时才发现,前端基于旧接口生成,测试重写了共享 Fixture,认证 Agent 又在最后一次 格式化中覆盖了另一条分支的改动。
33B 音画模型塞进 Apple Silicon,h3.c 重写了哪些 Runtime 职责
运行 h3.c 的命令看起来很短:给模型目录、提示词、画面尺寸和输出路径,最后得到一段 带声音的视频。 短命令容易掩盖真正的工程量。
登录不是授权:高能力 AI 的连续身份保证链
发布边界:OpenAI 产品名称、访问路径与账户政策需发布前复核。产品规则不外推为行业标准,未完成完整评估时不得宣称消费账户达到 AAL2 或 AAL3。 摘要 Passkey 提供抗钓鱼认证,却不能证明当前组织、工作区、设备...
一次 Prompt 如何变成 Turn、Step 与工具事件
用户输入一句“检查这个项目并修复测试”,系统什么时候算接收,什么时候算开始,什么时候算完成? 如果把一次 Prompt 直接等同于一次模型请求,工具一出现,边界马上崩掉:模型先请求读文件,工具返回以后还要再调用模型;
模型分数涨了,它真的学会了吗?LittleLearner 拆开了三种可能
给模型加几万条 SFT 数据,再跑一轮 GRPO,数学分数从 30 分涨到 50 分。这个结果通常会 被概括成一句话:模型学会了更多数学。 这句话跳过了最难判断的一步。分数上涨至少有三种来源。模型可能获得了预训练中没有的 新能力。
DeepSeek Harness、Codex、Claude Code、LangGraph 应该怎么选
“DeepSeek Harness 和 Codex、Claude Code、LangGraph 谁更强?” 这个问题看似直接,却把三种不同采购对象混在了一起:可直接工作的 Coding Agent 产品、可深度重组的 Agent Runti...
Pi Extension 写完不等于可用:从类型检查到真实 Runtime 的证据阶梯
摘要 本文用一个 Context Audit Extension 展示 Pi Tool、Command、Event 与 UI Status 的职责, 并给出来源契约、官方类型检查、注册与 Mock、真实 Runtime、TUI/模型路径...
Subagent、Job、Goal 都叫任务,为什么不能混成一个对象
“让另一个 Agent 查资料”“把命令放到后台跑”“继续做,直到目标完成”,在人看来都像是在创建任务。 如果系统也用一个通用 Task 对象承载它们,接口起初会很整齐:都有 id、status、result、cancel。
Project Trust 不是 Sandbox:Pi 的安全边界怎样补齐
你克隆了一个陌生仓库,Pi 启动时询问是否信任项目。选择“不信任”,是不是就可以放心让 Agent 读代码、跑测试?选择“信任”以后,是不是意味着项目已经通过安全检查? 都不是。 Project Trust 解决的是项目资源能否参与 Pi...
Cordis 如何让插件可卸载、可依赖、可重组
把一个工具塞进注册表并不难。真正麻烦的是它离开以后发生什么。 假设一个 Workspace 插件注册了文件服务、监听器、Prompt 片段和一个定时任务。用户切换项目时,插件被卸载:监听器有没有解除?
从 Pi 学习设计自己的 Agent Harness:一条可验证的垂直生产线
一个内容团队把研究、写稿、审核、配图和发布串成自动流程。开始几天很顺:模型能写文件,脚本能跑, 图片能上传。后来编辑改了两段正文,旧审核结论仍显示通过;上传图片只改了 Markdown 链接,却又触发 一次全文和逐图复审;
GPT-Live 到底发布了什么:从回合式语音到连续交互循环
一个语音 Agent 可以做到 300 毫秒出声,仍然可能很难用。 用户只是停下来想了半秒,它抢着回答;用户说“等等”,它要到整段 TTS 播完才停;搜索需要十几秒,会话就像断线;后台结果回来时,用户已经换了问题,它却继续念旧答案。
给 Pi 增加能力时,应该写 Prompt、Skill、Tool 还是 Extension?
团队想统一发布流程,于是有人提议“写一个插件”:它要提醒检查清单、读取团队规范、 执行发布命令、拦截危险参数,还要让每个人一键安装。听起来只是一个需求,实际上混合了 五种职责。如果全部塞进一个高权限插件,改一句提示词也要重发代码;
Tool 注册成功,为什么还不等于安全可用
一个工具出现在模型的 Tool 列表里,只能证明一件事:模型可能知道它叫什么、接收什么参数。 它不能证明 Provider 已经装载,不能证明参数经过审批,不能证明 Sandbox 覆盖网络和进程,更不能证明工具执行到一半失败时,外部文件...
Pi 怎样决定模型看见什么:AGENTS.md、SYSTEM.md 与 Skills 的加载边界
你在仓库根目录告诉 Agent:“修改后运行单测。”进入 services/payment/ 后,它又遵循 “禁止运行全量测试”;调用数据库迁移 Skill 时,第三份说明要求先连接生产库做探测。
DeepSeek 把 Agent Core 也插件化了:Harness 的真正赌注
假设同一个团队要做两个 Agent 产品。 一个通过 Web 界面工作,会话存进 SQLite,允许使用 Bash 和文件工具;另一个只跑一次性任务, 会话写入 JSONL,禁止本地 Shell,通过 Python SDK 调用。
回到旧对话为什么没有恢复代码:Pi Session Tree 与上下文投影
你让 Coding Agent 修复登录问题。它先改了 Token 校验,测试失败;你退回到“读取认证模块”那条消息,换成检查数据库时区。对话看起来回到了过去,但工作区里第一次尝试留下的文件改动、已安装依赖,甚至数据库写入,可能仍然存在。
实现 GPT-Live-like:两条路线、一个控制面和六阶段验收
开头:先把“像 GPT-Live”改写成可验收的问题 “我们也做一个 GPT-Live-like 系统”,听起来像一个模型选型任务。团队可能先替换 Realtime 模型,或者把原有 ASR、LLM、TTS 全部推翻...
同一个模型为什么在不同 Agent 里表现不同:模型与 Harness 的责任边界
团队把同一个模型接进两套系统。第一套只把仓库说明和用户问题拼进 Prompt,再提供一个通用 Shell; 第二套会先定位相关文件,按项目规则构造上下文,把读取、修改、执行和验证拆成不同工具,并在测试失败后 把结构化结果送回循环。
GPT-Live 与 GPT-Realtime:产品模型和公开 API 不应混写
开头:把发布页里的名字填进 model,是一次很典型的事故 新模型发布后,团队最容易出现一条看似合理的工作流:产品经理看到了 ChatGPT Voice 的新体验,技术文章写着 GPT-Live-1,开发者便把 model 配置改成同名字符...
Pi 为什么不内置 MCP:工具发现与上下文成本的真实争议
一个 Coding Agent 原来只有 read、write、edit、bash 四个通用工具。团队接入工单、 数据库、监控、云平台和内部知识库后,工具很快增加到几十个。最直接的做法,是把每个 MCP Server 暴露的工具定义都交给模...
前台语音与后台任务为什么要做双循环:从委派到结果新鲜度
一个迟到结果如何变成事故 用户对语音 Agent 说:“帮我找上海周末适合孩子的活动。”系统把搜索交给后台,前台没有卡住,还能自然回应:“好,我查一下,你可以继续补充要求。” 两秒后,用户补充:“不要室外的,最好周日下午。
打断不是听到声音就闭嘴:语音 Agent 的话权状态怎样真正收敛
元信息 文章类型:语音交互状态机与事件协议 目标读者:实时语音 Agent、智能硬件、客服语音和多模态系统的工程师与技术负责人 读者问题:怎样区分打断、附和、旁人语音、环境声和停顿,并让取消、播放与历史最终一致?
让不同大模型共享一个 Agent:Pi 如何统一 Provider 与 Context Handoff
设想一个正在写代码的 Agent:前半段由模型 A 分析日志并发起 Tool Call,中途因为成本或能力切到模型 B。B 不仅要读懂文字,还要知道哪个 Tool Result 对应哪个 Call、此前的 Thinking 能保留到什么程度...
上下文装不下以后:Pi Compaction 怎样压缩历史,又会丢掉什么
一个 Coding Agent 已经连续工作两小时:读过几十个文件,尝试过三条修复路线,跑了多轮测试,还记着用户最早说的“不能改公开 API”。此时上下文接近上限,系统自动生成摘要,然后继续工作。
全双工语音 Agent 如何评测:从首音延迟到事件级验收
元信息 文章类型:Voice Agent 评测方法与验收合同 目标读者:正在开发实时语音、客服、车载、机器人或工具型 Voice Agent 的工程团队 读者问题:除了首音延迟,怎样判断系统真的会倾听、会打断、能恢复并正确完成任务?
一次用户输入到底发生了什么:Pi Agent Loop 源码级解析
从 prompt() 到 Tool Result:Pi Agent Runtime 的完整执行链 Coding Agent 为什么能持续行动:拆解 Pi 的双层 Agent Loop
GPT-Live 可能怎样实现:从公开行为到架构约束的证据梯度
开头:同一种体验,可能来自完全不同的系统 用户在系统说话时插入一句“等等,不是杭州,是青岛”,旧回答迅速停下,新答案沿着纠正后的目标继续。看到这个行为,很容易写出一个看似专业的结论:GPT-Live 一定使用双音频流...
WebRTC 已经双向,语音 Agent 为什么还会抢话?
备用标题 1. 语音 Agent 全双工的三层验收:传输、推理与话权 2. 音频能同时收发之后,真正难的是四份状态保持一致 3. 从 sendrecv 到自然打断:全双工语音系统还缺什么 开头钩子 一个语音 Agent 的 WebRTC 指...
GPT-5.6 Sol 的 ARC-AGI-3 分数为何翻近三倍:Agent 评测必须记录整套运行合同
发布边界:本文依据 2026-07-30 可访问的 OpenAI 与 ARC Prize 第一方资料。
Code Mode 什么时候更省:别只数工具调用,要数模型往返
判断 Code Mode 是否更省,最容易犯的错误,是盯着“工具调用了多少次”。 同样读取 10 个文件,可以是模型发起 10 次串行决策,也可以是模型先写一个有界程序,让程序完成 10 次读取、筛选和聚合,再把一份压缩结果交还模型。
从生成一张图到交付一套资产:怎样验收 AI 图片的连续可编辑性
事实复核截止:2026 年 8 月 1 日;发布前于 2026 年 8 月 8 日重新核对来源可达性与产品状态边界。 生成模型最容易展示的是第一张图,生产团队真正付费的却是第五次修改之后仍然正确。
MCP 无状态核心之后:身份、任务、幂等与审计状态到底放在哪里
发布边界:规范事实按 MCP 2026-07-28 稳定版核验;operationid、operation ledger、outcomeunknown 与审计字段属于作者架构设计,Tasks 是可选扩展,发布前复核勘误和目标 SDK 支持。
OpenAI 重置 GPT-5.6 Sol 使用限额:18% 改善到底意味着什么
2026 年 7 月 28 日 21:09(美国太平洋夏令时间),OpenAI Codex 负责人 Tibo Sottiaux 发布了 GPT-5.6 Sol 使用限额调查更新;换算为中国标准时间是 7 月 29 日 12:09。
SWE-1.7 的提升究竟来自哪里?先把 Agent 能力拆成五个变量
一个团队把 Agent 模型从 A 换成 B,任务成功率明显上升,最容易出现的结论是:新模型的权重更强,所以换到任何系统里都能得到同样提升。 这个结论通常越过了最关键的一步:Agent 的表现不是由模型名单独决定的,而是由模型检查点...
VLA 落地先签动作合同:从视觉语言输入到可执行控制指令
发布边界:合成接口与示意时序不得写成公开模型原生 Schema、作者实测或安全认证;公开频率和动作维度只用于对应论文系统。 摘要 VLA 能输出动作,不代表它已经能接到真实机器人。输入必须带时间和版本,动作必须声明坐标、单位、范围、频率...
MiniMax H3 的多模态参考为什么比 2K 更重要
事实复核截止:2026 年 8 月 4 日。本文依据 MiniMax 官方发布文章、V2 API 文档、官方 Hugging Face 模型卡与价格页展开;没有运行 H3 API 或本地权重,不提供画质、速度、口型和稳定性的实测结论。
开放权重不是唯一控制权:Kimi K3、Hy3 与 Seed 的九项交付比较
企业评估模型时,最容易问错的一个问题是:它到底开放还是闭源? 这个二分法对软件许可证有用,却不足以描述一套 AI 系统真正交给采用团队的东西。拿到权重,意味着可以固定版本、选择部署位置并修改运行时,但不代表已经获得成熟的工作流...
同一画面,两种动作:多模态 Agent 如何验证状态是否足够
先看两个合成工程场景。它们不是公开事故,也不是作者实测。 机械臂在两次测试中看到几乎相同的 RGB 画面:夹爪已经合拢,杯子位于指尖之间。策略都准备“向上抬升”。第一次杯子被稳定拿起;第二次杯子刚离开桌面就滑落。
Prompt 之外,生产级 Agent Harness 到底在控制什么
发布边界:本文的六层控制面是作者工程综合,不是 OpenAI 官方产品架构。预算阈值、权限强度和状态转换必须按具体系统验证。 摘要 “最多搜索五次”“不要浪费 Token”“完成后立刻停止”写在 Prompt 中...
2026 年 7 月 AI 模型发布复盘:真正被比较的是整套工作系统
统计截止:2026 年 7 月 31 日。本文只收录能由官方发布页、模型卡或平台文档确认的模型事件,并区分首次发布、正式 GA、API 开放、权重开放和受限预览。
模型发布可以按天看,生产默认模型不能按天切:一套可回退的 30 天验收流程
证据截止:2026 年 7 月 31 日。本文将厂商直接说明的日期、状态、入口和价格写为事实;厂商公布的性能与客户反馈写为厂商主张;跨厂商解释写为作者推断;30 天验收流程、阈值和回退条件均为工程建议。
GPT-5.6 Luna 降价 80%:Agent 真正该重算的是单次成功成本
事实边界:本文按 2026-07-31 可访问的 OpenAI 公告、Luna 模型卡与 API 价格页核验。降价不代表模型权重改变,也不能推导 OpenAI 的单位推理成本或毛利率。 摘要 Luna Standard 短上下文输入...
GitHub Code Quality GA 后,100 名开发者真的只要每月 1000 美元吗?
事实核验时间:2026 年 7 月 30 日。文中的价格演算均为示例,不是作者账单、客户数据或 GitHub 官方 ROI。 发布边界:公开价、产品支持范围、Runner 单价、AI Credits 与预算行为均为 2026-07-30 快...
不要问模型是 Transformer 还是 Diffusion:一套五层技术栈检查法
发布边界:五层框架是作者工程综合,不是学界统一 taxonomy;速度、质量和能力结论必须绑定模型、配置、硬件与评测条件。 摘要 Transformer、VAE、Diffusion、Flow 和 Solver 经常被放在同一张比较表里...
同样的 Rate Card,为什么更强的 Sol 反而更快耗尽 Codex 限额
发布边界:模型定位、Rate Card、限额和 reasoning effort 行为可能变化;发布前必须复核官方页面。文中场景和决策表用于说明方法,不代表作者完成了对照实测。 摘要 GPT-5.6 Sol 与 GPT-5.5 的公开 To...
从随机动作块到真实闭环:Diffusion 与 Flow 策略的执行账本
发布边界:文中的伪代码、延迟项和门限均为工程示例;不得改写为特定机器人实测、实时保证或安全认证。 摘要 Diffusion 或 Flow 策略输出平滑动作,只完成候选轨迹生成。真实闭环还需要动作数据合同、数值求解时限...
从 Issue 到 Merge:把 Coding Agent 任务写成可执行、可回退、可审计的工程合同
发布边界:本文给出工程合同模型和示例,不冒充 GitHub 的正式 Schema;具体 Agent 能力、权限与自动化边界以产品文档和仓库配置为准。 摘要 Issue 不是更长的 Prompt,而是一次可判定的变更授权。
从视频模型到决策世界模型:进入 Agent 与机器人闭环前的证据门槛
发布边界:L0-L5 是作者提出的工程证据梯子,不是论文统一分级;不得把厂商演示或视觉指标改写成规划、控制或安全有效性。 摘要 视频模型能生成可控画面,只说明它学到部分视觉统计规律。要成为决策世界模型,还需证明动作会改变预测、任务状态可持续...
Video VAE 不是末端编解码器:它如何定义视频模型的系统边界
发布边界:不同模型家族的时间压缩、空间压缩、潜通道和缓存语义必须分别核对;本文不声称已完成作者自有重建或显存实验。 摘要 Video VAE 在主模型之前就决定时空网格、信息损失和 token 数量,在主模型之后又决定解码峰值...
VLA 已经能输出动作,为什么机器人仍需要多时间尺度闭环
发布边界:控制频率、接口字段和云边分工均为工程量级与示例;须按具体机器人、传感器、网络和风险等级实测校准。 摘要 VLA 能共享视觉、语言与动作表示,却不能取消传感器时钟、动力学、关节限位、网络故障和事故责任。
从世界状态到可执行控制:Cosmos 3 Edge 与机器人控制器之间应建立什么合同
发布边界:本文依据公开技术资料提出接口与安全架构;4B、15 Hz 和公开性能数据只在原始测试条件内成立,不推广为任意硬件或机器人上的实测承诺。
Inkling 975B 可部署性阶梯:开放权重之后,真正的门槛才开始
发布边界:运行时版本、托管模态与硬件路径需发布前复核;作者容量计算只作理论估算,不得改写为官方验证配置或部署建议。 摘要 Inkling 的 Apache 2.0 权重可以下载,但可获得并不等于可适配、可装载、可运行、可验证多模态...
1M Context 也会失忆:Coding Agent 为什么需要 Context Ledger
发布边界:价格、会员层级、模型 ID、默认 effort、缓存与 compact 行为需在发布前复核;本文不声称已完成本地吞吐或成本实测。 摘要 1M Context 解决容量上限,却不能自动保证约束没有在 compact 中丢失...
权重已到、Recipe 还在变:Kimi K3 发布后该怎样做工程验收
摘要: Kimi K3 的完整权重已经出现在官方仓库,但“权重可获得”不等于 “生产可运营”。本文把一次开放权重发布拆成七道可审计门,并给出可直接落库的 Release Acceptance Ledger,用来约束 Revision...
高能力模型评估为什么需要一份可验证的 Containment Contract
发布边界:本文讨论公开事件与工程控制框架,不声称掌握未公开事故细节,也不把架构建议冒充已经完成的生产验证。 摘要 “禁公网”不等于“没有公网能力”。代理、DNS、身份服务、缓存、共享文件系统和短期凭证都可能形成传递可达路径。
生产模型路由不是一次难度分类:从硬约束可行域到状态检查点升级
发布边界:产品能力和公开案例绑定来源;通用控制面、检查点与副作用账本属于工程设计,不宣称为供应商内部实现。 生产模型路由不能被简化为一次 Prompt 难度分类。
Ask/Allow 不是安全边界:企业 Coding Agent 必须建立四层治理
发布边界:四层模型是工程控制框架;具体产品的权限、隔离和合规能力必须逐项核验。 交互式 Ask/Allow 只能表达一次人机确认,不能承担企业安全边界。
同一套 ComfyUI 工作流,第二次为什么快一倍?
发布边界:标题中的快一倍是待解释现象,不是作者实测承诺;任何性能结果都必须绑定工作流、硬件、版本和运行条件。 摘要 同一套 ComfyUI 工作流第二次运行明显更快,可能来自模型常驻、编译预热、节点缓存或实际执行子图变化...
低延迟不是更快地猜:EOU、Barge-in 与 Turn Protocol 为什么必须统一
发布边界:协议、状态机和预算属于工程设计;供应商事件名只在对应产品边界内成立,不冒充作者已完成的线上实测。 摘要 语音 Agent 的低延迟不只是缩短静音阈值。EOU 决定何时允许一轮产生后果,Barge-in 决定旧一代工作何时失去提交资...
Token 单价更低,Agent 任务为什么反而更贵
摘要:IBM 的一次 AppWorld 实验中,纸面 Token 单价更低的模型反而产生 更高任务总成本。多步 Agent 的正确计量单位不是一次调用,而是包含缓存、 工具、重试、升级、失败和人工处理的完整任务轨迹。
1.2GB 离线语音 Agent 真正值得复用的,不是 908ms
摘要:一台 Galaxy S23 Ultra 上的离线语音 Agent 曾测得 908ms 首音频和 1,116MB PSS。但真正值得复用的不是这两个数字,而是四阶段职责、状态感知 Tool Schema...
Pi 真的打赢 Claude Code 和 Codex 了吗?Databricks Harness 基准的正确读法
Databricks 在内部真实代码任务上比较了多种模型与 Coding Agent Harness。 最容易传播的说法是“Pi 打赢 Claude Code 和 Codex”,但公开证据支持的是一个 更窄、也更有工程价值的结论
Shippy 的启示:可靠 Agent 不是“更听话”,而是更少犯错空间
摘要:高风险 Agent 的可靠性不能只押注于模型更强。Shippy 的工程价值 在于用版本化行为工件、确定性 CLI、会话隔离和整套 Agent Eval,持续缩小 动作空间、状态空间与错误后果。
Claude Code 权限分析器为什么必须 Fail Closed
推荐标题:Claude Code 权限分析器为什么必须 Fail Closed 备选标题1:别只看表面:Claude Code 权限分析器为什么必须 Fail Closed真正要验收什么 备选标题2:
Kimi K3 2.8T:超稀疏 MoE、百万上下文与真实部署边界
研究快照:2026-07-21。完整权重、许可证、模型配置和技术报告在该日期尚未公开。本文讨论的是已经确认的架构与部署边界,不是完整本地部署实测。 摘要 Kimi K3 最容易被误读的数字是 2.8T。
Search Console 开始追踪社交和视频内容
发布边界:该功能仍在逐步开放,只覆盖 Instagram、TikTok、X、YouTube 在 Google Search/Discover 的表现,不代表平台内部曝光;API 支持未确认。 入库说明:
vLLM 0.25.1:推理引擎升级的正确性门禁
推荐标题:vLLM 0.25.1:推理引擎升级的正确性门禁 备选标题1:别只看表面:vLLM 0.25.1真正要验收什么 备选标题2:一张工程图拆解 vLLM 0.25.1 备选标题3:vLLM 0.25.1为什么经常被理解错
恶意 Dataset 不是文件风险,而是一条执行链
推荐标题:恶意 Dataset 不是文件风险,而是一条执行链 备选标题1:如果 Dataset Loader 能执行代码,隔离该怎么做 备选标题2:只做文件扫描,为什么拦不住 Dataset 攻击 备选标题3:
GitHub Actions 开始拦 Pwn Request,但别把它当沙箱
日期:2026-07-20 状态:完整母稿 事实状态:GitHub 已公告计划于 2026-07-20 将保护回移到除 v1 外的其他受支持 actions/checkout 主版本;本文没有把所有 Tag...
GitHub Models 7 月 30 日关闭:迁移别只换 Base URL
日期:2026-07-20 状态:完整母稿 时间边界:2026-07-23 第二次 Brownout 与 2026-07-30 全面退役均为未来事件。Brownout 的具体 HTTP 状态码和错误 Body 尚未由官方公告明确...
GPT-Red:自动化红队如何形成 Agent 安全数据飞轮
章节角色:旗舰热点研究母稿 优先级:P0 推荐长度:8,000—12,000 字 验证状态:官方事实已核验;核心指标为厂商内部评测 一句话核心论点:GPT-Red 的意义不在于“AI 会攻击 AI”,而在于把威胁模型、攻击搜索、真实工具后果...
FDE 到底是什么:为什么 AI 时代重新需要前线部署工程师
阅读说明:公司岗位和公开计划按 2026-07-18 的一手页面核对;招聘状态可能变化。本文讨论工程责任边界,不虚构客户采用、ROI 或业务收益。 编辑复核(2026-07-18):一手来源支持核心事实;岗位状态为时间快照;
从 Java 后端到实时语音 AI:我的工作为什么越来越像 FDE
阅读说明:本文只使用已披露的 Java、Go、Python、实时语音、端云链路和机器人端经历,不虚构客户交付、采用率或 ROI;重点是复盘工程所有权如何变化。 编辑复核(2026-07-18):一手来源支持核心事实;岗位状态为时间快照;
Hugging Face 入侵后,先检查这 7 个 Dataset Processing 边界
编辑审核(2026-07-18):官方披露能证明攻击链和影响面;攻击者身份、完整入侵细节与所有受影响对象仍不能扩写成定论。 核心结论:这次事件最重要的不是“攻击者用了 AI”,而是 AI 平台把可执行 Loader...
OpenAI 为什么需要 FDE:模型公司正在变成交付公司
阅读说明:OpenAI 公司公告、岗位与产品页面按 2026-07-18 的一手来源核对。本文分析部署战略,不把招聘快照或规划扩写成已经实现的业务结果。 编辑复核(2026-07-18):一手来源支持核心事实;岗位状态为时间快照;
GitHub Copilot for JetBrains 正在形成可组合 Agent Runtime
推荐标题:GitHub Copilot… 备选标题1:生产控制面的五道闸 备选标题2:权限审批灰度怎么连 备选标题3:Agent 上线前需要什么 发布边界:Runtime 是作者工程抽象;Claude Provider 与 Local Sa...
OpenAI 的首款硬件不是“音箱”问题:无屏 AI 伴侣成立的十二个条件
发布边界:无屏、可移动、音箱形态仍来自媒体匿名信源;OpenAI 官方只确认团队与设计合作。 核心结论 1. OpenAI 已确认的是团队与设计能力,不是最终产品规格。[S01] 2. Bloomberg 所述“无屏、可移动...
OpenAI 把 Codex 接进 Claude Code:Coding Agent 开始从单兵走向协作
事实核验: 本稿按 openai/codex-plugin-cc v1.0.6(2026-07-08)与官方 README 核对。插件命令、参数和实现细节属于版本敏感信息,发布前仍需重新检查最新 release。
Claude Code 怎么调用 Codex:拆解 codex-plugin-cc 的四层架构
事实核验: 本稿按 openai/codex-plugin-cc v1.0.6(2026-07-08)与官方 README 核对。插件命令、参数和实现细节属于版本敏感信息,发布前仍需重新检查最新 release。
如何给 Coding Agent 写仓库规则:硬约束、软约束与证据门禁
让模型写出一个函数并不难,难的是让它在一个已经运行多年的仓库里改对三行代码。 同样一句“给订单接口增加重试”,可能牵涉公开 API、事务边界、幂等语义、异常映射、调用方假设和监控口径。一个局部看起来正确的补丁,可能通过语法检查...
Fable 5 的 7 月 19 日不是发布延期:模型可用性正在变成动态资源
发布边界:配额与 7 月 19 日窗口是动态状态,发布当天必须再次核验官方公告。 核心结论 Fable 5 是 Anthropic 的正式模型,不是社区代号或拼写错误;模型 ID 为 claude-fable-5。
GPT-5.6 Sol、Terra、Luna 怎么选:内容仓库为什么默认 Sol + Medium
推荐标题:GPT-5.6 Sol、Terra、Luna 怎么选:内容仓库为什么默认 Sol + Medium 备选标题1:Sol + Medium 为什么适合长期内容仓库 备选标题2:内容仓库如何选择 GPT-5.6 模型与推理档位 备选标...
HunyuanVideo 怎么选
“HunyuanVideo”现在不是一个模型,而是一个家族。搜索结果里同时出现原版 13B、HunyuanVideo-I2V、Avatar、Foley、Custom 和 HunyuanVideo-1.5。
LingBot 四条路线
LingBot 最近连续发布了 VLA 2.0、Video、World 2.0 和 VA 2.0。名称相似、发布时间接近,又都涉及视觉、视频、世界模型和机器人动作,最容易出现的误解是把它们看成同一模型的连续版本。
LLM 应用工程化:从 Demo 到生产的关键实践
记录将大模型应用从原型推进到生产环境的核心经验:上下文管理、错误处理、成本控制、可观测性。不讲基础概念,只谈实际踩坑。
实时语音交互链路的延迟优化实践
记录构建 ASR→LLM→TTS 实时语音链路的过程:为什么延迟高、流水线并发如何降低首字节延迟、VAD 端点检测踩坑,以及各组件的实际选型经验。
AI研究-135 Gemini 3 Pro重回榜首:MoE、百万上下文与Deep Think等关键因素
从稀疏MoE架构、百万Token上下文、原生多模态(文本/图片/视频/PDF)到思维深度控制(thinking_level)与Deep Think模式,解释其在高难度推理与长程任务中的稳定优势。
AI研究-127 Qwen2.5-Omni 深解:Thinker-Talker 双核、TMRoPE 与流式语音
Qwen2.5-Omni(2024–2025) 的 Thinker-Talker 双核架构 做工程化拆解:统一 Transformer 解码器融合 文本/图像/视频/音频,通过 TMRoPE 完成时间对齐;
AI-调查研究-75-具身智能 从LLM到LBM:大模型驱动下的机器人分层控制架构
大型语言模型(LLM)与机器人实时控制的融合,正推动机器人智能化升级。LLM在指令理解、任务规划和环境适应性方面展现出巨大潜力,但直接应用也带来安全性、实时性等瓶颈。
AI-调查研究-13-LLM与Agent的研究 2024–2025年LLM Agent兴起发展 LLM趋势更大更强更智能
2024年被称为"Agent元年"。LLM趋势呈现"更大更强"与"小而专精"并行发展。OpenAI o1系列、Claude等多模态模型不断突破。
AI-调查研究-12-LLM与Agent的研究 2024–2025年LLM主要应用方向综述
2024-2025年LLM主要应用方向包括企业级应用(代码辅助、客服、知识管理)和消费者应用(通用对话、内容创作)。企业采用率不断提升。
LangChain-26 Custom Agent 全面教程 从零构建自定义智能体
本文展示了如何在Python中使用Langchain库和GPT-4模型创建一个聊天代理,通过定义工具函数并将其与LLM集成,实现对用户输入中单词长度等信息的查询。
LangChain-24 AgentExecutor 全面详解
本文介绍了如何在Python中使用Langchain库进行文档检索,加载Web内容,配置OpenAIEmbeddings,并集成GPT-3.5-turbo模型进行问答。展示了如何创建代理执行器来处理用户查询并获取相关信息。
LangChain-25 ReAct框架详解 大语言模型推理与行动融合
文章介绍了大模型ReAct,一种利用逻辑推理和行动序列实现目标导向的框架,通过LLM进行决策和操作。核心组成部分包括Thought(思考)、Act(行动)和Obs(观察)。
LangChain-22 Text Embedding与FAISS实战详解
本文介绍了TextEmbedding在NLP中的关键作用,如何将文本转换为实数向量以表达语义关系,以及如何结合OpenAIEmbeddings和FAISS进行高效存储和查询。
LangChain-23 Vector AI语义检索系统 向量数据库+大语言模型
文章介绍了如何使用Chroma向量数据库处理和检索来自文档的高维向量嵌入,通过OpenAI和HuggingFace模型进行向量化,并展示了在实际场景中如何通过大模型进行问答和增强回复的应用实例。
LangChain-20 文档加载器 TextLoader、CSVLoader、PyPDFLoader、JSONLoader
本文介绍了LangChain库提供的多种文档加载器,如TextLoader、CSVLoader、DirectoryLoader等,展示了如何加载和处理各种格式的数据。
LangChain-21 Text Splitter 全面详解
本文介绍了LangChain库中的各种TextSplitters,包括基于字符、单词、HTML标签和编程语言的分割器,以及它们的应用场景。
LangChain-18 缓存机制详解 InMemoryCache与SQLiteCache
LangChain 提供完善的缓存机制,用于显著降低 LLM 调用延迟与成本。其核心包括 InMemoryCache(内存缓存)与 SQLiteCache(持久化缓存)。
LangChain-19 TokenUsage 回调函数详解
介绍了如何在Python中通过LangChain库集成OpenAI GPT-3模型,展示如何使用getopenaicallback函数来获取回调并执行请求。
LangChain-16 Using Tools 掌握 LLM 工具调用
LangChain 是当前最热门的 LLM 应用开发框架之一,专为构建智能助手、自动化流程和AI数据分析而设计。通过其强大的工具集成能力,开发者可轻松调用外部API,实现从搜索、计算到文件处理的多功能自动化。
LangChain-17 Function Calling AI函数调用的工作原理
Function Calling(函数调用)是大语言模型(如GPT-4、Claude、Gemini)与外部系统交互的核心技术。它让AI不仅能理解语言,还能执行任务,实现从文本对话到真实操作的跨越。
LangChain-14 OpenAI 内容审核 Moderation详解
内容审核(Moderation)是现代互联网平台安全与合规的核心环节,用于识别、过滤和管理用户生成内容(UGC),防止违法违规、低质或有害信息的传播。
LangChain-15 智能知识检索:AgentExecutor执行机制
本文介绍了如何通过Wikipedia搜索插件、AgentExecutor执行机制、上下文Token控制来构建智能知识检索系统。
LangChain-12 Routing By Semantic Similarity 语义相似度路由
本文介绍了一种使用大模型(如OpenAI)和Prompt模板的方法,通过计算查询与预设模板的相似度来处理程序设计中非预期输入的问题。
LangChain-13 Memory ConversationBufferMemory 对话记忆与上下文管理
本文介绍了如何利用LangChain库中的工具在Python中管理大模型的会话上下文,通过ConversationBufferMemory和RunnableLambda等组件,实现在连续对话中保存和加载用户信息,使大模型具有记忆功能。
LangChain-11 Code Writing FunctionCalling 自回归语言建模、大数计算局限与代码生成
文章介绍了如何使用GPT-3.5-Turbo模型编写Python代码来解决用户的抽象计算问题,如2+2和复杂的数学表达式,展示了模型在处理非标准问题上的潜力。
LangChain-09 Query SQL DB With RUN GPT 实现自然语言查询数据库
文章介绍了如何使用Python库如langchain和ChatOpenAI(GPT-3.5-turbo)结合SQLite数据库,创建一个程序来执行SQL查询并以自然语言形式返回结果。
LangChain-10 Agents Langchainhub使用指南
文章介绍了如何通过LangChainHub的Hub机制,利用Python代码轻松访问和共享Prompt。尽管该项目已有一年未更新,但作者仍看好其潜力,展示了如何安装依赖并使用一个模拟搜索引擎的工具来获取天气信息。
LangChain-07 Multiple Chains 多链串联
本文展示了如何使用LangChain库中的Runnable和Prompts,配合OpenAI模型,创建一个可以串联的对话链,以实现多阶段问题解答。通过实例演示了如何构建并执行一个包含两个步骤的查询过程。
LangChain-08 Query SQL DB 通过GPT自动查询SQL
本文介绍了如何在LangChain框架下,通过Python脚本导入ChinookSQLite数据库,利用GPT模型执行SQL查询,如计算员工数量。
LangChain-05 RAG 增强检索会话 Conversational
本文介绍了如何使用Langchain库中的工具,如OpenAIEmbeddings和ChatModels,结合文档检索技术,创建一个基于对话历史生成回答的程序。
LangChain-06 RAG With Source Document 检索增强生成
检索增强生成(RAG,Retrieval-Augmented Generation with Source Document)是一种结合检索与大语言模型生成的AI技术框架。其核心流程是先在向量数据库中检索相关文档片段...
LangChain-03 astream_events 流输出 FAISS 实战
本文介绍如何使用DocArrayInMemorySearch对文本数据进行向量化,并结合OpenAIEmbeddings和GPT-3.5模型,实现在给定上下文的情况下检索相关信息并生成回答。
LangChain-04 RAG Retrieval-Augmented Generation 检索增强生成
本文详细讲解了如何在LangChain中利用RAG技术,结合OpenAI的GPT-3.5模型,通过检索和生成提高文本生成质量。给出了安装和使用代码实例。
LangChain-01 入门指南:快手上手 Hello World
本文介绍了如何使用LangChain库,结合OpenAI API和GPT-3.5-turbo模型,创建一个模板来生成关于特定主题(如猫)的笑话。作者展示了如何安装依赖、设置API Key并实际操作来获取幽默输出。
LangChain-02 JsonOutputParser 解析与流式 JSON 数据处理全攻略
文章介绍了如何在Python环境中安装并使用Langchain和OpenAIAPI,通过异步函数获取指定国家及其人口数据,并展示了逐步增加人口值的过程。