OpenCode 番外篇:驾驭 AI 的法典、军团与薄壳 ✍ AI最严厉的父亲🕐 2026-07-22📦 21.6 KB 🟢 已读 𝕏 文章列表 文章指出 AI 编程的核心不是工具安装,而是建立权力结构与规则。作者通过 AGENTS.md、模型路由、MCP 和 Team Mode 等 OpenCode 机制,阐述如何通过立法、感官建立和验收来驾驭 AI 军团,强调开发者应成为立法者而非单纯的批准按钮。 AI编程OpenCodeAgent工程方法论模型路由AGENTSMCPTeamMode系统架构技术哲学 # OpenCode 番外篇:上篇·法典、军团与那层薄壳 **作者**: AI最严厉的父亲 **日期**: 2026-07-21T14:27:31.000Z **来源**: [https://x.com/dashen_wang/status/2079573994291023962](https://x.com/dashen_wang/status/2079573994291023962) ---  > 我不想再写一篇工具教程。 > 工具教程太容易写,也太容易骗人。 > 你把按钮顺序抄下来,像拿到一张地图。真上路的时候,发现地图上没有天气,没有塌方,没有你自己那只会发抖的手。 # 楔子:别把神灯当电灯泡 人类第一次看见大模型的时候,很多人脑子里冒出来的不是工具,是神。 不是宗教意义上的神。是那种很古老的、突然把边界往外推开的东西。你问一句,它答一句。你不会的,它会。你卡了三天的错误,它瞄一眼,给你一段能跑的代码。 那一刻很容易让人产生幻觉。 你会以为自己终于得到了一盏神灯。只要把愿望说清楚,灯神就会从烟里出来,把你想要的东西摆在桌上。 后来你用久了,就会发现不对。 神灯不是电灯泡。电灯泡接上电,亮就是亮,不亮就是坏。神灯会解释,会补全,会猜,会为了让你满意而把自己没看见的地方编圆。它最危险的地方不在于无能,而在于它太像有能。它会把一件没想清楚的事,写成一堆看起来已经想清楚的代码。 这就是 AI 编程真正要命的地方。 不是它不会写。它太会写了。 执行正在变成白菜价。以前你一个函数要写半小时,现在一句话能吐三版。以前你改一百个文件要排期,现在一个 agent 能在你泡茶的时候扫完整个仓库。执行便宜到这个程度,问题就换了。 以前的问题是:我怎么把它做出来。 现在的问题是:什么算对。 这五个字,是 OpenCode 这类工具背后真正的门槛。不是安装,不是模型,不是 MCP,不是哪个插件更强。那些都是剑。真正分人的,是握剑的人脑子里有没有一部法。 我这几年反复见到同一种死法:一个人打开 AI 编程工具,把它当一个更聪明的聊天框。他把需求扔进去,看它写,看它改,看它跑命令。刚开始很爽,像坐上高铁。三十分钟后,项目变成一坨他自己也不认识的东西。测试可能还是绿的,界面可能还会动,甚至提交说明还挺像人话。 但他已经失去了系统的所有权。 代码在他机器上。仓库在他账号下。键盘在他手边。可真正决定这套系统长成什么样的,已经不是他了。 他成了一个批准按钮。 这比被 AI 替代更丢人。替代至少说明你还有一个位置被拿走。变成批准按钮,说明你主动把位置让了出去。 我写这篇,不是为了吹 OpenCode。OpenCode 也不是神。OMO 也不是神。它们只是把一件原本藏在老工程师肌肉记忆里的事,做成了可以看见的结构:规则、权限、子代理、模型路由、MCP、hooks、Team Mode、日志、回滚、审查。 这些东西合起来,不叫“更会聊天”。 它叫驾驭。 # 第一章:驾驭不是让马更强,是让骑手不死 我很不喜欢 Harness 这个词。 中文翻成驾驭,差不多。但“驾驭”容易让人误会,以为重点在骑手多厉害。其实 Harness 更冷一点,它是一套连接系统。缰绳,马鞍,脚蹬,护具,口衔。它不提供马的力量,它只决定这股力量最后会不会把你摔死。 AI 模型就是马。 而且是人类造过最奇怪的一匹马:它力气大,速度快,记性短,讨好欲强,有时候聪明得像妖怪,有时候蠢得像刚出生。你不能靠“相信它”骑它。相信不是工程方法。相信是宗教。 工程方法是:把能信的地方写成契约,把不能信的地方关进笼子,把必须由人判断的地方留给人。 OpenCode 的价值,不在于它又给你一个聊天入口。聊天入口已经够多了。它的价值在于,它让 agent 不再只是屏幕里的嘴,而是一个被权限、上下文、工具、规则、日志和审查包住的执行体。 这件事听起来像产品功能。其实是权力结构。 普通聊天框里,权力结构很糊。你说一句,它回一句。它错了,你骂它。它道歉。然后继续错。整个过程像两个没有合同的人在酒桌上谈事,靠情绪维持秩序。 真正的 agent 工程里,权力结构必须硬。谁能读什么,谁能写什么,谁能跑命令,谁必须先问,谁只能研究,谁可以动手,谁来审判,谁负责记账。这些东西不写清楚,AI 就会用它自己的默认值替你写。 而模型的默认值,永远不是你的公司、你的项目、你的审美、你的风险承受能力。它只是互联网上无数平均值的幽灵。 平均值很危险。 平均值能写出能跑的代码。平均值也能把一个有灵魂的项目写成随处可见的外包模板。它不犯罪,它只是把你的东西磨平。 所以驾驭的第一条铁律是:不要让模型替你决定什么重要。 你可以让它执行。可以让它搜索。可以让它比较。可以让它写草稿。可以让它扮演一支小队,替你把你懒得干的脏活干完。 但“什么算对”,必须是你写下来的。 # 第二章:AGENTS.md 不是说明书,是你写给机器看的法 很多人第一次看见 AGENTS.md,会把它当 README 的亲戚。 错了。 README 是写给人看的。它讲项目怎么装、怎么跑、怎么贡献。AGENTS.md 是写给机器看的。它讲这台机器在这个项目里应该怎么活。 这两者的差别很大。 人读文档,会带着常识。机器读规则,只会带着上下文。你在 README 里写“注意不要提交密钥”,人知道这句话背后是什么:别把 .env 推上去,别把 token 写进例子,别在日志里露出真实值。机器不一定知道。你不把边界写实,它就会用“我觉得这样合理”补全。 “我觉得这样合理”,是 agent 事故的祖坟。 一份好的 AGENTS.md,不该像公司文化墙。不要写“追求卓越”“保持简洁”“注重质量”。这类话对人都有点没用,对机器更没用。它需要的是可执行的法条。 在这个目录里,本地规则写得很明白:这里是 AI 工具链运维底座,不处理无关项目;排障先本地后外部;inventory 是版本、路径、端口唯一事实源;凭据绝不入库;logs 只增不改;改完跑健康检查。 这不是文采。 这是边界。 边界的意义在于,它把“聪明”变成次要,把“守法”变成主要。一个模型再聪明,如果它跳过本地知识库直接上网搜,它在这个目录里就是错的。一个模型再能写,如果它把凭据复制进文章,它就是错的。一个模型再会修,如果它没读 inventory 就瞎说版本号,它就是错的。 法的作用,就是让你在它看起来很有道理的时候,仍然有东西能一刀砍下去,说:不行。 我越来越觉得,AI 时代最值钱的人,不是提示词写得最花的人,而是会立法的人。 提示词像口头命令。法典像操作系统。 口头命令会随着会话消失。法典会在每一次新会话里重新加载。口头命令依赖模型这次有没有听懂。法典把“听不听懂”降成一个可以检查、可以修、可以迭代的工程问题。 这也是为什么我不喜欢“AI 小白”这个词。 小白这个词会给人一种许可:我不懂,所以我可以乱来。可 agent 拿到文件写权限之后,你已经不是游客了。你坐在驾驶位上。你可以不懂引擎,但你不能不懂刹车。 AGENTS.md 就是第一块刹车片。 # 第三章:OMO 不是外挂,是军队编制 我以前写过,未来的团队是一支公会,不是一张组织架构图。 OMO 把这句话在工具层面做了一遍。 它没有假装一个模型能当所有人。它把事情拆成兵种:Sisyphus 做编排,Prometheus 做计划,Atlas 执行计划,Oracle 做高难度只读顾问,Librarian 查外部资料,Explore 翻代码库,Momus 挑计划的刺,Metis 找隐藏歧义,Sisyphus-Junior 按 category 去干活。 这不只是“多几个 agent”。 多几个 agent 如果没有编制,就是一群人挤在门口一起喊。真正有用的是编制:谁能动手,谁只读;谁适合视觉,谁适合逻辑;谁负责查资料,谁负责做最终实现;谁的成本高,谁的成本低;谁可以并行,谁必须等前置判断出来。 一个人用 AI 用到后面,最容易犯的错不是不会命令模型,而是舍不得分工。 他什么都让一个会话干。让它读文档,让它查网页,让它写计划,让它改代码,让它跑测试,让它自我审查。听起来省事,实际是把一整支队伍压成一个疲惫的人。上下文越来越胖,判断越来越糊,最后它忘了开头,也忘了谁该负责什么。 这跟现实里的烂公司一样。 老板觉得“大家都是同事,互相帮一下”,于是所有边界都被抹掉。销售写产品方案,产品盯客服,技术去做 PPT,最后每个人都在干别人不该干的活,真正该负责的地方没人负责。 OMO 的 category 系统有意思的地方在这里:它逼你先判断任务性质,而不是先迷信模型名。 UI 和视觉,走 visual-engineering。高难逻辑,走 ultrabrain。自主深度执行,走 deep。小修小补,走 quick。文档写作,走 writing。你不是在问“哪个模型最强”,你是在问“这件事是什么活”。 这才是工程。 一个很强的开发者,不是永远亲自下场敲每一行的人。那是手艺人,不是构架师。构架师的价值在于,他知道什么时候自己下刀,什么时候让别人拆骨,什么时候叫审计,什么时候停工。 AI 时代也是一样。 你不是跟一个模型聊天。你是在调一支机器军团。 军团最怕的不是兵不够强。军团最怕的是没有军法。 # 第四章:模型路由不是炫富,是把马派到它该跑的路上 中文 AI 圈有个毛病:一谈工具,就开始比模型。 谁更强,谁更贵,谁上下文更长,谁跑分更高。像一群刚拿驾照的人在路边比发动机,没人问你要开去哪里。 模型当然重要。不同模型确实有不同脾气。有的适合长文,有的适合代码,有的适合视觉,有的适合硬推理,有的适合便宜快速地跑小任务。但“最强模型包打一切”是穷人突然有钱后的幻觉。 真正的路由,不是把所有事都塞给最贵的马。 是把每匹马派到它最该跑的路上。 本机的路由表里,Sisyphus 走编排优先,Oracle 走高难推理,Explore 走快速代码检索,writing 走专门的文档通道。category 也有自己的模型和 fallback。这个结构真正表达的不是“我有很多模型”,而是:不同判断层的成本、速度、可靠性不一样。 你让最贵的模型改一个错别字,是浪费。你让便宜模型做复杂架构判断,是找死。你让写作模型去改生产配置,是岗位错配。你让视觉模型去做 UI 细节,才是让刀回到刀鞘里。 这里还有一个很多人会读错的点:fallback_models 不是护身符。 写了 fallback,不等于运行时会自动切。声明候选和启用运行时回退,是两件事。就像你通讯录里存了消防队电话,不等于房子起火时有人自动替你拨出去。要让切换发生,你得把 runtime_fallback 这层开关打开,还得重启,让进程真的读到它。 这件事很小,但很能说明 AI 工程的本质。 你以为你改的是配置。实际上你改的是运行时世界的法律。法律不被加载,就不存在。你写在磁盘上,进程没读,它就只是纸。 所以我越来越反感那些“万能配置包”。 配置不是符咒。复制过去不会自动保佑你。你得知道它什么时候被读取,谁读取,读取失败会怎样,改完怎么验证,出事怎么回滚。否则你不是在配置系统,你是在贴平安符。 贴符的人,早晚会被机器教育。 # 第五章:MCP 是感官,不是工具栏 MCP 这个东西,很容易被讲成“给 AI 接更多工具”。 这话没错,但太浅。 工具栏的想象,会让人贪多。搜索接一个,文档接一个,GitHub 接一个,浏览器接一个,图片接一个,数据库接一个,Slack 接一个。最后 agent 面前摆了二十把刀,每把刀都能碰真实世界。你以为它变强了,其实你只是把事故面积扩大了。 我更愿意把 MCP 看成感官。 人没有眼睛,看不见图。没有耳朵,听不见声。没有触觉,不知道东西烫不烫。模型本身没有外部世界。它只有上下文窗口里那点东西。MCP 给它接上外部感官:Web search 是远处的望远镜,Context7 是查官方文档的图书馆,grep.app 是看别人真实代码的公共街道,LSP 是语法神经,CodeGraph 是关系神经,视觉工具是眼睛。 感官的价值,不在于多。 在于准。 一个人不是因为全身长满眼睛才强。那叫怪物。真正强的是,该看的时候看,该闭的时候闭,该相信显微镜的时候不相信肉眼,该相信编译器的时候不相信感觉。 本机这套 MCP 七根神经都 connected,这很好。但“都连上”不是终点。终点是你知道什么时候该调哪根神经。 问库怎么用,先查官方文档。问这个项目里某个符号影响谁,先走代码图谱。问 UI 截图有没有崩,走视觉。问一个公开 repo 里别人怎么写,走 GitHub 代码搜索。 最蠢的是让模型凭记忆答。 模型的记忆像酒桌传闻。可能对,可能过期,可能把三个版本混在一起。MCP 的意义,就是把“凭印象”变成“有证据”。 一个强开发者和一个普通用户的差别,在这里特别明显。 普通用户问:你觉得应该怎么写? 强开发者问:证据在哪里?这个版本的文档怎么说?当前代码里谁调用它?跑一次结果是什么?改完有没有诊断? AI 不怕你粗鲁。它怕你没有判据。 # 第六章:hooks 是传感网,不是装饰品 一个系统真正变强,不是因为它会干更多事,而是因为它能更早知道自己快错了。 这句话适用于身体,也适用于公司,也适用于代码库。 身体有疼痛。疼痛很烦,但疼痛救命。你摸到火缩手,不是因为你道德高尚,是因为神经比你的哲学快。公司有财务报表、客户投诉、事故复盘。代码有编译器、类型检查、测试、日志。 Agent 系统也必须有传感网。 OMO 的 hooks,就是这张网。 它们不是“插件功能”。它们是把某些规则从人的提醒,降到机器的反射。未读就写文件,拦一下。AI 写废话注释,拦一下。todo 没做完就想停,拦一下。关键词触发某种工作模式,自动注入指令。运行时模型失败,按可恢复错误尝试 fallback。 这些东西单看都小。 但工程世界里,真正改变系统命运的,往往就是这些小到没人愿意认真写的东西。 “不要直接改没读过的文件”,人当然知道。可人会忘。agent 更会忘。把它写成 hook,它就不再依赖这一次会话有没有记住。它变成了反射。 这就是判定下沉。 不要把所有判断都留给人。人太贵,也太累。能交给编译器的,交给编译器。能交给 LSP 的,交给 LSP。能交给测试的,交给测试。能交给 hook 的,交给 hook。人只保留那几件机器真的够不着的事:取舍、品味、信任、方向。 这件事讲透了,其实就是薄壳公司的核心。 公司不是人多才强。公司强在有一层薄薄的规则,把人、机器、钱、责任、判断连接起来。壳太厚,官僚。壳太薄,散架。真正好的壳,不抢执行权,只保留治理权。 OpenCode 加 OMO 也是这样。 底下是模型,是 agent,是 MCP,是脚本,是命令,是一堆会跑的东西。上面必须有一层薄壳:规则、权限、路由、传感网、日志、回滚、人工门控。 这层薄壳不写代码,却决定代码会不会变成灾难。 # 第七章:Team Mode 不是热闹,是开团纪律 很多人一听 Team Mode,就兴奋。 多智能体协作。并行。共享任务。邮箱。tmux 可视化。十二个 team_* 工具。听起来像终于可以把一群 AI 放出去打仗了。 我反而想先泼冷水。 开团不是新手福利。开团是组织能力考试。 一个人连单 agent 的边界都没写清楚,开 Team Mode 只会把混乱并行化。原来一个模型乱改,现在四个模型一起乱改。原来一个会话忘上下文,现在四个成员互相丢消息。原来你不知道谁负责,现在每个成员都以为别人负责。 这不叫团队。 这叫灾难分布式部署。 真正该开团的场景很少,但很明确:多个互相独立的研究轴,多个不重叠的文件改动,长任务需要共享任务列表,或者你想让不同成员从不同角度互相质疑。比如一个人查官方文档,一个人看本地代码,一个人做安全角度,一个人写实现,一个人做 QA。每个人有边界,有产物,有停机条件。 Team Mode 默认关闭,是对的。 默认关闭不是因为它不强,而是因为它太强。强工具默认不该裸露。你把圆锯放在桌上,不会默认通电。你要用它,先知道手指在哪里。 本机已经把 team_mode.enabled 打开,tmux_visualization 关掉。这个选择也很工程:先要能力,不急着要热闹。tmux 可视化很好,能看每个成员怎么跑;但缺了它,不应该影响团队创建。工具的展示层不能绑架执行层。 这句话放大到所有 AI 工程也成立。 不要为了看起来像未来,牺牲系统真正能跑。 # 第八章:新手最该学的不是配置,是验收 我想把话说得难听一点。 很多所谓 AI 教程,教出来的是一群会启动工具、不会验收结果的人。 他们会装,会复制配置,会调用模型,会把终端搞得五颜六色。可你问他:这次改动为什么是对的?证据是什么?失败时从哪一层排?不可逆操作有没有门控?版本事实谁是 owner?他说不上来。 说不上来,就不算会。 AI 时代真正的新手村,不是“如何让 AI 帮你写第一个函数”。那太低了。真正的新手村应该教四件事: 第一,识别权力。这个工具能动什么?能读什么?能删什么?能发什么? 第二,写下法律。这个项目里什么算对,什么禁止,什么必须验证? 第三,建立感官。它需要哪些外部证据?官方文档、代码图谱、LSP、日志、截图、运行结果,各自负责哪一层? 第四,验收执行。改完以后,谁来证明它没错?编译器、测试、构建、手动跑一遍、人工 review,顺序是什么? 这四件事不会过时。 OpenCode 会升级。OMO 会改名。模型会换。今天的路由明天可能被更强的模型替掉。MCP 生态会长出更多工具。Team Mode 以后也可能变得更顺手。 但只要 AI 仍然是那个会执行、会猜、会补全、会把你的含糊变成真实改动的东西,这四件事就不会过时。 因为它们管的不是工具。 它们管的是权力。 # 结尾:你不是要成为 AI 的朋友 别再把 AI 当朋友了。 朋友这个词太软。朋友会被原谅,会被安慰,会因为“态度很好”获得第二次机会。生产系统不吃这一套。一个 agent 删除错文件之后说“我深感抱歉”,没有意义。文件不会因为它道歉长回来。 你也不是要成为 AI 的主人。 主人这个词又太旧。它会让人产生一种帝王幻觉,好像你发号施令,机器跪地执行。现实不是这样。现实里,你的大部分命令都很烂,你的很多需求都没想清楚,你的判断也会疲惫、漂移、被情绪污染。 更准确的关系是:你是立法者,也是最后的验收人。 机器军团负责执行。法典负责约束。传感网负责报警。MCP 负责感知外部世界。模型路由负责给不同任务派不同的马。Team Mode 在需要的时候开团。OpenCode 只是这一切运行起来的壳。 而你,不能把“什么算对”交出去。 这就是整篇的骨头。 AI 时代,执行会越来越便宜。便宜到最后,写代码本身会像打字一样不值钱。真正贵的,是判断;是边界;是验收;是把一群机器和一群人组织成一个能长期不散架的系统。 我为什么一直讲薄壳?因为未来的强公司、强个体、强团队,都不会靠一堵厚墙保护自己。墙会被模型推平。技能会被复刻。经验会被压缩成教程。藏着的井会干。 剩下能护住你的,是一层很薄但很硬的壳。 它不替你干活。 它只保证活不会把你反过来干掉。 下篇再讲怎么从新手村开始,把这层壳一片一片装起来。不要急着开团。不要急着炫模型。不要急着把所有 MCP 都接上。 先学会写法。 再学会验收。 最后,才轮到让军团冲锋。 ## 相关链接 - [AI最严厉的父亲](https://x.com/dashen_wang) - [@dashen_wang](https://x.com/dashen_wang) - [4.3K](https://x.com/dashen_wang/status/2079573994291023962/analytics) - [grep.app](https://grep.app/) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [10:27 PM · Jul 21, 2026](https://x.com/dashen_wang/status/2079573994291023962) - [4,357 Views](https://x.com/dashen_wang/status/2079573994291023962/analytics) --- *导出时间: 2026/7/22 11:07:14*
读 读 Google Cloud 多租户智能体 AI 系统参考架构 作者分享了阅读 Google Cloud 《多租户智能体 AI 系统》参考架构后的 5 个核心启发。文章指出企业级 Agent 落地需关注中心辐射模式、系统级安全防护(Model Armor)、MCP 的企业级用法以及完整的闭环流程。作者认为单纯依靠 Prompt 的时代即将结束,未来的重点在于系统架构设计与安全边界。 技术 › Agent ✍ lifcc🕐 2026-07-14 Agent多租户GoogleCloud系统架构安全防护MCP工程化
S Shopify 工程师团队的 Claude Code 配置与实战策略 文章详细介绍了 Shopify 23,000 名工程师如何通过 Claude Code 实现 96% 的代码自动化。核心策略包括:构建统一的 LLM 代理层以控制成本,并行运行多个 Agent 处理不同模块,利用 MCP 服务器集成内部文档与 API,以及将 CLAUDE.md 纳入版本控制。工程师角色正从代码编写者转向架构审查者,通过护栏机制保障安全。 技术 › Claude Code ✍ darkzodchi🕐 2026-05-19 AI编程ShopifyAgentMCP工程效率自动化LLM架构最佳实践团队协作
2 2026 年 AI 编程三强横评:OpenCode / Claude Code / Codex 本文是对 2026 年主流 AI 编程框架 OpenCode、Claude Code 和 Codex 的深度横评。文章详细介绍了 OpenCode 旗下的 OMO 插件及其多 Agent 编排哲学,并犀利指出了 OpenCode 目前面临的稳定性与性能问题。同时,对比了 Claude Code 的云端重构与 Ultraplan 特性,以及 Codex 的移动端与 Symphony 框架优势。作者认为模型能力差距正在收敛,真正的竞争在于 Agent 的编排与工具链整合,并推荐新手根据稳定性与生态需求选择合适的工具。 技术 › DevOps ✍ AI最严厉的父亲🕐 2026-05-17 AI编程OpenCodeClaude CodeCodexAgentLLM开发工具多Agent编排OMOCC Switch
C Claude Code新版本 + CodeGraph + MCP 组合拳!大型代码库直接起飞! 文章介绍了Claude Code 2.1.142、CodeGraph与MCP的“组合拳”方案,有效解决了大型代码库探索中tool call过多、上下文爆炸等问题。通过CodeGraph构建语义知识图谱,结合MCP持久化记忆与新版优化,实现了Tool call减少92%、代码探索速度提升71%的显著效果,并提供了详细的安装配置流程与实战场景指南。 技术 › Claude Code ✍ loveabit🕐 2026-05-16 Claude CodeCodeGraphMCPLLMAI编程DevOps工具与效率Agent技术选型代码优化
3 30天精通Claude Code:从入门到实战的完整路径 本文详细介绍了如何在30天内掌握Claude Code这一命令行自主编程Agent。文章将其划分为三个阶段:第一周侧重基础安装与环境配置(如CLAUDE.md文件的编写及Plan/Act模式的区分);第二周通过构建真实MVP项目来掌握调试与核心斜杠指令;第三周进阶至多文件重构及MCP服务器连接。旨在帮助开发者摆脱简单的聊天对话,利用Claude Code实现高效的代码编写、调试与部署。 技术 › Claude Code ✍ Mayank Agarwal🕐 2026-05-06 Claude CodeAI编程AgentCLIDevOps自动化开发工具MCP代码重构
A Anthropic Claude Code 源码剖析:为什么它比别人好用 基于 Anthropic 泄露的 Claude Code 源码,深入剖析其技术架构。文章指出 Claude Code 实为以 LLM 为内核的“操作系统”,拥有极致的提示词工程、42 个独立工具的安全管控、AI 记忆检索系统、子蜂群 Agent 机制以及三层上下文压缩技术。其 51 万行代码中有 95% 专注于安全、权限和上下文管理等工程脚手架,而非单纯的模型调用。 技术 › Claude Code ✍ Yuker🕐 2026-04-01 源码分析Agent提示词工程系统架构安全Anthropic上下文管理AI编程
O OpenCode免费白嫖指南:Claude Skill全攻略 本文介绍了2026年值得尝试的AI工具组合:OpenCode、Oh-My-Opencode与Claude Skills。作者详细讲解了如何通过OpenCode免费使用GLM-4.7等模型,安装Agent框架OMO,以及如何调用和创建Skills来实现一句话生成论文、画报和文案等功能。文章旨在降低AI编程门槛,让小白用户也能轻松上手。 技术 › 工具与效率 ✍ 向阳乔木🕐 2026-01-12 AI编程Claude SkillOpenCode免费AI工具AgentGLM-4.7Oh-My-Opencode教程自动化安装指南
B BestBlogs 早报 · 07-29|MCP 无状态化与多智能体编排成本 本期早报探讨 MCP 协议的无状态核心变化与 Claude 的生产化接入,分析 Codex 与 ChatGPT Work 共用的执行框架差异,并审视多智能体并行中上下文搬运的隐性成本“编排器的税”。同时涵盖图工程、vLLM 商业化及 Uber 零增长架构等速览内容。 技术 › LLM ✍ ginobefun🕐 2026-07-29 MCPAgentOpenAI架构多智能体上下文Claude早报DevOps工程化
百 百度网盘 + 闲鱼 MCP 一键发布实战指南 本文介绍了如何通过 MCP 协议将百度网盘与闲鱼连接,利用 AI Agent 自动化完成从网盘选取资料、生成文案到闲鱼发布商品的流程。文章详细讲解了环境配置、接口接入及常见坑点,帮助读者建立自动变现系统。 技术 › Agent ✍ mousepotato🕐 2026-07-27 MCP自动化闲鱼百度网盘AgentPython实战教程
T The Graph Engineering Setup Guide 本文介绍了图工程如何为Agent提供复合记忆。通过双时态模型和MCP配置,Claude可获得持久的图记忆,相比向量搜索,多跳任务准确率提升36-46%,幻觉减少40%以上。 技术 › Agent ✍ darkzodchi🕐 2026-07-24 Graph EngineeringGraph RAGMemoryMCPClaude CodeNeo4jKnowledge GraphAgent
开 开源月入10w+的Codex使用方法(超详细教学) 本文详细介绍了OpenAI推出的AI编程Agent Codex的使用方法,包括其与ChatGPT的区别、注册订阅流程、Web/桌面/CLI/IDE四种安装方式,以及桌面App的页面功能全解,帮助非程序员利用AI提升效率。 技术 › Codex ✍ 产品经理老王霸🕐 2026-07-23 AI编程OpenAICodex教程效率工具Agent
A AI 产品经理的系统思维:从种花到构建智能系统 文章阐述了 AI 产品的有机特性,强调系统思维对 AI 产品经理的重要性。核心观点包括:系统行为源于组件交互、结构与规则比参数更具杠杆效应、新演员(Agent)出现时价值流向接口。实践层面建议通过分解产品、定义契约和设计反馈循环,将 Agent 深度融入产品,以建立竞争壁垒。 技术 › Agent ✍ Christine Zhu🕐 2026-07-23 AI产品系统思维Agent产品设计PM系统架构反馈循环SaaS