oh-my-pi 的功能与原生调试: 对比 Pi 和 Codex
我对 oh my pi 的“原生调试”挺好奇, 想看看 Agent 怎么读变量、验证 review 里的猜测. 0x00 它在 Pi 上加了什么 如果已经在终端里读 diff, 下一步想直接查引用、看诊断、打断点验证一个越界假设, oh my pi 把这些入口接在同一个 coding agent 里. 模型调用 lsp
TAG / A
aiagent·18 篇笔记·Agent 系统的设计、架构与工程实践, 不含模型原理本身
我对 oh my pi 的“原生调试”挺好奇, 想看看 Agent 怎么读变量、验证 review 里的猜测. 0x00 它在 Pi 上加了什么 如果已经在终端里读 diff, 下一步想直接查引用、看诊断、打断点验证一个越界假设, oh my pi 把这些入口接在同一个 coding agent 里. 模型调用 lsp
我想写个只接收 PR 的审查 Agent, 但还没弄清 Pi 能替我做多少, 尤其是多个工具同时调用的时候. 0x00 从能做的东西选入口 拿 Pi 做一个 PR reviewer, 宿主程序先获取 PR, 再给模型几个取证工具. 模型决定读哪个文件, Pi 负责执行工具、把结果放回对话、继续请求模型. 你负责定义“审
NOTE AI 做完视觉任务后说"渲染成功了", 这句话里有多少是它真看见的? 我调试一个字幕预览时连续误判六次: 其中四次用了一个在正负样本上区分不开的指标, 一次是参数用错, 一次是从有效判据推出了越界结论. 这篇写那个指标的失效机制, 在它失效时该怎么办, 以及阈值具体取多少. 0x00 方框的像素比真字还少 我
NOTE 同一个记忆框架, 在自家 benchmark 上可以报到 94.4 分 而这个数字来自厂商托管平台的自测. 更麻烦的是: 同一类系统换一套测试脚手架, 分数能相差几十个百分点, 变量既不是模型也不是产品, 而是 谁写的评测代码 . 那么问题就不是"该买哪个", 而是: 在一个连分数都不可比的领域里, 选型到底
NOTE 你的笔记库在半年后会比今天更聪明吗? 大多数"第二大脑"的答案是不会 它们只是一个更整齐的文件柜: 放进去的东西原样躺着, 三个月前的决策和昨天的决策互相矛盾, 而没有任何人知道. obsidian second brain 想换掉这个前提: 知识库不是往里面加东西, 而是围绕新信息重写自己 . 那么, 一个
NOTE 为什么一个精心写好的 skill 会从来不被触发, 而一个写得普通的 skill 却总被误触发? 决定这件事的, 甚至不是它的正文. 更反直觉的是: 命名不合法、描述缺失、正文超预算 这些失败 没有一个会报错 . skill 只是安静地从目录里消失, 而模型既看不到错误, 也分不清"不存在"与"写错了". 那
NOTE 如果一份 skill 文档写得不好, 为什么不能像调参一样把它"训"好? SKILL.md 是纯文本, 模型权重可以冻结, 任务分数就是现成的损失函数 这条路听起来几乎无懈可击. 但真正的问题在另一头: 一个只会看任务分数的优化器, 知不知道 skill 该长成什么形状? 它怎么判断"变得更长"是进步还是灾难
NOTE 给 Agent 接检索, 最省事的做法永远是"买一个搜索 API 然后填 key". 可一旦把约束换成"尽量完全本地自建"和"凭证配置必须体面", 整个方案的形态就变了 而且变的不只是选型. 更反直觉的是: 决定这套栈能不能长期活下来的, 往往不是检索算法, 而是 token 过期那一刻用户要面对多少摩擦.
NOTE 同一句"你好", 为什么在标准模式和极简模式里会被送出完全不同的请求头? 提示词在那台运行时里不是一段文字, 而是一组按 order 拼装、按预设挂载、按步骤重建的资产. 更反常识的是: 压缩指令不是另写的摘要 system prompt, 而是 追加在回放会话最后的一条 user 消息 只为让这次旁路调用命
NOTE 一个 AI 在 A 项目里踩过的坑, 为什么到了 B 项目还要再踩一遍? 多数"记忆"系统只做到了同一工作区内的召回 出了这个会话, 经验就归零. 真正想要的是另一件事: 让一次具体事故自动上升成一条对 所有 项目都成立的规则. 那么, 一个既能被任何 harness 读写、又能自己把经验拔高的记忆层, 该由
NOTE 一个 agent 最贵的时刻, 不是模型答错, 而是它在崩溃重启后 把已经改过的文件又改了一遍 . 要避免这件事, 光有"聊天记录"远远不够: 系统必须能回答三个问题 这个能力是谁给的、这次副作用到底发生了没有、模型究竟看见过什么. DeepSeek Harness 把这些归属全部收进两根支柱: 插件树 与
NOTE 用户说一句"用 echo 回显 ping", 会话里到底发生了什么? 没有聊天记录, 只有一条 turn/start step/start tool/call tool/result step/end 的事件串, 模型每次看到的历史都是现场推导出来的. 更反常识的是: 一次 step/start 到 step
NOTE 你的 Agent 记住的应该是什么? 是一堆日志, 还是一条 能从过去通向当下决策的链子 ? 如果一个用户今天改了偏好、明天打断纠正了你, 你的系统是"秒更新又能回答昨天", 还是两者顾此失彼? 日志该追加、知识该分视图、现状该覆盖、历史该双时态、错误该变成 skill 而这一切不始于某张精美的架构图, 而始
NOTE 一个 Agent 聊到第二十轮突然不守规矩, 第一百零一次工具调用吐出坏 JSON 第一反应通常是"框架有 bug", 可如果问题根本不在框架里呢? 温度、分词、注意力这些看起来离业务很远的东西, 决定了 Agent 的成本、延迟与稳定边界; 把它们当成玄学调参, 就只会在同一个坑里反复摔. 0x00 一句话
NOTE 同一个模型, 换一套外壳, 有的 Agent 能可靠跑完一单退款, 有的却在第三步就编出一句"已经帮你处理好了"差距究竟在模型里, 还是在模型之外? 上下文、工具、约束、验证、纠正, 每一环都决定它落地时是助手还是负担; 这篇文章要问的是, 把这些环节拼成生产可用的 Agent, 工程上到底要付出什么. 0x
NOTE 如果所有 Agent 都跑在同一套基础设施上, 那么当某个业务要求更高隔离、另一套集群容量见底、某个客户坚持私有网络部署时, 平台还剩多少选择? "一个控制面管理多个数据面"听起来只是多了一层抽象, 可它决定的其实是平台能不能跨机器、跨集群、跨云落地. 0x00 背景 Agent 平台通常由控制面和数据面组成
NOTE 在一个工作区里让一个 agent 去唤起另一个 agent 继续干活, 听起来只需要一句 @ ; 但它最容易长成的却是停不下来的成本循环 谁该被叫醒, 被叫醒时它究竟带着哪些上下文? 更反直觉的是: 决定一次运行的并不是上一条评论, 而是 runtime 为这次触发临时注入的任务 brief. agent 一
NOTE 用户说"这些技术栈都可以用", 一个 agent 会怎么理解? 大概率是把它们全部装进方案 因为它把"可用"读成了"必用". 同一个问题在编排上还会再出现一次: 当"组一个小队"被理解成"把成员都 @ 一遍", 平台实际只唤醒了一个 leader, 其余人从未收到任务. 那么, 一套真正可交付的智能体编排 s