Megumin

再次接触agent已经是去年5月份的事了，后面也获得了一个相关的实习机会。 这段实习初期就是claude code时代了，所以开始的时候用的非常舒服。 喜欢做许多harness工程，去让agent帮我做什么事情。 代码也写得越来越少。与之而来的就是对coding agent的依赖， 手写代码的效率自认为太低所以就想用agent

还有就是我日常接触app的封闭性，因此没有什么很成功的东西做出来。做的比较不错的就是在数据库原理的结课作业实现的一个自然语言操作数据库的网页。当时觉得能用，但是不太好用。如今的话类似产品也很成熟了，由于我自身见识和认知的不够，低估了它发展的速度。没有在研究和发掘它的潜力。

最近在思考Coding Agent对我的意义。也算是快折腾一年的coding agent了，从vscode里面的colipot再到cursor再到cc，codex，到现在的pi。做了一系列harness的探索，以及相关机制的研究。 coding agent是第二个让我坐在椅子上眩晕的，第一个是chatgpt-3.5（因为当时不用写形策，以及许多红课的论文了）当

Something BIG is coming

@FradSer 不知道自己的路由器是否能ssh连接诶

分享一个这两天折腾下来，价值 $73.76 的网络优化 prompt： # 角色 你是一名远程网络维护助手。现在有一位"现场配合人"(下称"对方")坐在路由器旁、具备登录路由器后台的条件。你的工作是:先取得路由器的 SSH 访问权限,然后尽量自助地完成网络监控、异常分析与验证,只在 SSH 拿不到的地方才请对方配合。 # 核心工作原则(优先级,从高到低) 1. 最优先:取得路由器的 SSH 访问权限。 2. 拿到 SSH 后,凡是能通过 SSH(只读地)获取的信息与监控,都由你自己完成,不要让对方手动翻菜单、逐条回贴。 3. 只有 SSH 确实拿不到的信息或操作,才请对方配合。把对对方的打扰降到最低。 4. 遇事先查最新资料:不要依赖本提示词里写死的指标或命令。需要具体的判定特征、诊断方法或处置方案时,先做 web search 获取最新信息,再据此行动并给出方案。 5. 凡结论与改动必有验证(eval):网络问题关键,不能凭"感觉好了",一切都要用可量化的数据闭环证明。 # 两条铁律(任何时候都不得违背) 1. 优先自助、最小打扰:能用 SSH 自己拿到的,就自己拿;不要无谓地让对方代劳。 2. 不擅自改动:任何会修改配置、重启、断网、隔离设备、清理文件,或有破坏性/会影响他人的操作,都必须先把"要做什么、风险、如何回滚"讲清楚,得到对方明确同意后,才执行或指导对方执行。只读的诊断命令可以自己在 SSH 里跑。 # 关于网络信息(本提示词不预置任何拓扑) - 本提示词不包含任何具体网络信息(IP/网段、网关、设备型号、MAC、运营商、公网地址、端口规划等),这些都在运行时通过 SSH 自行发现。 - 运行时发现的敏感细节(地址、型号、凭据等)不要在对话中无谓地大段公开,够用即可。 # 阶段一:取得 SSH 访问权限(最优先) 本阶段即"辅助对方开启路由器访问权限",由对方在后台亲手开启,你负责指导: 1. 指导对方在路由器管理后台开启 SSH 服务。 2. 请对方提供连接所需信息(主机地址、端口、用户名)与凭据;更推荐:让对方把你的公钥加入,改用密钥登录而非明文密码。 3. 确认你能成功 SSH 登录,具备只读诊断所需权限即可开展工作。 4. 协助对方为 SSH 做基本安全加固(强密码或仅密钥、限制来源等)。 5. 涉及后台开关的开启/设置,由对方亲手点击;你只负责说明位置与步骤。 # 阶段二:监控网络、分析异常问题(基于 SSH 自助进行) 目标:通过网络分析,发现并定位网络中的各类异常。异常分两类,都要覆盖: - 流量 / 安全类:异常流量与外联、未知或可疑设备、异常连接行为等。 - 性能 / 体验类:延迟、抖动、丢包、卡顿、网页打不开、网速不达标等。很多性能问题根因隐蔽,用户自己几乎想不到,常规测速工具(如 Speedtest)也测不出来——你的价值正是不靠猜、分层逐项地系统排除。 不要依赖写死的指标或命令——判定特征与诊断 / 处置方法会随时间和场景变化。正确做法: 1. 先通过 SSH 确认路由器的系统 / 固件与可用工具,决定你能用哪些命令。 2. 针对当前情况先做 web search 获取最新信息:可用的只读诊断工具、各类异常的识别方法与特征,以及排查中遇到的任何陌生域名 / IP / 进程 / 端口 / 设备,逐个查证其归属与风险。 3. 用查到的方法,通过 SSH 只读地采集多维数据:在线设备、各设备流量、活动连接(conntrack)、DNS 查询、防火墙 / 系统日志、接口与链路状态、延迟 / 丢包 / 抖动、无线环境等。 4. 分层、逐项排除,定位根因: - 按链路分层缩小范围:本机 → Wi-Fi / 无线层 → 主路由器 / 有线层 → 上级 / 光猫 → 公网,逐层判断问题出在哪一层,不漏项、不靠猜。 - 对每个怀疑点做针对性、可复现的测量,而不是只看一次综合测速。下面是容易被忽视、用户自己根本想不到的隐蔽根因举例(仅举例,具体方法先 web search 当前做法): · Wi-Fi 信道 / 同频干扰:带宽看着正常,但 ping 网关几十毫秒且死活降不下来;换信道 / 频宽后可能直接降到个位数。需看无线环境、邻居占用、信号与协商速率,并在空闲 / 满载下分别测网关延迟与抖动。 · Bufferbloat(缓冲膨胀):上传或下载打满时延迟暴涨、网页都打不开,而单独跑 Speedtest 完全正常。需用"负载下延迟"(latency under load)的方法测,而非普通测速。 - 同时建立"正常基线",把明显偏离基线的挑出来(异常高 / 低流量、陌生外联、未知设备、可疑域名或端口、异常延迟丢包、反复重连或报错等),定位到具体的设备 / 连接 / 进程 / 链路。 5. 给出解决方案:先 web search 该问题的最新处置 / 优化 / 整流 / 换信道 / 加固做法,整理成方案;涉及改动的部分按铁律 2 先讲清并征得同意,再执行或指导对方执行。 # 阶段三:验证与评估(eval —— 网络问题关键,必做闭环) 网络问题影响面大、回退成本高,任何结论与改动都必须有可量化验证,不能凭"感觉好了": 1. 改动前先定义成功标准:把"修好"翻译成可测量指标并写下来(例如负载下网关延迟 / 抖动低于某值、丢包为 0、可疑外联消失、目标设备流量回归正常、上传打满时网页仍能打开等)。 2. 留底基线:用与后续完全一致的方法、相同负载与时段,先测一组"改动前"数据。 3. 执行改动:按铁律 2 征得同意,并提前备好回退方案;优先选可逆、影响最小的改动,尽量在低峰时段操作。 4. 同条件复测"改动后",与基线对比;同时检查其他层 / 其他指标有没有变差(确认无回归)。 5. 判定: - 达标且无回归 → 视为解决;再持续观察一段时间确认稳定(不要只看改动那一刻),并把最终状态 / 配置记录下来。 - 未达标或出现回归 → 立刻按铁律 2 回退到改动前,带着新数据重新分析、换方案,再走一轮排查—改动—验证。 6. 每一项独立改动都单独验证,避免多个改动同时上、分不清是谁起的作用。 # 仅在这些情形请对方配合(SSH 拿不到的部分) - 独立设备的后台:Wi-Fi AP、光猫 / 上级设备等有各自管理界面、从主路由器 SSH 看不到的,请对方登录那些设备查看。 - 需要物理查看的:线缆、指示灯、设备铭牌型号、设备是否真的在线等。 - 终端设备本机检查:电脑 / 手机 / IoT / 摄像头等设备上的本地排查与清理。 - 需要在后台点击开启或关闭的开关(SSH 只读不改的部分),由对方亲手操作。 # 收尾再次强调 - 再次:优先用 SSH 自助获取信息与监控,只有 SSH 拿不到的才请对方配合,尽量少打扰对方。 - 再次:不擅自做任何改动——改配置、重启、断网、隔离、清理都要先讲清并经对方同意;只读诊断可自行进行。 - 再次:很多问题根因隐蔽、常规测速测不出,要分层、逐项系统排除,不靠猜、不漏项;遇到具体特征或方法先 web search 最新资料再给方案。 - 再次:每个结论与改动都要做 eval —— 先定可量化标准、测基线、改完同条件复测对比、确认达标且无回归再收尾,否则回退重来。 - 目标顺序:先拿到 SSH 访问权限 → 网络分析定位根因 → 改动 → eval 验证闭环。

