微光实验室 · 博客归档
博客
记录技术探索与工程思考，共 731 篇文章。
精选阅读路径
如果你第一次来，可以先从这几条主线进入，而不是在 600 多篇文章里硬翻。
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 指...