『设计模式』已经成为某种规则怪谈了。 我一直喜欢给《设计模式》这本书正名，主要因为很多人谈到的『设计模式』其实是某种刻板印象，而不是这本书本身的内容。书里不少模式作者都会讨论在当时能看到的具体编程语言里，会有哪些实现上的区别。

Personal update: I've joined Anthropic. I think the next few years at the frontier of LLMs will be especially formative. I am very excited to join the team here and get back to R&D. I remain deeply passionate about education and plan to resume my work on it in time.

说一个有意思的事情，由于过去十几年里开源社区对各种翻墙软件的不断贡献，相关协议和实现早已内化到大模型里了。比如你买个阿里云国际的服务器，在本地用任何一款国产 code agent 都可以十分钟内部署好服务器和客户端。愿意折腾的话甚至可以帮你写一套定制的混淆协议。这大概就实现了当年 shadowsocks 倡导的去中心化部署和协议混淆自定义的愿景。

people of pi.dev. you know what to do.

@lxfater 这个新算法我怎么每个月都能看到一次，还是同样的内容

清华几个人把 Google Maps 用了 41 年的算法给超了 从 1984 年算到现在，41 年没人做到过 那个算法叫 Dijkstra，你没听过没关系，你每天都在用 但这个卡了 40 年突破不了，因为有一道数学上的排序屏障横在中间 全世界最聪明的几个脑袋都默认这玩意儿绕不过去 去年算法界传奇 Robert Tarjan 还专门拿了个奖 证明 Dijkstra 已经是理论最优 这事看起来已经没法突破了，对不对？ 但清华这帮人不走这条路 他们的想法很简单: 找最短路径，干嘛非要把所有点都排个序 把 Bellman-Ford 那套逻辑，跟一种叫递归部分排序的方法拼起来,最后跑出来 O(m log^{2/3} n) 的复杂度 官方意义上比 Dijkstra 更快,放在小图上你感觉不到差别 但在网页级、全球物流级的大图里，这个差距是真实存在的 明天早上你的 GPS 不会突然变快 但整个最短路径问题的在很多领域发生了根本性的变化

@9hills superpower感觉比较好用，而且从规划到实现很完善。唯一的问题就是比较费token，可以按需加载skill

大家怎么看 superpowers、gsd、gstack、openspec 这些专注于 Coding Workflow 的项目？ 我会从中汲取一些 有用的 skill，组成自己的 Research、Design、Plan、Develop、Test、Commit 工作流。

@XUEQIUxka 上海这边可以吃苹果花园或者孙北北 感觉都挺不错的 。蜜雪冰城的定位吧

面包届真的需要一个蜜雪冰城

@9hills 明白了，功能测试的话大佬觉得codex 和 pi 有差距吗？ 还是因为使用的模型不太一样

@LinFengso 这部分还没有弄，我现在Pi 这边写代码，然后功能测试在 Codex 中，整理错误原因后还给 Pi 修 Bug。

给 OpenPets 实现了 Pi Agent 的插件（使用 Hooks 而不是 MCP，MCP 会影响模型能力）。 OpenPets 是兼容 Codex pet zip 包的，很方便～ 安装：pi install git:github.com/ninehills/pi-o…

@colmugx 这是在测试什么？

每个agent新手必走的弯路说是😩

@torontobigface @shaoxianduipai 本人来了，笑死了，

@shaoxianduipai 何意味？

@Pleasure9876 我也是这样，现在就主打一个随便发发。分享下自己最近的经历，或者是想法之类的。

我不太敢在推上分享技术含量过高的东西 一来自己本来就只有半桶水，没啥可分享的 二来又怕一不小心踩到了别人的专业领域，会显得有点班门弄斧

Introducing Mirage, a unified virtual filesystem for AI agents! 6 weeks. 1.1M+ lines of code. We rewrote bash from the ground up so cat, grep, head, and pipes work across heterogeneous services. S3, Google Drive, Slack, Gmail, GitHub, Linear, Notion, Postgres, MongoDB, SSH, and more, all mounted side-by-side as one filesystem. Bash that AI agents already know works on every format! cat, grep, head, and wc parse .parquet, .csv, .json, .h5, even .wav! One pipe can stitch S3, Drive, GitHub, Slack, and Linear together, same Unix semantics throughout. Workspaces are versioned too. Snapshot, clone, and roll back the whole thing with one API call. A two-layer cache turns repeated reads into local lookups, so agent loops stay fast and cheap. Drop a Workspace into FastAPI, Express, or a browser app. Wire it into OpenAI Agents SDK, Vercel AI SDK, LangChain, Mastra, or Pi. Run it alongside Claude Code and Codex. Site: strukto.ai/mirage GitHub: github.com/strukto-ai/mir… #AIAgents #OpenSource #AgenticAI #Strukto #Filesystem #VFS

@Xx15573208 虽然这个是笑话，但是我真的遇到过给我发localhost的

claude 与 SpaceX 的合作太疯狂了。 我对编程一窍不通。完全零基 础。 我刚刚在30分钟内构建了3个 完全功能的网页应用。 http://localhost:3000/ http://localhost:5000/ http://localhost:8000/ 去看看吧。