[{"data":1,"prerenderedAt":1994},["ShallowReactive",2],{"blog-taxonomies":3,"blog-stats":507,"post-2026\u002F2026-06-13-从上下文工程到-agent-harness-engineering":1083},[4,11,16,21,25,29,36,39,44,47,52,58,63,66,71,76,80,84,87,93,96,101,105,110,113,117,122,127,132,136,141,143,146,151,155,157,162,165,169,173,176,179,183,186,190,193,197,200,205,208,211,214,219,222,228,234,237,239,245,249,253,256,260,266,271,276,281,283,287,290,293,298,301,304,306,308,311,314,316,318,321,327,332,337,342,347,352,354,356,358,361,365,367,369,371,374,376,378,381,386,390,393,396,400,404,407,411,413,415,417,421,423,425,428,431,433,435,437,439,441,443,446,448,450,454,456,459,461,463,465,467,469,471,473,477,483,486,488,491,493,495,497,499,501,503,505],{"category":5,"tags":6},"笔记",[7,8,9,10],"QQ","插件","LiteLoader","美化",{"category":12,"tags":13},"其他",[14,15,10],"博客","IP签名",{"category":17,"tags":18},"杂谈",[19,20],"互联网","观点",{"category":5,"tags":22},[14,23,24],"GitHub","数据可视化",{"category":5,"tags":26},[14,27,28],"访问统计","不蒜子",{"category":30,"tags":31},"工具",[32,33,34,35],"Python","爬虫","选课脚本","广州大学",{"category":5,"tags":37},[38,5],"数学分析",{"category":40,"tags":41},"算法",[42,40,43],"数据结构","线性表",{"category":40,"tags":45},[42,46],"复习",{"category":5,"tags":48},[49,50,51],"高等代数","线性代数","知识点",{"category":5,"tags":53},[14,54,55,56,57],"Typora","PicGo","图床","Markdown",{"category":30,"tags":59},[60,61,62],"Jupyter","工具配置","中文",{"category":30,"tags":64},[65,61,10],"VSCode",{"category":30,"tags":67},[68,69,70,35],"路由器","OpenWrt","校园网",{"category":12,"tags":72},[73,74,75],"网络协议","Wireshark","DEVP2P",{"category":5,"tags":77},[73,74,78,79],"Lua","解码器",{"category":5,"tags":81},[82,5,83],"常微分方程","数学",{"category":5,"tags":85},[86,5,83],"概率论",{"category":30,"tags":88},[89,90,91,92],"Docker","WSL","Windows","磁盘清理",{"category":30,"tags":94},[32,33,95,35],"课程表",{"category":5,"tags":97},[14,98,99,100],"Hexo","Gitalk","评论系统",{"category":5,"tags":102},[14,103,98,104],"Obsidian","写作工具",{"category":12,"tags":106},[107,108,109],"课题研究","泊松分布","参数估计",{"category":12,"tags":111},[107,108,109,112],"组会",{"category":12,"tags":114},[109,115,108,116],"IM模型","统计学",{"category":17,"tags":118},[119,120,121],"软考","网络规划","信息系统项目管理",{"category":30,"tags":123},[124,125,126],"Arch Linux","AppImage","Linux",{"category":5,"tags":128},[129,130,131],"编程语言","计算机科学","内存管理",{"category":5,"tags":133},[134,135],"Canvas","前端",{"category":5,"tags":137},[14,138,139,140],"GitHub Actions","Vite","部署",{"category":5,"tags":142},[135],{"category":5,"tags":144},[135,145],"系统设计",{"category":5,"tags":147},[135,148,149,150],"安全","XSS","CSRF",{"category":152,"tags":153},"项目",[134,154],"PixiJS",{"category":152,"tags":156},null,{"category":40,"tags":158},[42,159,160,161],"栈","队列","JavaScript",{"category":40,"tags":163},[42,164,161],"哈希表",{"category":5,"tags":166},[167,161,168],"ES6","Set",{"category":40,"tags":170},[40,171,172],"动态规划","背包问题",{"category":40,"tags":174},[40,175],"滑动窗口",{"category":40,"tags":177},[42,178,161],"链表",{"category":40,"tags":180},[40,181,161,182],"ACM","面试",{"category":40,"tags":184},[40,161,185],"数据类型转换",{"category":40,"tags":187},[42,188,178,189],"顺序表","TypeScript",{"category":5,"tags":191},[135,154,134,192],"渲染",{"category":5,"tags":194},[135,195,134,196],"富文本编辑","wangEditor",{"category":40,"tags":198},[199,40,178],"力扣",{"category":5,"tags":201},[202,203,204,91],"DNS","加密","网络安全",{"category":5,"tags":206},[135,207],"Axios",{"category":5,"tags":209},[135,207,189,210],"接口封装",{"category":5,"tags":212},[135,213,145],"JWT",{"category":152,"tags":215},[134,216,217,154,218],"画布","React","项目开发",{"category":17,"tags":220},[221],"日志",{"category":5,"tags":223},[224,225,226,227],"Neo4j","图数据库","中心度分析","PageRank",{"category":12,"tags":229},[230,231,232,233],"论文","机器学习","随机森林","保险欺诈",{"category":5,"tags":235},[236],"人工智能",{"category":5,"tags":238},[231,40,32],{"category":12,"tags":240},[241,242,243,244],"共识算法","最长链","区块链","算法设计",{"category":5,"tags":246},[161,247,248,135],"闭包","作用域",{"category":5,"tags":250},[14,138,251,252],"RSS","自动化",{"category":30,"tags":254},[89,90,91,255],"安装",{"category":30,"tags":257},[258,91,259],"MSYS2","开发环境",{"category":5,"tags":261},[262,263,264,265],"团队协作","Git","Commit规范","代码审查",{"category":30,"tags":267},[268,269,270],"oh-my-posh","终端美化","CLI",{"category":5,"tags":272},[273,274,275],"上下文工程","Agent","RAG",{"category":5,"tags":277},[278,279,280],"前端工程化","技术选型","工程基建",{"category":5,"tags":282},[275],{"category":5,"tags":284},[285,286],"SDD","规格驱动开发",{"category":5,"tags":288},[289],"neovim",{"category":5,"tags":291},[292],"技术写作",{"category":5,"tags":294},[295,32,296,89,297],"FastAPI","后端","工程实践",{"category":152,"tags":299},[274,300],"Harness Engineering",{"category":5,"tags":302},[303],"RFC",{"category":152,"tags":305},[274,300,275],{"category":152,"tags":307},[274],{"category":40,"tags":309},[199,40,161,310],"两数之和",{"category":40,"tags":312},[199,40,161,313],"双指针",{"category":40,"tags":315},[199,40,161,178],{"category":40,"tags":317},[199,40,161,175],{"category":40,"tags":319},[199,40,161,320],"回溯",{"category":5,"tags":322},[323,324,325,326],"分布式处理与计算","Spark","Scala","RDD",{"category":5,"tags":328},[323,329,330,331],"线性回归","逻辑回归","监督学习",{"category":5,"tags":333},[323,334,335,336],"数值优化","牛顿法","收敛性",{"category":5,"tags":338},[323,339,340,341],"PCA","数据降维","正则化",{"category":5,"tags":343},[323,344,345,346],"聚类","层次聚类","K-Means",{"category":5,"tags":348},[323,349,350,351],"随机模拟","统计推断","EM算法",{"category":5,"tags":353},[24],{"category":5,"tags":355},[24],{"category":5,"tags":357},[24],{"category":40,"tags":359},[42,360],"图论",{"category":40,"tags":362},[42,363,364],"树","二叉树",{"category":40,"tags":366},[42,160],{"category":40,"tags":368},[42],{"category":40,"tags":370},[42,159],{"category":40,"tags":372},[42,40,373],"复杂度分析",{"category":40,"tags":375},[42,43,178],{"category":40,"tags":377},[42,43,188],{"category":40,"tags":379},[42,380],"基础概念",{"category":17,"tags":382},[383,384,385],"随记","照片","高中",{"category":17,"tags":387},[383,388,389],"团建","战地",{"category":17,"tags":391},[383,392],"生活",{"category":17,"tags":394},[383,395],"文学",{"category":17,"tags":397},[383,398,399],"SCP","模因",{"category":17,"tags":401},[383,402,403],"画集","艺术",{"category":17,"tags":405},[14,406,383],"写作",{"category":17,"tags":408},[383,409,410],"音乐","摇滚",{"category":17,"tags":412},[383,392],{"category":17,"tags":414},[383,409],{"category":17,"tags":416},[383,35,392],{"category":17,"tags":418},[383,419,420],"同人","手书",{"category":17,"tags":422},[383,392],{"category":17,"tags":424},[383,392],{"category":17,"tags":426},[383,427],"植物",{"category":17,"tags":429},[383,430],"读书",{"category":17,"tags":432},[383,392],{"category":17,"tags":434},[383,392],{"category":17,"tags":436},[383,392],{"category":17,"tags":438},[383,392],{"category":17,"tags":440},[383,392],{"category":17,"tags":442},[383,392],{"category":17,"tags":444},[14,445,383],"一周年",{"category":17,"tags":447},[383,392],{"category":17,"tags":449},[383,392],{"category":17,"tags":451},[35,452,453],"开源组织","SITE-193",{"category":17,"tags":455},[383,392],{"category":17,"tags":457},[383,458],"年末",{"category":17,"tags":460},[383,392],{"category":17,"tags":462},[383,392],{"category":17,"tags":464},[14,17],{"category":17,"tags":466},[383,392],{"category":17,"tags":468},[383,392],{"category":17,"tags":470},[383,392],{"category":17,"tags":472},[383,392],{"category":17,"tags":474},[383,475,476],"游戏","Control",{"category":30,"tags":478},[479,480,481,482],"Quadim","图像处理","四叉树","Rust",{"category":17,"tags":484},[14,485],"上线纪念",{"category":17,"tags":487},[383,395],{"category":30,"tags":489},[203,490],"测试",{"category":17,"tags":492},[383],{"category":17,"tags":494},[383,392],{"category":17,"tags":496},[383],{"category":5,"tags":498},[40],{"category":5,"tags":500},[40],{"category":5,"tags":502},[40],{"category":5,"tags":504},[40],{"category":5,"tags":506},[40],[508,512,516,520,524,528,532,536,540,544,548,552,556,560,564,568,572,576,579,583,587,590,594,598,602,606,610,614,618,622,626,630,634,638,642,646,650,654,658,662,666,670,674,678,682,686,690,694,698,702,706,710,714,718,722,726,730,734,738,742,746,750,754,758,762,766,770,774,778,782,786,790,794,798,801,805,809,813,817,821,825,829,833,837,841,845,849,853,857,861,865,869,873,877,881,885,889,893,897,901,904,907,911,915,919,923,927,930,934,938,942,946,950,954,957,961,965,969,973,977,981,984,988,992,996,1000,1004,1007,1011,1015,1019,1023,1027,1031,1035,1039,1043,1047,1051,1055,1059,1063,1067,1071,1075,1079],{"path":509,"words":510,"published":511,"date":156},"\u002Fposts\u002F2024\u002F2024-06-25-liteloaderqqnt",1296,"2024-06-25 11:03:08",{"path":513,"words":514,"published":515,"date":156},"\u002Fposts\u002F2024\u002F2024-06-26-ip签名",0,"2024-06-26 22:53:53",{"path":517,"words":518,"published":519,"date":156},"\u002Fposts\u002F2024\u002F2024-06-29-何加盐中文互联网正在加速崩塌",4853,"2024-06-29 00:47:13",{"path":521,"words":522,"published":523,"date":156},"\u002Fposts\u002F2024\u002F2024-07-12-github-chart",270,"2024-07-12 20:02:50",{"path":525,"words":526,"published":527,"date":156},"\u002Fposts\u002F2024\u002F2024-07-14-访客数统计",192,"2024-07-24 01:34:28",{"path":529,"words":530,"published":531,"date":156},"\u002Fposts\u002F2024\u002F2024-07-26-广大选课脚本",110,"2024-07-26 01:34:28",{"path":533,"words":534,"published":535,"date":156},"\u002Fposts\u002F2024\u002F2024-07-26-数学分析笔记其二",14,"2024-07-26 23:54:02",{"path":537,"words":538,"published":539,"date":156},"\u002Fposts\u002F2024\u002F2024-07-26-数据结构复习其二",12856,"2024-07-26 02:48:08",{"path":541,"words":542,"published":543,"date":156},"\u002Fposts\u002F2024\u002F2024-07-26-数据结构复习相关",32856,"2024-07-26 02:24:14",{"path":545,"words":546,"published":547,"date":156},"\u002Fposts\u002F2024\u002F2024-07-26-线性代数与空间解析几何知识点全汇总",6110,"2024-07-26 03:27:55",{"path":549,"words":550,"published":551,"date":156},"\u002Fposts\u002F2024\u002F2024-07-31-typora-picgo-兰空图床打造markdown写作环境",311,"2024-07-31 12:56:23",{"path":553,"words":554,"published":555,"date":156},"\u002Fposts\u002F2024\u002F2024-09-02-jupyter配置中文",441,"2024-09-02 23:49:05",{"path":557,"words":558,"published":559,"date":156},"\u002Fposts\u002F2024\u002F2024-09-02-自定义vscode背景图片",100,"2024-09-02 23:39:00",{"path":561,"words":562,"published":563,"date":156},"\u002Fposts\u002F2024\u002F2024-09-03-制作gzhu校园网路由器",1423,"2024-09-03 23:43:18",{"path":565,"words":566,"published":567,"date":156},"\u002Fposts\u002F2024\u002F2024-09-26-09-25-2024",136,"2024-09-26 00:49:26",{"path":569,"words":570,"published":571,"date":156},"\u002Fposts\u002F2024\u002F2024-11-04-创建一个网络包解码器分析devp2p协议",1943,"2024-11-04 16:45:19",{"path":573,"words":574,"published":575,"date":156},"\u002Fposts\u002F2024\u002F2025-03-09-2024一些笔记常微分",16,"2024-12-09 22:51:00",{"path":577,"words":574,"published":578,"date":156},"\u002Fposts\u002F2024\u002F2025-03-09-2024一些笔记概率论","2025-03-09 22:51:00",{"path":580,"words":581,"published":582,"date":156},"\u002Fposts\u002F2025\u002F2025-03-01-windows下释放docker占用的wsl空间",164,"2025-03-01 13:54:15",{"path":584,"words":585,"published":586,"date":156},"\u002Fposts\u002F2025\u002F2025-03-01-爬虫实战-爬取广州大学课程表",774,"2025-03-01 14:55:48",{"path":588,"words":530,"published":589,"date":156},"\u002Fposts\u002F2025\u002F2025-04-03-hexo集成gitalk的问题","2025-04-03 14:26:34",{"path":591,"words":592,"published":593,"date":156},"\u002Fposts\u002F2025\u002F2025-09-22-记一次配置obsidian配合hexo写博客",92,"2025-09-22 16:47:52",{"path":595,"words":596,"published":597,"date":156},"\u002Fposts\u002F2025\u002F2025-10-24-10-20课题",204,"2025-10-24 08:15:01",{"path":599,"words":600,"published":601,"date":156},"\u002Fposts\u002F2025\u002F2025-11-02-组会朝花夕拾",501,"2025-11-02 18:56:59",{"path":603,"words":604,"published":605,"date":156},"\u002Fposts\u002F2025\u002F2025-11-05-基于随机加权推断模型im的参数估计算法",481,"2025-11-05 20:51:41",{"path":607,"words":608,"published":609,"date":156},"\u002Fposts\u002F2025\u002F2025-11-09-关于软考高项网规",884,"2025-11-09 19:54:52",{"path":611,"words":612,"published":613,"date":156},"\u002Fposts\u002F2025\u002F2025-11-17-arch-linux运行appimage相关",365,"2025-11-17 09:59:59",{"path":615,"words":616,"published":617,"date":156},"\u002Fposts\u002F2025\u002F2025-11-19-相关概念",2058,"2025-11-19 11:06:20",{"path":619,"words":620,"published":621,"date":156},"\u002Fposts\u002F2025\u002F2025-11-21-web可视化实践canvas",6393,"2025-11-21 14:50:48",{"path":623,"words":624,"published":625,"date":156},"\u002Fposts\u002F2025\u002F2025-11-22-使用-github-actions-自动部署基于vite的项目到-github-pages",272,"2025-11-23 01:59:24",{"path":627,"words":628,"published":629,"date":156},"\u002Fposts\u002F2025\u002F2025-11-22-关于前端包管理器npmpnpmyarn和bun",4890,"2025-11-22 21:21:15",{"path":631,"words":632,"published":633,"date":156},"\u002Fposts\u002F2025\u002F2025-11-23-undo-redo-机制具体实现",7839,"2025-11-23 19:15:00",{"path":635,"words":636,"published":637,"date":156},"\u002Fposts\u002F2025\u002F2025-11-27-前端安全-关于xss与crsf",1866,"2025-11-28 02:05:25",{"path":639,"words":640,"published":641,"date":156},"\u002Fposts\u002F2025\u002F2025-12-05-现代协同-2d-画布编辑器pixijs-v8",4285,"2025-12-05 02:00:16",{"path":643,"words":644,"published":645,"date":156},"\u002Fposts\u002F2025\u002F2025-12-07-杂谈-课题组系统设计",3710,"2025-12-07 21:09:33",{"path":647,"words":648,"published":649,"date":156},"\u002Fposts\u002F2025\u002F2025-12-25-javascript中的数组方法与栈stack和队列queue的实现",474,"2025-11-29 16:58:15",{"path":651,"words":652,"published":653,"date":156},"\u002Fposts\u002F2025\u002F2025-12-25-关于javascript-实现哈希表",189,"2025-11-27 11:31:39",{"path":655,"words":656,"published":657,"date":156},"\u002Fposts\u002F2025\u002F2025-12-25-关于javascript的set方法",332,"2025-12-25 15:26:18",{"path":659,"words":660,"published":661,"date":156},"\u002Fposts\u002F2025\u002F2025-12-25-关于动态规划(背包问题为例)",1238,"2025-11-17 18:24:04",{"path":663,"words":664,"published":665,"date":156},"\u002Fposts\u002F2025\u002F2025-12-25-关于滑动窗口",712,"2025-11-20 15:04:40",{"path":667,"words":668,"published":669,"date":156},"\u002Fposts\u002F2025\u002F2025-12-25-关于链表(javascript)",500,"2025-11-25 13:00:48",{"path":671,"words":672,"published":673,"date":156},"\u002Fposts\u002F2025\u002F2025-12-25-面试算法acm模式构建构建输入输出模板",2051,"2025-12-25 23:09:45",{"path":675,"words":676,"published":677,"date":156},"\u002Fposts\u002F2025\u002F2025-12-26-javascript-数字数组字符串的处理",483,"2025-12-26 11:20:25",{"path":679,"words":680,"published":681,"date":156},"\u002Fposts\u002F2025\u002F2025-12-26-javascripttypescript-的顺序表链表实现",446,"2025-12-26 12:16:12",{"path":683,"words":684,"published":685,"date":156},"\u002Fposts\u002F2025\u002F2025-12-27-前端画布设计vol-1-实现基础yuan素渲染和状态控制",2136,"2025-12-28 01:23:08",{"path":687,"words":688,"published":689,"date":156},"\u002Fposts\u002F2025\u002F2025-12-27-前端画布设计vol-2-实现富文本编辑",1838,"2025-12-28 02:58:47",{"path":691,"words":692,"published":693,"date":156},"\u002Fposts\u002F2025\u002F2025-12-27-算法刷题-关于链表操作",2135,"2025-12-27 16:12:42",{"path":695,"words":696,"published":697,"date":156},"\u002Fposts\u002F2025\u002F2025-12-27-配置dnscrypt-proxy实现加密dns服务windows",1899,"2025-11-15 01:06:37",{"path":699,"words":700,"published":701,"date":156},"\u002Fposts\u002F2025\u002F2025-12-28-前端-关于网络请求xhrajaxfetchaxios",7788,"2025-10-28 15:48:46",{"path":703,"words":704,"published":705,"date":156},"\u002Fposts\u002F2025\u002F2025-12-28-前端-接口封装与请求规范axios为例",2373,"2025-12-29 01:01:18",{"path":707,"words":708,"published":709,"date":156},"\u002Fposts\u002F2025\u002F2025-12-28-前端-身份验证管理-基于-jwt-token-的实现",2709,"2025-11-23 22:04:41",{"path":711,"words":712,"published":713,"date":156},"\u002Fposts\u002F2025\u002F2025-12-29-记canvas画布项目开发",6254,"2025-12-29 04:52:15",{"path":715,"words":716,"published":717,"date":156},"\u002Fposts\u002F2025\u002Fabout-site",116,"2025-03-31 16:44:24",{"path":719,"words":720,"published":721,"date":156},"\u002Fposts\u002F2025\u002F使用neo4j图数据科学库gds进行中心度分析",143,"2025-04-02 23:37:24",{"path":723,"words":724,"published":725,"date":156},"\u002Fposts\u002F2026\u002F2026-01-03-论文实训草稿",10445,"2026-01-03 14:10:49",{"path":727,"words":728,"published":729,"date":156},"\u002Fposts\u002F2026\u002F2026-01-06-人工智能导论",11461,"2026-01-07 03:25:49",{"path":731,"words":732,"published":733,"date":156},"\u002Fposts\u002F2026\u002F2026-01-07-机器学习相关算法",82,"2026-01-08 02:28:13",{"path":735,"words":736,"published":737,"date":156},"\u002Fposts\u002F2026\u002F2026-01-16-关于低复杂度最长链共识算法设计",4466,"2026-01-16 10:33:23",{"path":739,"words":740,"published":741,"date":156},"\u002Fposts\u002F2026\u002F2026-01-19-杂记2026-01-19",5754,"2026-01-20 01:03:26",{"path":743,"words":744,"published":745,"date":156},"\u002Fposts\u002F2026\u002F2026-01-22-github-action-自动同步博客到-github-主页",1069,"2026-01-22 16:31:47",{"path":747,"words":748,"published":749,"date":156},"\u002Fposts\u002F2026\u002F2026-03-01-windows-wsl安装docker",257,"2026-03-01 20:55:31",{"path":751,"words":752,"published":753,"date":156},"\u002Fposts\u002F2026\u002F2026-03-14-关于-msys2",701,"2026-03-15 03:05:04",{"path":755,"words":756,"published":757,"date":156},"\u002Fposts\u002F2026\u002F2026-03-28-团队项目协作规范随记",2419,"2026-03-29 05:33:50",{"path":759,"words":760,"published":761,"date":156},"\u002Fposts\u002F2026\u002F2026-03-29-oh-my-posh配置分享",104,"2026-03-29 16:34:43",{"path":763,"words":764,"published":765,"date":156},"\u002Fposts\u002F2026\u002F2026-06-13-从上下文工程到-agent-harness-engineering",8840,"2026-06-13 21:06:20",{"path":767,"words":768,"published":769,"date":156},"\u002Fposts\u002F2026\u002F2026-07-13-简谈前端基建质量标准与ai友好建设",3814,"2026-07-13 21:06:20",{"path":771,"words":772,"published":773,"date":156},"\u002Fposts\u002F2026\u002F2026-07-15-agentic-rag-系统实践",13357,"2026-07-15 21:06:20",{"path":775,"words":776,"published":777,"date":156},"\u002Fposts\u002F2026\u002F2026-07-18-简谈sdd规范驱动开发-copy",4476,"2026-07-18 11:06:20",{"path":779,"words":780,"published":781,"date":156},"\u002Fposts\u002F2026\u002F2026-07-20-个人neovim配置分享",366,"2026-07-22 13:46:50",{"path":783,"words":784,"published":785,"date":156},"\u002Fposts\u002F2026\u002F2026-07-20-关于技术写作-设计文档",6763,"2026-07-20 13:46:50",{"path":787,"words":788,"published":789,"date":156},"\u002Fposts\u002F2026\u002F2026-07-29-fastapi-工程实践随记",3417,"2026-07-29 04:58:34",{"path":791,"words":792,"published":793,"date":156},"\u002Fposts\u002Frfc_agentic_project\u002F2026-06-19-rfc-liskin_code_agent",3563,"2026-06-19 15:18:20",{"path":795,"words":796,"published":797,"date":156},"\u002Fposts\u002Frfc_agentic_project\u002F2026-07-25-rfc-glushkov_ogas",13461,"2026-07-28 23:46:50",{"path":799,"words":800,"published":793,"date":156},"\u002Fposts\u002Frfc_agentic_project\u002F2026-08-03-adr-ogas-arkhiv",2698,{"path":802,"words":803,"published":804,"date":156},"\u002Fposts\u002Frfc_agentic_project\u002Frag\u002F2026-08-12-arkhiv_rag-vol-1",4366,"2026-08-12 15:18:20",{"path":806,"words":807,"published":808,"date":156},"\u002Fposts\u002Fleetcode\u002F2025-12-25-力扣百题速练javascripttypescriptvol-1",3108,"2025-12-25 13:57:08",{"path":810,"words":811,"published":812,"date":156},"\u002Fposts\u002Fleetcode\u002F2025-12-26-力扣百题速练javascripttypescriptvol-2",3185,"2025-12-26 13:57:08",{"path":814,"words":815,"published":816,"date":156},"\u002Fposts\u002Fleetcode\u002F2025-12-28-力扣百题速练javascripttypescriptvol-3",2533,"2025-12-29 02:15:44",{"path":818,"words":819,"published":820,"date":156},"\u002Fposts\u002Fleetcode\u002F2026-01-17-力扣百题速练javascripttypescriptvol-4",3024,"2026-01-17 22:53:01",{"path":822,"words":823,"published":824,"date":156},"\u002Fposts\u002Fleetcode\u002F2026-01-19-力扣百题速练javascripttypescriptvol-5",293,"2026-01-19 15:15:12",{"path":826,"words":827,"published":828,"date":156},"\u002Fposts\u002F分布式处理与计算\u002F分布式处理与计算spark系统与scala语言",4320,"2026-07-06 14:10:49",{"path":830,"words":831,"published":832,"date":156},"\u002Fposts\u002F分布式处理与计算\u002F分布式处理与计算分类与回归分析",2081,"2026-07-07 12:40:29",{"path":834,"words":835,"published":836,"date":156},"\u002Fposts\u002F分布式处理与计算\u002F分布式处理与计算数值优化方法",2182,"2026-07-07 13:50:29",{"path":838,"words":839,"published":840,"date":156},"\u002Fposts\u002F分布式处理与计算\u002F分布式处理与计算数据降维",1583,"2026-07-07 21:50:29",{"path":842,"words":843,"published":844,"date":156},"\u002Fposts\u002F分布式处理与计算\u002F分布式处理与计算聚类分析",1882,"2026-07-07 16:50:29",{"path":846,"words":847,"published":848,"date":156},"\u002Fposts\u002F分布式处理与计算\u002F分布式处理与计算随机模拟与统计推断",2433,"2026-07-06 22:40:29",{"path":850,"words":851,"published":852,"date":156},"\u002Fposts\u002F数据可视化\u002F2026-06-14-数据可视化-基本图像",10011,"2026-06-14 20:18:20",{"path":854,"words":855,"published":856,"date":156},"\u002Fposts\u002F数据可视化\u002F2026-06-14-数据可视化-概论",10030,"2026-06-14 15:18:20",{"path":858,"words":859,"published":860,"date":156},"\u002Fposts\u002F数据可视化\u002F2026-06-15-数据可视化-可视化库",2032,"2026-06-15 20:18:20",{"path":862,"words":863,"published":864,"date":156},"\u002Fposts\u002F数据结构\u002F2025-09-29-数据结构-图",5451,"2025-04-15 20:48:06",{"path":866,"words":867,"published":868,"date":156},"\u002Fposts\u002F数据结构\u002F2025-09-29-数据结构-树",4211,"2025-04-30 02:19:06",{"path":870,"words":871,"published":872,"date":156},"\u002Fposts\u002F数据结构\u002F2025-09-29-数据结构-队列",921,"2025-04-11 15:30:08",{"path":874,"words":875,"published":876,"date":156},"\u002Fposts\u002F数据结构\u002F关于数据结构的一些想法",456,"2025-04-04 19:13:49",{"path":878,"words":879,"published":880,"date":156},"\u002Fposts\u002F数据结构\u002F数据结构-栈",920,"2025-04-18 00:17:37",{"path":882,"words":883,"published":884,"date":156},"\u002Fposts\u002F数据结构\u002F数据结构-算法复杂度",2153,"2025-04-05 16:09:55",{"path":886,"words":887,"published":888,"date":156},"\u002Fposts\u002F数据结构\u002F数据结构-线性表链表",4572,"2025-04-06 00:24:40",{"path":890,"words":891,"published":892,"date":156},"\u002Fposts\u002F数据结构\u002F数据结构-线性表顺序表",4191,"2025-04-05 22:09:59",{"path":894,"words":895,"published":896,"date":156},"\u002Fposts\u002F数据结构\u002F数据结构-绪论",2881,"2025-04-05 11:31:22",{"path":898,"words":899,"published":156,"date":900},"\u002Fposts\u002F杂记\u002F2023-12-26-2023年12月26日",7,"2023-12-26 23:51:33",{"path":902,"words":899,"published":156,"date":903},"\u002Fposts\u002F杂记\u002F2024-01-01-2024团建","2024-01-01 01:51:27",{"path":905,"words":581,"published":156,"date":906},"\u002Fposts\u002F杂记\u002F2024-01-09-随记","2024-01-09 20:50:35",{"path":908,"words":909,"published":156,"date":910},"\u002Fposts\u002F杂记\u002F2024-03-12-花名",5275,"2024-03-12 16:04:23",{"path":912,"words":913,"published":156,"date":914},"\u002Fposts\u002F杂记\u002F2024-04-15-逆模因",1353,"2024-04-15 00:26:16",{"path":916,"words":917,"published":156,"date":918},"\u002Fposts\u002F杂记\u002F2024-05-03-艺作",27,"2024-05-03 00:01:00",{"path":920,"words":921,"published":156,"date":922},"\u002Fposts\u002F杂记\u002F2024-05-21-关于博客",1720,"2024-02-21 23:21:11",{"path":924,"words":925,"published":156,"date":926},"\u002Fposts\u002F杂记\u002F2024-06-20-dnvrc维克多崔专访-2023",2036,"2024-06-20 00:28:39",{"path":928,"words":760,"published":156,"date":929},"\u002Fposts\u002F杂记\u002F2024-06-25-6月25日随记","2024-06-25 12:46:36",{"path":931,"words":932,"published":156,"date":933},"\u002Fposts\u002F杂记\u002F2024-06-25-歌名-想見星星",148,"2024-06-25 22:47:59",{"path":935,"words":936,"published":156,"date":937},"\u002Fposts\u002F杂记\u002F2024-07-11-桂花岗",6,"2024-07-11 00:28:17",{"path":939,"words":940,"published":156,"date":941},"\u002Fposts\u002F杂记\u002F2024-07-15-rolling-bocci",9,"2024-07-15 21:25:56",{"path":943,"words":944,"published":156,"date":945},"\u002Fposts\u002F杂记\u002F2024-07-22-七月九日",34,"2024-07-09 17:54:23",{"path":947,"words":948,"published":156,"date":949},"\u002Fposts\u002F杂记\u002F2024-07-22-六月随记",1052,"2024-07-22 01:03:19",{"path":951,"words":952,"published":156,"date":953},"\u002Fposts\u002F杂记\u002F2024-07-22-石菖蒲",41,"2024-07-10 01:26:05",{"path":955,"words":514,"published":156,"date":956},"\u002Fposts\u002F杂记\u002F2024-07-23-新书","2024-07-23 01:05:49",{"path":958,"words":959,"published":156,"date":960},"\u002Fposts\u002F杂记\u002F2024-07-29-年前",74,"2024-07-29 23:59:07",{"path":962,"words":963,"published":156,"date":964},"\u002Fposts\u002F杂记\u002F2024-07-30-周边",138,"2024-07-30 02:03:23",{"path":966,"words":967,"published":156,"date":968},"\u002Fposts\u002F杂记\u002F2024-07-31-2024-7-31日",185,"2024-07-31 01:21:52",{"path":970,"words":971,"published":156,"date":972},"\u002Fposts\u002F杂记\u002F2024-08-02-八月",1710,"2024-08-30 00:31:02",{"path":974,"words":975,"published":156,"date":976},"\u002Fposts\u002F杂记\u002F2024-09-01-九月",1484,"2024-09-26 16:30:15",{"path":978,"words":979,"published":156,"date":980},"\u002Fposts\u002F杂记\u002F2024-09-08-2024年9月8日",97,"2024-09-08 13:59:36",{"path":982,"words":514,"published":156,"date":983},"\u002Fposts\u002F杂记\u002F2024-09-19-博客站的一周年","2024-09-18 23:36:24",{"path":985,"words":986,"published":156,"date":987},"\u002Fposts\u002F杂记\u002F2024-10-03-十月",1028,"2024-10-31 23:54:27",{"path":989,"words":990,"published":156,"date":991},"\u002Fposts\u002F杂记\u002F2024-11-04-十一月",2134,"2024-11-30 00:04:39",{"path":993,"words":994,"published":156,"date":995},"\u002Fposts\u002F杂记\u002F2024-11-10-gzhu-site-193",80,"2024-11-10 19:19:12",{"path":997,"words":998,"published":156,"date":999},"\u002Fposts\u002F杂记\u002F2024-12-01-十二月",455,"2024-12-30 23:13:47",{"path":1001,"words":1002,"published":156,"date":1003},"\u002Fposts\u002F杂记\u002F2024-12-21-年末",23,"2024-12-21 23:21:49",{"path":1005,"words":522,"published":156,"date":1006},"\u002Fposts\u002F杂记\u002F2025-01-30-一月","2025-01-30 23:44:41",{"path":1008,"words":1009,"published":156,"date":1010},"\u002Fposts\u002F杂记\u002F2025-03-01-二月",224,"2025-02-28 00:11:08",{"path":1012,"words":1013,"published":156,"date":1014},"\u002Fposts\u002F杂记\u002F2025-03-01-博客杂谈",344,"2025-03-01 16:03:18",{"path":1016,"words":1017,"published":156,"date":1018},"\u002Fposts\u002F杂记\u002F2025-03-05-三月",2090,"2025-03-05 19:17:28",{"path":1020,"words":1021,"published":156,"date":1022},"\u002Fposts\u002F杂记\u002F2025-07-10-七月",361,"2025-07-10 22:04:32",{"path":1024,"words":1025,"published":156,"date":1026},"\u002Fposts\u002F杂记\u002F2025-09-21-九月",781,"2025-09-21 20:53:37",{"path":1028,"words":1029,"published":156,"date":1030},"\u002Fposts\u002F杂记\u002F2025-10-09-十月",591,"2025-10-09 00:35:07",{"path":1032,"words":1033,"published":156,"date":1034},"\u002Fposts\u002F杂记\u002Fcontrol",13,"2023-09-25 13:03:59",{"path":1036,"words":1037,"published":156,"date":1038},"\u002Fposts\u002F杂记\u002Fquadim四叉树图像处理",1094,"2023-10-21 11:27:06",{"path":1040,"words":1041,"published":156,"date":1042},"\u002Fposts\u002F杂记\u002Fsuccess",24,"2023-09-22 15:59:07",{"path":1044,"words":1045,"published":156,"date":1046},"\u002Fposts\u002F杂记\u002F三光年",295,"2023-11-18 04:18:40",{"path":1048,"words":1049,"published":156,"date":1050},"\u002Fposts\u002F杂记\u002F加密测试",961,"2023-11-21 14:24:01",{"path":1052,"words":1053,"published":156,"date":1054},"\u002Fposts\u002F杂记\u002F啊啊啊啊啊啊啊",54,"2023-09-20 17:29:33",{"path":1056,"words":1057,"published":156,"date":1058},"\u002Fposts\u002F杂记\u002F杂谈",124,"2023-09-25 23:11:32",{"path":1060,"words":1061,"published":156,"date":1062},"\u002Fposts\u002F杂记\u002F艹",25,"2023-10-21 17:40:43",{"path":1064,"words":1065,"published":1066,"date":156},"\u002Fposts\u002F神经网络\u002F神经网络与深度学习卷积神经网络",3168,"2026-06-07 11:23:08",{"path":1068,"words":1069,"published":1070,"date":156},"\u002Fposts\u002F神经网络\u002F神经网络与深度学习循环神经网络",2348,"2026-06-07 11:33:08",{"path":1072,"words":1073,"published":1074,"date":156},"\u002Fposts\u002F神经网络\u002F神经网络与深度学习改进学习方法",3360,"2026-06-07 10:13:08",{"path":1076,"words":1077,"published":1078,"date":156},"\u002Fposts\u002F神经网络\u002F神经网络与深度学习深度生成模型",2727,"2026-06-07 11:43:08",{"path":1080,"words":1081,"published":1082,"date":156},"\u002Fposts\u002F神经网络\u002F神经网络与深度学习神经网络基础",3205,"2026-06-07 10:03:08",{"id":1084,"title":1085,"abbrlink":1086,"body":1087,"category":5,"cover":1982,"date":156,"description":1983,"extension":1984,"mathjax":1985,"meta":1986,"navigation":1985,"path":763,"published":765,"readingMinutes":1989,"seo":1990,"stem":1991,"sticky":156,"swiper_index":156,"tags":1992,"updated":156,"words":764,"__hash__":1993},"posts\u002Fposts\u002F2026\u002F2026-06-13-从上下文工程到 Agent Harness Engineering.md","2026-06-13-从上下文工程到 Agent Harness Engineering","f3a243ef",{"type":1088,"value":1089,"toc":1925},"minimark",[1090,1095,1100,1105,1109,1112,1120,1124,1131,1142,1149,1164,1167,1171,1174,1178,1181,1192,1195,1198,1202,1205,1208,1219,1225,1229,1232,1247,1251,1254,1260,1263,1269,1280,1283,1286,1292,1296,1304,1307,1313,1316,1320,1323,1325,1329,1333,1336,1359,1362,1366,1373,1387,1390,1394,1409,1412,1416,1423,1431,1438,1441,1443,1447,1450,1454,1457,1460,1463,1470,1477,1485,1500,1504,1515,1518,1521,1524,1527,1530,1533,1536,1539,1545,1549,1552,1556,1559,1570,1573,1575,1579,1582,1597,1601,1604,1608,1611,1617,1620,1624,1627,1630,1633,1636,1639,1641,1645,1649,1652,1656,1659,1662,1665,1669,1672,1680,1683,1689,1692,1703,1707,1721,1725,1728,1731,1733,1737,1741,1744,1750,1754,1757,1763,1767,1774,1778,1781,1784,1789,1791,1794,1797,1800,1806,1812,1818,1824,1830,1836,1842,1846,1849,1852,1855,1858,1862,1870,1888,1892,1895,1901,1904,1910,1913,1916,1919,1922],[1091,1092,1094],"h1",{"id":1093},"从上下文工程到-agent-harness-engineering","从上下文工程到 Agent Harness Engineering",[1096,1097,1099],"h2",{"id":1098},"范式转移从编码者到-agent-驾驭者","范式转移：从编码者到 Agent 驾驭者",[1101,1102,1104],"h3",{"id":1103},"ai-时代的研发焦虑与反直觉现象","AI 时代的研发焦虑与反直觉现象",[1106,1107,1108],"p",{},"有一个很反直觉的现象：AI Coding 把代码的生成速度提高了整整一个数量级，可产品的交付速度却并没有跟着变快。\n问题到底卡在哪里？答案是非编码的那部分工作量，正随着代码生成量的暴涨而指数级地膨胀。",[1106,1110,1111],{},"把一次完整交付拆开看，真正写代码的环节大概只占三成时间，而这恰恰是 AI 用的最多的地方；紧接着的验证、QA 和测试要吃掉四成时间，至今仍高度依赖人工；部署、发布、灰度又占去两成，只能算部分自动化；剩下一成的排障、沟通和 Code Review，则几乎全靠人力。AI 把那块本就不算最耗时的环节压缩到了极致，却对占了七成的非编码流程无能为力。",[1106,1113,1114,1115,1119],{},"这正是所谓的",[1116,1117,1118],"strong",{},"局部最优陷阱","，人反而成了整条链路上最大的瓶颈——AI 写完代码之后，你得帮它 Review、帮它测试、帮它善后，工作量不降反升。",[1101,1121,1123],{"id":1122},"什么是-harness-engineering","什么是 Harness Engineering？",[1106,1125,1126],{},[1127,1128],"img",{"alt":1129,"src":1130},"alt text","https:\u002F\u002Fpicx.zhimg.com\u002F80\u002Fv2-2f3326aa80c07f564c71fc2b393738bf_720w.webp",[1106,1132,1133,1134,1137,1138,1141],{},"Harness 这个词的本意是\"马具\"：我们要完成的转变，是从一个",[1116,1135,1136],{},"使用模型的人","，变成一个",[1116,1139,1140],{},"驾驭模型的人","。「不要只把大模型看作'大脑'，必须为它打造专属的'工作室'。」",[1106,1143,1144,1145,1148],{},"首先是任务形态的变化，从过去的代码补全走向 Agentic Coding——单次任务的运行时间从秒级一路拉长到分钟级乃至小时级。随之而来的是工程师角色的重新定位，工作重心从亲手\"编写代码\"转向\"设计环境、明确意图、提供反馈\"。而衡量这一切做得好不好的指标是 ",[1116,1146,1147],{},"Agent 可读性","：能不能把整个代码库重新塑造成一个模型能够\"读懂\"的环境。",[1106,1150,1151,1152,1155,1156,1159,1160,1163],{},"整套方法论可以收敛到三个相互支撑的维度。\n",[1116,1153,1154],{},"好的上下文","精准布局 Prompt 结构、保护前缀稳定性，让 KV Cache 能够高效复用；\n",[1116,1157,1158],{},"好的工具","强调提供快速、结构化、带有\"痛觉反馈\"的 API，而不是一套面向人类操作的 GUI；\n",[1116,1161,1162],{},"可读的环境","则要求把一切从\"对人友好\"重新校准为\"对 Agent 可读\"的结构化语义，在下面进行阐述",[1165,1166],"hr",{},[1096,1168,1170],{"id":1169},"transformer-底层物理规律agent-的硬约束","Transformer 底层物理规律：Agent 的「硬约束」",[1106,1172,1173],{},"Harness Engineering 的底层逻辑是处理模型的物理限制，强调模型对外界能力的应用",[1101,1175,1177],{"id":1176},"自回归生成为什么是一个-token-一个-token-地吐","自回归生成：为什么是一个 token 一个 token 地吐？",[1106,1179,1180],{},"绝大部分 LLM 的本质，是一个\"下一个 token 预测器\"。用形式化的方式写出来是这样：",[1182,1183,1188],"pre",{"className":1184,"code":1186,"language":1187},[1185],"language-text","P(x₁, x₂, ..., xₜ) = ∏ P(xₜ | x₁, ..., xₜ₋₁)\n\n每生成第 t 个 token，都需要看完前面所有 t-1 个 token\n","text",[1189,1190,1186],"code",{"__ignoreMap":1191},"",[1106,1193,1194],{},"先把已有的前缀喂进模型，模型据此输出一个关于\"下一个 token\"的概率分布，然后从分布里采样或挑选出一个 token，把它拼回输入，如此循环往复，直到吐出终止符为止。",[1106,1196,1197],{},"于是衍生出来一个问题：在没有 KV Cache 的情况下，要生成第 100 个词，模型得把前面 99 个词全部重新算一遍。上下文越长，这种重复计算就越离谱。也就是为什么塞进去一大坨 System Prompt 加代码之后，GPU 要\"转很久\"才肯出第一个字。",[1101,1199,1201],{"id":1200},"kv-cache为什么追加便宜修改昂贵","KV Cache：为什么「追加」便宜、「修改」昂贵？",[1106,1203,1204],{},"要理解这一点，得先对 Self-Attention 里的 Q、K、V 有个直觉。\n把 Query 理解成当前 token 想问的问题——\"我指代的到底是前面哪个词？\"\n把 Key 理解成每个历史 token 的自我介绍或标签——\"我是个名词\u002F动词\u002F时间状语\"\n把 Value 理解成每个历史 token 携带的详细语义内容,也就是具体的词义、情感和关系信息。\nAttention 的计算,就是拿当前的 Q 和所有历史的 K 做点积打分,经过 softmax 得到注意力权重,再对所有 V 加权求和。",[1106,1206,1207],{},"KV Cache 机制的聪明之处，在于把已经算过的 K 和 V 缓存下来。这样每来一个新 token，只需要计算它自己的 Q、K、V，再和缓存里的内容做一次 Attention 就行。",[1106,1209,1210,1211,1214,1215,1218],{},"这就直接导致了一个极不对称的成本结构。",[1116,1212,1213],{},"追加（Append）极度便宜","：老的 KV 全部可以复用，只需为新 token 算上这一次，增量成本是 O(新 token)。而",[1116,1216,1217],{},"修改中间内容则极其昂贵","：一旦你改动了某个位置，它之后所有 token 的 KV 全部作废、必须重算，成本是 O(N)。",[1220,1221,1222],"blockquote",{},[1106,1223,1224],{},"一切上下文工程，本质上都是为了「尽量不破坏前缀」 追加 = 复用 KV；修改 = 缓存作废",[1101,1226,1228],{"id":1227},"prompt-cache降本-90-的工程杠杆","Prompt Cache：降本 90% 的工程杠杆",[1106,1230,1231],{},"这套机制落到钱上，效果非常惊人。以 Claude Sonnet 的定价为例，基础输入大约是 $3.75\u002FMTok（相当于 1.25 倍率），而一旦命中 Prompt Cache，Cache Read 的价格只要 $0.30\u002FMTok，也就是 0.1 倍率——成本直接降低九成，同时推理速度大幅提升。",[1106,1233,1234,1235,1238,1239,1242,1243,1246],{},"由此能引出几条很实在的工程启示。它",[1116,1236,1237],{},"更快","，因为缓存了 KV 就能跳过 Prefill，首 Token 延迟大幅缩短；它",[1116,1240,1241],{},"更省","，因为 Cache Read 只要基础价的十分之一；但它有个",[1116,1244,1245],{},"前提","——前缀必须保持稳定，千万不要在开头塞时间戳、随机种子这类每次都在变的内容，否则缓存命中无从谈起。",[1101,1248,1250],{"id":1249},"attention-数学推导与-prefilldecode-两阶段","Attention 数学推导与 Prefill\u002FDecode 两阶段",[1106,1252,1253],{},"把 Self-Attention 的完整公式写出来，前面的直觉就有了精确的落点：",[1182,1255,1258],{"className":1256,"code":1257,"language":1187,"meta":1191},[1185],"Attention(Q, K, V) = softmax(QK^T \u002F √d_k) · V\n\n其中：\n- Q = X · W_Q    (Query 矩阵，当前位置的\"提问\")\n- K = X · W_K    (Key 矩阵，每个位置的\"标签\")\n- V = X · W_V    (Value 矩阵，每个位置的\"内容\")\n- d_k = Key 的维度，用于缩放防止点积过大导致梯度消失\n- softmax 沿 K 的序列维度归一化，得到注意力权重 α\n",[1189,1259,1257],{"__ignoreMap":1191},[1106,1261,1262],{},"实际模型里用的是 Multi-Head Attention，做法是把 Q、K、V 切成 h 个头，每个头各自独立做一遍 Attention，最后拼接起来：",[1182,1264,1267],{"className":1265,"code":1266,"language":1187,"meta":1191},[1185],"MultiHead(Q, K, V) = Concat(head_1, ..., head_h) · W_O\n\nhead_i = Attention(Q · W_Q^i, K · W_K^i, V · W_V^i)\n\n# 好处：不同的 head 关注不同类型的依赖关系\n# 有的 head 关注语法结构，有的关注语义相似性，有的关注位置关系\n",[1189,1268,1266],{"__ignoreMap":1191},[1106,1270,1271,1272,1275,1276,1279],{},"推理过程其实分成性格迥异的两个阶段。",[1116,1273,1274],{},"Prefill（预填充）阶段","的输入是整个 Prompt，可能多达数万 token，它要一次性把所有 token 的 K\u002FV 都算出来并缓存，计算量很大但高度并行，决定的是首 Token 延迟（TTFT）。",[1116,1277,1278],{},"Decode（解码）阶段","则每次只处理一个新 token，只算它自己的 Q\u002FK\u002FV 再和缓存做 Attention，单步计算量很小但天然串行，决定的是 token 之间的延迟（TBT）。",[1106,1281,1282],{},"这正是工程上的要害所在： Coding Agent 塞进几万字上下文时，Prefill 阶段会变得极其昂贵——这就是\"首 Token 延迟大\"的物理根源，而 Prompt Cache 的全部意义，就是跳过 Prefill 里那段已经缓存好的前缀。",[1106,1284,1285],{},"至于模型为什么只能\"往前看\"，靠的是因果 Mask：",[1182,1287,1290],{"className":1288,"code":1289,"language":1187,"meta":1191},[1185],"Causal Mask（下三角矩阵）:\n\n     t1  t2  t3  t4  t5\nt1 [  1   0   0   0   0 ]   ← t1 只能看自己\nt2 [  1   1   0   0   0 ]   ← t2 能看 t1, t2\nt3 [  1   1   1   0   0 ]   ← t3 能看 t1, t2, t3\nt4 [  1   1   1   1   0 ]\nt5 [  1   1   1   1   1 ]   ← t5 能看所有前面的\n\n# 0 的位置在 softmax 前被设为 -∞，确保未来信息不泄露\n# 这就是\"自回归\"的数学保证\n",[1189,1291,1289],{"__ignoreMap":1191},[1101,1293,1295],{"id":1294},"pytorch-推理代码看懂重复计算的代价","PyTorch 推理代码——看懂重复计算的代价",[1182,1297,1302],{"className":1298,"code":1300,"language":1301,"meta":1191},[1299],"language-python","import torch\n\n# model: 自回归语言模型 (input_ids) -> logits\n# tokenizer: 文本 \u003C-> token id\n\n# 1. 准备初始输入\nprompt = \"给 user-service 加一个 \u002Fhealthz 接口\"\ninput_ids = tokenizer.encode(prompt, return_tensors=\"pt\")  # shape: [1, prompt_len]\n\n# 2. 自回归生成循环\nmax_new_tokens = 200\nfor step in range(max_new_tokens):\n    # ⚠️ 关键问题：每一步都把\"当前全部 token 序列\"重新丢进模型\n    # 第 1 步：算 prompt (比如 20 个 token)\n    # 第 2 步：算 prompt + 第1个新 token (21 个 token)\n    # 第 50 步：算 prompt + 前49个新 token (69 个 token)\n    # → 每轮都在重复计算前面 90% 一模一样的东西！\n\n    with torch.no_grad():\n        outputs = model(input_ids)  # 重算整个序列的所有层\n\n    # 只关心最后一个位置的 logits\n    next_token_logits = outputs.logits[:, -1, :]\n\n    # 选取概率最大的 token\n    probs = torch.softmax(next_token_logits, dim=-1)\n    next_token_id = torch.argmax(probs, dim=-1, keepdim=True)\n\n    # 把新 token 拼回输入，作为下一轮的输入\n    input_ids = torch.cat([input_ids, next_token_id], dim=-1)\n\n    if next_token_id.item() == tokenizer.eos_token_id:\n        break\n\n# 总计算量 ≈ O(prompt_len + 1) + O(prompt_len + 2) + ... + O(prompt_len + N)\n#         = O(N * prompt_len + N²\u002F2)\n# 当 prompt_len 很大（比如 10000 token）时，浪费极其严重\n","python",[1189,1303,1300],{"__ignoreMap":1191},[1106,1305,1306],{},"带上 KV Cache 之后，思路就变成了\"Prefill 一次性把 prompt 算完并缓存，之后 Decode 每步只喂一个新 token 并复用缓存\":",[1182,1308,1311],{"className":1309,"code":1310,"language":1301,"meta":1191},[1299],"import torch\n\nprompt = \"给 user-service 加一个 \u002Fhealthz 接口\"\ninput_ids = tokenizer.encode(prompt, return_tensors=\"pt\")\n\n# Prefill 阶段：一次性处理整个 prompt，缓存所有层的 K\u002FV\nwith torch.no_grad():\n    outputs = model(input_ids, use_cache=True)\n    past_key_values = outputs.past_key_values  # 缓存！每层的 (K, V) 张量\n\nnext_token_logits = outputs.logits[:, -1, :]\nnext_token_id = torch.argmax(torch.softmax(next_token_logits, dim=-1), dim=-1, keepdim=True)\n\n# Decode 阶段：每次只输入 1 个新 token + 复用缓存的 K\u002FV\nfor step in range(max_new_tokens - 1):\n    with torch.no_grad():\n        outputs = model(\n            next_token_id,              # 只输入 1 个 token！\n            past_key_values=past_key_values,  # 复用之前所有的 K\u002FV\n            use_cache=True\n        )\n        past_key_values = outputs.past_key_values  # 更新缓存（追加新 token 的 K\u002FV）\n\n    next_token_logits = outputs.logits[:, -1, :]\n    next_token_id = torch.argmax(torch.softmax(next_token_logits, dim=-1), dim=-1, keepdim=True)\n\n    if next_token_id.item() == tokenizer.eos_token_id:\n        break\n\n# Decode 每步计算量 ≈ O(1 个 token 过所有层) + O(和缓存 K 做 Attention)\n# 相比朴素版，节省了重复计算 prompt 的巨大开销\n",[1189,1312,1310],{"__ignoreMap":1191},[1106,1314,1315],{},"两相对比，结论一目了然：朴素版每步都重算全部，复杂度是 O(N·L)；\nKV Cache 版的 Decode 每步只有 O(L)。当 prompt 达到一万 token 量级时，这中间的差距是万倍级别的。\n这就解释了为什么所有推理服务都离不开 KV Cache，为什么\"保护前缀稳定性\"这件事如此要命——前缀一变，缓存就全废了。",[1101,1317,1319],{"id":1318},"三条约束能带走的结论","三条约束，能带走的结论",[1106,1321,1322],{},"所以三条物理约束各自对应着明确的工程含义和应对策略。自回归逐 token 生成意味着上下文越长、重复计算越多，所以要精简上下文、做治理而非堆砌；KV Cache 追加便宜而修改昂贵，意味着保护前缀稳定性就等于省钱加提速，因此永远是 append 而非 edit 前缀；上下文本身是最贵的资源，窗口有限且注意力会被稀释，应对之道是三段式布局、配合 Compaction 和把记忆外包出去。",[1165,1324],{},[1096,1326,1328],{"id":1327},"上下文工程实战prompt-布局与膨胀对策","上下文工程实战：Prompt 布局与膨胀对策",[1101,1330,1332],{"id":1331},"一次-agent-任务背后-prompt-的五层结构","一次 Agent 任务背后 Prompt 的五层结构",[1106,1334,1335],{},"敲下一句任务指令时，Agent 并不是把你这句话原封不动丢给模型，而是在背后悄悄构造了一整套相当精密的 Prompt 结构。它大致分五层，从稳定到易变排列下来是这样：",[1106,1337,1338,1339,1342,1343,1346,1347,1350,1351,1354,1355,1358],{},"最底层是 ",[1116,1340,1341],{},"System 层","，包含模型服务商的系统提示、Agent 的身份定义和工具能力声明，稳定性极高，可以长期缓存；\n往上是 ",[1116,1344,1345],{},"AGENTS.md 层","，写着技术栈、代码风格、安全边界和团队工作流，稳定性高，适合做项目级缓存；\n再往上是",[1116,1348,1349],{},"项目快照层","，记录当前工作目录、选中文本和项目结构，稳定性居中，做会话级缓存；\n接着是",[1116,1352,1353],{},"会话历史层","，囊括对话记录、工具调用与返回、各种 snapshot 和总结，它稳定性最低、还会持续膨胀，必须主动压缩；\n最后是",[1116,1356,1357],{},"工具定义层","，也就是 MCP 工具清单——名称、说明加 JSON Schema，稳定性高，可以长期缓存。",[1106,1360,1361],{},"这里可以看出上下文绝不是\"越多越好\"，而是要\"把最重要的东西放到最该放的位置\"。位置和占比，直接决定了模型把注意力分配到哪里。",[1101,1363,1365],{"id":1364},"react-循环","ReAct 循环",[1106,1367,1368,1369,1372],{},"Coding Agent 和纯聊天机器人最大的区别，就在于它跑的是一套 ",[1116,1370,1371],{},"ReAct（Reason + Act）循环","。",[1106,1374,1375,1376,1379,1380,1379,1383,1386],{},"这个循环从观察开始：当前的用户输入、历史对话加上工具输出，共同构成了 Agent 眼中的\"世界状态\"。\n接着是思考，模型会在上下文里\"自言自语\"，分析现状、规划下一步该干什么。\n然后进入行动，它调用 ",[1189,1377,1378],{},"read_file()","、",[1189,1381,1382],{},"write_file()",[1189,1384,1385],{},"bash()"," 这类工具去真正影响物理世界。\n行动产生的结果又会被追加回上下文，形成新的观察，从而触发下一轮循环。",[1106,1388,1389],{},"麻烦也正出在这里：每一轮 ReAct 都会往上下文里追加\"思路 + 工具调用 + 工具输出\"这三样东西。Turn 1 时上下文还很短，到 Turn 5 就明显变长，跑到 Turn 20 基本已经爆炸。如果你的工具平均每轮要塞进超过 5000 token，那 Cache 命中率很可能早就崩了。",[1101,1391,1393],{"id":1392},"注意力分布的u-型曲线","注意力分布的「U 型曲线」",[1106,1395,1396,1397,1400,1401,1404,1405,1408],{},"Transformer 在长上下文下的注意力分布，会呈现出一条很有特点的 U 型曲线。",[1116,1398,1399],{},"头部相当于宪法","，这里放着 System Prompt、AGENTS.md 和核心规则，权重最高，扮演着长期记忆的角色;",[1116,1402,1403],{},"中部则容易沦为噪音",",历史对话、日志和那些被废弃的方案都堆在这儿,注意力被严重稀释,很快退化成背景噪声;",[1116,1406,1407],{},"尾部是真正的工作区",",当前任务和关键代码都在这里,模型的决策也主要依赖这一段。",[1106,1410,1411],{},"为什么会形成这样的 U 型？背后有三层原因叠加。一是训练带来的近因偏置，next-token 预测的目标让模型天生就偏爱\"多看最近的东西\";二是位置偏置与信息汇聚效应,多层堆叠之后,开头的 token 会逐渐变成信息的汇聚点;三是序列位置效应,这有点像人背单词列表——开头和结尾总是记得最牢,夹在中间的最容易忘。",[1101,1413,1415],{"id":1414},"记忆的艺术compaction-agentsmd-snapshot","记忆的艺术：Compaction + AGENTS.md + Snapshot",[1106,1417,1418,1419,1422],{},"应对上下文膨胀，第一招是",[1116,1420,1421],{},"主动 Compaction","，也就是在关键节点把状态封装成文件。具体做法是让模型把当前这一长串对话浓缩成一个结构化的 snapshot 文件，写盘之后就把冗长的历史清掉：",[1182,1424,1429],{"className":1425,"code":1427,"language":1428,"meta":1191},[1426],"language-bash","# 让 Agent 总结当前状态并写入文件\nAgent \"请把我们关于支付模块迁移的讨论，总结成 snapshot，写入 docs\u002Fstate\u002Fpayment-migration.md\"\n\n# 后续任务只需读取 snapshot 即可恢复上下文\n# 好处：有价值的中间状态可版本管理、可 review；对话不无限堆积\n","bash",[1189,1430,1427],{"__ignoreMap":1191},[1106,1432,1433,1434,1437],{},"第二招是写好 ",[1116,1435,1436],{},"AGENTS.md","，把它当成项目的\"Prompt 宪法\"。它应该承载那些稳定的长期规则：技术栈与框架选择、代码风格与错误处理约定、安全边界（哪些事坚决不能做）、团队工作流（比如测试优先、commit 规范）。反过来,那些一次性的需求、经常变动的信息、某次重构的临时目标、本周的活动安排,统统不该写进去——它们属于 Spec 或 Plan 文件。",[1106,1439,1440],{},"把这些策略串起来看就四条：让前缀稳定，KV Cache 才好复用；用 Sub Agent、Snapshot、Spec 去替换冗长的历史，对话才不会无限堆积；把 AGENTS.md 里的写法钉死，所有 Agent 才会默认遵守同一部宪法；最后，把记忆外包给文件系统——任何没有落进代码仓库的隐形知识，对 Agent 而言就等于不存在。",[1165,1442],{},[1096,1444,1446],{"id":1445},"给-agent-打造-workspace-的工具设计哲学","给 Agent 打造 Workspace 的工具设计哲学",[1106,1448,1449],{},"工具，直接决定了模型的能力边界。2026年逐渐从给人用的 UI 演化到给 Agent 用的 API，于是就有了快、准、结构化的设计需求",[1101,1451,1453],{"id":1452},"从对人友好到对-agent-可读","从「对人友好」到「对 Agent 可读」",[1106,1455,1456],{},"过去的基础设施，给人准备了大量酷炫的 GUI 和海量的终端日志，可这些东西对模型其实并不友好——模型上下文有限，多模态能力也还不够强。范式转移的方向，是把这一切翻译成模型能用的形态。",[1106,1458,1459],{},"面向鼠标点击的交互，要换成面向自然语言指令的接口;视觉冗余的图表,要换成高信噪比的诊断摘要,结构化输出;酷炫 GUI 和刷屏日志,要换成结构化语义的JSON 和 API,才能更好的和agent进行交互",[1101,1461,1462],{"id":1462},"好工具的三大标准",[1106,1464,1465,1466,1469],{},"第一条标准是",[1116,1467,1468],{},"贴近物理上限、做到秒级响应","。工具必须足够快，否则 Agent 会在等待中\"走神\"——冷启动加上响应都得在秒级完成，慢工具等于让 Agent 注意力涣散。",[1106,1471,1472,1473,1476],{},"第二条标准是",[1116,1474,1475],{},"结构化输出，禁止 PDF 和截图","。工具应当吐出 JSON 或 Markdown，而不是原始日志或图片。当上下文窗口紧张时，结构化的信息能用最少的 token 传达最多的语义。比如一个理想的报错应该长这样：",[1182,1478,1483],{"className":1479,"code":1481,"language":1482,"meta":1191},[1480],"language-json","{\n    \"ok\": false,\n    \"error_type\": \"SyntaxError\",\n    \"file\": \"src\u002Fcomponents\u002FButton.tsx\",\n    \"line\": 42,\n    \"column\": 13,\n    \"message\": \"Unexpected token '}'\",\n    \"suggestion\": \"Check for missing semicolon on line 41\"\n}\n","json",[1189,1484,1481],{"__ignoreMap":1191},[1106,1486,1487,1488,1491,1492,1495,1496,1499],{},"第三条标准是",[1116,1489,1490],{},"痛觉反馈，错误比正确更重要","。错误信息其实是闭环的起点。基于 ReAct 循环，当模型调用工具撞上错误时，一份精确的错误反馈能让它离解决问题更近一步。最烂的返回是 ",[1189,1493,1494],{},"{\"ok\": false, \"error\": \"Something went wrong\"}"," 这种——对人都没用,对模型更是毫无价值;而好的返回会把错误类型、具体信息和修复建议都讲清楚,例如 ",[1189,1497,1498],{},"{\"ok\": false, \"error_type\": \"PermissionDenied\", \"message\": \"No permission to write \u002Fetc\u002Fconfig\", \"suggestion\": \"Ask user to execute manually with sudo\"}",",模型据此就知道下一步该怎么走。",[1101,1501,1503],{"id":1502},"agent-内置工具的能力边界","Agent 内置工具的能力边界",[1106,1505,1506,1507,1510,1511,1514],{},"Coding Agent 的\"物理上限\",其实是被它内置的那几类工具硬生生框死的。**文件读写（File I\u002FO）**负责列目录、读文件、写回和 patch 修改——少了它,Agent 既看不到也改不了代码,等于睁眼瞎,所以这类工具要支持 glob 搜索、增量 patch,还要在文件过大时给出提示。",[1116,1508,1509],{},"受控 Bash\u002FShell","负责执行 npm test、lint、pytest 这类受限命令并返回 stdout\u002Fstderr——少了它,Agent 感知不到\"真实运行结果\",只能凭逻辑空想,因此命令白名单、超时控制、输出截断加摘要都是必需的。",[1116,1512,1513],{},"网络搜索","让 Agent 能查技术文档、API 文档、issue 和论坛——少了它,它对外部世界的认知就停留在训练数据的截止日,所以结果要结构化、要去重、要带上 URL 来源。**WebFetch（HTTP 抓取）**负责拉取 wiki 页面、接口文档和 issue 页面——少了它,Agent 看不到线上文档和真实接口定义,因此要能自动提取正文、去掉导航噪音并支持分页。不给它看 CI 日志的工具，它就只能猜 CI；不给它查监控的工具，它就只能猜服务到底挂在哪。工具决定了模型的物理上限，工具设计得好不好，直接决定了模型能不能摸到这个上限。",[1106,1516,1517],{},"如果按能力层级把工具铺开，会形成一个从基础到高级的矩阵。",[1106,1519,1520],{},"L1 是 File I\u002FO 加 Bash，赋予读写代码和执行命令的能力，是所有 Coding Agent 的标配；",[1106,1522,1523],{},"L2 是 LSP、Lint、TypeCheck 这类感知层工具，让 Agent 能看到语法错误的\"红线\"，典型实现是把 apply_patch 和检查一体化；",[1106,1525,1526],{},"L3 是 Search 加 WebFetch，打通对外部知识和文档的访问，关键是带结构化摘要；",[1106,1528,1529],{},"L4 接入 CI\u002FCD 的状态、日志和部署能力，让 Agent 感知构建和发布状态，往往通过 MCP 接入；",[1106,1531,1532],{},"L5 接入 Metrics、Logs、Traces，让它感知生产环境的健康度，对接 APM 或日志平台；",[1106,1534,1535],{},"L6 则是 Issue、MR、Notification 这类协作工具，让 Agent 真正参与到团队工作流里，通常借助 GitHub 或 GitLab 的 MCP 实现。",[1106,1537,1538],{},"理想中的闭环校验工具应该把\"编辑\"和\"检查\"焊在一起，它的输入输出设计大致是这样：",[1182,1540,1543],{"className":1541,"code":1542,"language":1301,"meta":1191},[1299],"# 理想的闭环校验工具设计\ndef apply_patch_and_check(patch: str, files: list[str]) -> dict:\n    \"\"\"\n    输入：\n      - patch: unified diff 格式的代码补丁\n      - files: 受影响的文件路径列表\n\n    内部流程：\n      1. 应用 patch (git apply \u002F 直接写入)\n      2. 跑一次 tsc --noEmit (TypeScript) 或等价 typecheck\n      3. 跑一次 eslint --format json (Lint)\n      4. 收集 diagnostics\n\n    输出格式：\n    \"\"\"\n    return {\n        \"ok\": True | False,\n        \"patch_applied\": True,\n        \"diagnostics\": [\n            {\n                \"severity\": \"error\",      # error \u002F warning \u002F info\n                \"file\": \"src\u002Fapi\u002Fhealth.ts\",\n                \"line\": 15,\n                \"column\": 8,\n                \"code\": \"TS2322\",\n                \"message\": \"Type 'string' is not assignable to type 'number'\",\n                \"suggestion\": \"Check the return type of getHealthStatus()\"\n            }\n        ],\n        \"summary\": {\n            \"errors\": 1,\n            \"warnings\": 0,\n            \"files_checked\": 3\n        }\n    }\n\n# Agent 拿到这个结果后：\n# - ok=True → 继续下一步（跑测试）\n# - ok=False → 根据 diagnostics 精确定位并修复，而非盲目重试\n",[1189,1544,1542],{"__ignoreMap":1191},[1101,1546,1548],{"id":1547},"健壮性把分页和重试下沉到工具层","健壮性：把分页和重试下沉到工具层",[1106,1550,1551],{},"很多 API 天生带分页。如果你把翻页这件事原样丢给模型让它自己处理，几乎必出问题：上下文一长它就忘了参数，字段名写错、漏传 token 的概率极高，而且常常只看了第一页就急着\"下结论\"。凡是能在工具里做掉的健壮性，就别丢给模型去推理。模型擅长的是理解、归纳、规划和决策；它不擅长的恰恰是 next_page_token、边界条件和重试策略这些琐碎而确定的事。",[1101,1553,1555],{"id":1554},"lspagent-的红线感知器","LSP——Agent 的「红线感知器」",[1106,1557,1558],{},"人写代码靠 IDE 的红色波浪线一眼看出错误。可对 Agent 来说，它只知道\"我刚刚 write_file 了\"，根本看不到语法飘红。",[1106,1560,1561,1562,1565,1566,1569],{},"所以需要LSP能力来将",[1116,1563,1564],{},"编辑和检查做成一体","：Agent 应用 patch 或编辑完文件后，自动触发 ",[1189,1567,1568],{},"tsc --noEmit","、lint 或 typecheck，把 diagnostics（文件、行、列、消息）结构化地收集回来；如果有错误，Agent 就根据这些诊断信息再改一轮，直到没有错误了，才考虑去跑测试。",[1106,1571,1572],{},"收尾时就拿一份自检清单过一遍：这套工具的能力边界是否清楚（文件、bash、搜索、webfetch、LSP、CI 各自能干什么）；它干得稳不稳，分页、重试、超时、默认参数是否都下沉到了工具层；它干完之后说没说清楚，有没有给出成功\u002F失败\u002F错误类型\u002F位置\u002F建议这样的结构化反馈；模型能不能看到结果，LSP、typecheck、lint 有没有把\"红线\"显式暴露出来；以及它知不知道什么时候该问人，遇到权限、风险、歧义类错误时能否引导走 AskUserQuestion。",[1165,1574],{},[1096,1576,1578],{"id":1577},"多智能体架构mcp-skill-sub-agent-的分工与协作","多智能体架构：MCP \u002F Skill \u002F Sub Agent 的分工与协作",[1101,1580,1581],{"id":1581},"三种扩展机制",[1106,1583,1584,1585,1588,1589,1592,1593,1596],{},"扩展 Agent 能力有三套机制，它们的定位截然不同。\n",[1116,1586,1587],{},"MCP 工具","的本质是\"原子动作、常驻上下文\"，一次性挂在上下文里提供基础能力，适合 GitHub、Slack、DB、K8s 这类 API 调用。",[1116,1590,1591],{},"Skill","的本质是\"可执行的 SOP、按需激活\"，只有用到的时候才加载它的 skill.md、渐进式地注入上下文，适合 CI Debug、MR Review、重构流程这种有固定打法的场景。\n",[1116,1594,1595],{},"Sub Agent","的本质则是\"独立的大脑、黑盒外包\"，它完全隔离上下文，只和主 Agent 交换结构化摘要，适合并行探索、方案论证和长篇写作。",[1101,1598,1600],{"id":1599},"mcp扩展模型的手","MCP——扩展模型的「手」",[1106,1602,1603],{},"MCP 的核心，是把工具搬到了模型面前，扩展了它影响物理世界的能力边界。但这件事是有代价的：所有 MCP 工具的 Schema 都得常驻在上下文里、白白占着 token；工具数量一多，模型挑出正确工具的难度就直线上升；而且它只回答\"我能做哪些原子动作\"，并不回答\"这些动作该怎么组合起来用\"。",[1101,1605,1607],{"id":1606},"skill可执行文件夹-sop","Skill——可执行文件夹 + SOP",[1106,1609,1610],{},"Skill 不是一个缩小版的 MCP 工具，而是一整个可以执行的文件夹：",[1182,1612,1615],{"className":1613,"code":1614,"language":1187,"meta":1191},[1185],".claude\u002Fskills\u002Fci-debug\u002F\n  skill.md         # 给模型看的 SOP \u002F 使用说明（按需注入上下文）\n  run.sh           # 真正执行诊断的脚本\n  parse_log.py     # 日志解析脚本\n  examples.md      # 示例输入输出，帮助模型理解用法\n",[1189,1616,1614],{"__ignoreMap":1191},[1106,1618,1619],{},"它的价值在于补上了 MCP 没回答的那个问题。Skill 会告诉模型\"遇到这类问题，该按什么 SOP 去使用这些工具\"；它按需激活，不在主 Agent 的上下文里常驻，用到时才加载，因此能省下上下文窗口；它把领域知识固化成了可执行的流程；而且它可以版本管理、可以审查，也能在团队之间复用。",[1101,1621,1623],{"id":1622},"sub-agent突破单-agent-智能上限","Sub Agent——突破单 Agent 智能上限",[1106,1625,1626],{},"单个 Agent 是有天花板的：上下文一膨胀，注意力就被稀释，智商也跟着被锁死。破局的办法，是把子任务交给独立的 Agent 去干。",[1106,1628,1629],{},"最典型的应用是并行 Explore 模式。主 Agent 先识别出需要探索的三个微服务，然后 spawn 出三个并行的子 Agent，每个只读自己负责的目录、各自维护独立的上下文；子 Agent 在自己的沙盒里疯狂读文件、做内部推理、整理结构，最后各自产出一份结构化的 Summary；主 Agent 只需要读这三份 Summary，就能做出整体决策。",[1106,1631,1632],{},"这背后的核心理念，是用\"结构化通信\"取代\"无脑堆砌\"——Agent 在彼此隔离的沙盒里工作，只交换摘要。这样既物理隔离了噪音，又能交叉验证，从而突破单 Agent 的智能上限。",[1101,1634,1635],{"id":1635},"实战编排",[1106,1637,1638],{},"把三者串起来用，是一套很自然的编排：先用多个 Sub Agent 并行去做 Explore、分析和设计，把结果写进 docs、state 或 spec 文件；再回到主会话里，用 Skill 配合 MCP 工具，按 SOP 执行改动、debug 和检查；在关键的岔路口，则通过 AskUserQuestion 把人拉进来拍板。用架构隔离去对抗长任务的熵增——原子动作、固化打法、并行外包，层层递进。",[1165,1640],{},[1096,1642,1644],{"id":1643},"人机协作与受控执行spec-plan-askuser","人机协作与受控执行：Spec \u002F Plan \u002F AskUser",[1101,1646,1648],{"id":1647},"幻觉的根因训练目标鼓励有话就说","幻觉的根因：训练目标鼓励「有话就说」",[1106,1650,1651],{},"大部分模型在训练时的奖励逻辑很简单：答对得 1 分，答错得 0 分，而\"我不确定\"这种回答极少被当成高分答案。从优化的角度看，这就埋下了祸根。在「不知道」和「猜一个看起来像样的答案」之间，模型从奖励角度更偏向后者。训练目标鼓励「有话就说」，而不是「搞不清楚就先问」—— 这就是幻觉的根源之一。",[1101,1653,1655],{"id":1654},"askuserquestion动手前先问明白","AskUserQuestion——动手前先问明白",[1106,1657,1658],{},"既然根子在系统层缺了一块，解法就是把\"问人\"本身做成一个工具，在系统层把它补上。",[1106,1660,1661],{},"那么什么时候该放手让 Agent 自己跑，什么时候该第一轮就问人？判断的分界其实很清楚。当 Spec 足够明确、有闭环验证，工具能力覆盖完整，而且失败可以自动回退时，就放手让它跑；反过来，一旦意图模糊、存在多条可走的路径，或者环境信息不足、又或者牵涉到不可逆的操作，那就别犹豫，第一轮就该向人求助。",[1106,1663,1664],{},"好的工具链让 Agent 清楚地知道自己能做什么、不能做什么——这本身就是一种 Harness。不确定就问人，是一个被鼓励的正确行为，而不是无能的表现。",[1101,1666,1668],{"id":1667},"spec-kit用结构化需求压缩概率空间","Spec Kit——用结构化需求压缩概率空间",[1106,1670,1671],{},"直接丢给 Agent 一句\"写一个贪吃蛇游戏\"，它就得去猜平台、猜技术栈、猜控制方式、猜功能范围……熵高得离谱。正确的做法，是先通过几轮问答，把模糊的需求捏成一份结构化的 Spec：",[1182,1673,1678],{"className":1674,"code":1676,"language":1677,"meta":1191},[1675],"language-yaml","# 项目基本信息\nname: \"Snake Game\"\nversion: \"1.0.0\"\nauthor: \"auto-generated via Agent + Human review\"\n\n# 技术选型（消除 Agent 猜测空间）\nproject_type: \"web\"\nlanguage: \"TypeScript\"\nframework: \"React\"\nrendering: \"Canvas 2D\"\nbuild_tool: \"Vite\"\npackage_manager: \"pnpm\"\n\n# 游戏配置\ngrid:\n    rows: 20\n    cols: 20\n    cell_size_px: 25\n\n# 操控方式\ncontrol_scheme: \"WASD\" # 备选: \"arrow_keys\" | \"swipe\" (mobile)\ntouch_support: false\n\n# 游戏机制\nspeed:\n    initial: \"medium\" # 初始速度\n    acceleration: true # 是否随分数加速\n    max_speed_multiplier: 2.5 # 最大加速倍率\n\n# 功能清单（每一项都是明确的 Yes\u002FNo）\nfeatures:\n    - id: \"score-board\"\n      description: \"右上角实时显示当前分数和历史最高分\"\n      priority: \"P0\"\n    - id: \"pause\"\n      description: \"按 Space 暂停\u002F恢复，暂停时显示半透明遮罩\"\n      priority: \"P0\"\n    - id: \"auto-restart\"\n      description: \"死亡后 3 秒自动重新开始，显示最终分数\"\n      priority: \"P0\"\n    - id: \"food-types\"\n      description: \"普通食物 +1 分，金色食物 +5 分（10% 概率刷新）\"\n      priority: \"P1\"\n    - id: \"wall-mode\"\n      description: \"碰墙死亡（非穿越模式）\"\n      priority: \"P0\"\n\n# 验证标准（Agent 自动化测试的依据）\nsuccess_criteria:\n    - \"蛇能正常移动，方向切换无延迟\"\n    - \"吃到食物后蛇身增长 1 格\"\n    - \"碰墙或咬到自己时游戏结束\"\n    - \"分数正确累加并持久化到 localStorage\"\n    - \"暂停\u002F恢复功能正常\"\n    - \"Canvas 在 60fps 下无明显卡顿\"\n\n# 不做的事情（明确边界，防止 Agent 过度发挥）\nout_of_scope:\n    - \"多人模式\"\n    - \"关卡系统\"\n    - \"皮肤商店\"\n    - \"移动端适配\"\n    - \"音效\"\n\n# 目录结构约定\ndirectory_structure:\n    src\u002F: \"源代码\"\n    src\u002Fcomponents\u002F: \"React 组件\"\n    src\u002Fgame\u002F: \"游戏核心逻辑（纯函数，不依赖 React）\"\n    src\u002Fhooks\u002F: \"自定义 Hooks\"\n    src\u002Ftypes\u002F: \"TypeScript 类型定义\"\n    tests\u002F: \"Vitest 单元测试\"\n","yaml",[1189,1679,1676],{"__ignoreMap":1191},[1106,1681,1682],{},"有了这份 Spec，后续所有任务都指向它。每次构造 Prompt 时，Agent 都会把 Spec 读进来当作约束：",[1182,1684,1687],{"className":1685,"code":1686,"language":1428,"meta":1191},[1426],"# 每次构造 Prompt 时，Agent 会读入 Spec 作为约束\nAgent \"根据 specs\u002Fsnake-game.yaml，实现核心渲染和键盘控制逻辑\"\n\n# Agent 在一个「已约束好的实现空间」里搜索，而不是凭空想象\n# 不确定的点（Spec 里没写的），会触发 AskUserQuestion\n",[1189,1688,1686],{"__ignoreMap":1191},[1106,1690,1691],{},"Spec 和 AskUserQuestion 是天生一对：Spec 负责把不确定项显式地暴露出来，AskUserQuestion 负责在关键字段填不满时向你要真相，然后所有的实现、测试、文档生成都基于这份 Spec 展开。幻觉空间就这样被结构化约束硬生生压掉了一大块。",[1106,1693,1694,1695,1698,1699,1702],{},"再往上抽象一层，Spec 和 Plan 各管一头。",[1116,1696,1697],{},"Spec（规格说明书）回答\"做成什么样\"","——输入输出的 Schema、副作用的边界、验证通过的标准;",[1116,1700,1701],{},"Plan（执行计划）回答\"怎么做\"","——多步任务的拆解、关键检查点、失败时的回退策略。一句话:Spec 答 What,Plan 答 How,不确定时就在第一轮向人求助,而不是猜错之后白白浪费二十轮。",[1101,1704,1706],{"id":1705},"plan-模式","Plan 模式",[1106,1708,1709,1710,1712,1713,1716,1717,1720],{},"与其让 Agent 一头扎进迷雾里乱撞，不如分三步走。先进入 ",[1116,1711,1706],{},"，让它把局面看清楚——\"列出适合今天做的任务\"\"写一份小 RFC\";再让",[1116,1714,1715],{},"人类审阅",",在 RFC 或 Plan 这一层做修改和确认;最后切到 ",[1116,1718,1719],{},"Execute 模式",",确认无误后再让 Agent 照着 Plan 动手实现。这样做的好处,是在 Spec 和 RFC 层就把歧义消灭掉,让意图沉淀成一份可复用的文件,而不是飘在对话里随时可能走样。",[1101,1722,1724],{"id":1723},"端到端闭环从-review-代码到-review-交付物","端到端闭环：从 Review 代码到 Review 交付物",[1106,1726,1727],{},"这里有一个关键转变：人的注意力是有限的，而 Agent 的注意力近乎无限。所以不要再去逐行 Review 代码，而要去 Review 交付产物——单测有没有覆盖关键 Case？上线之后稳不稳？",[1106,1729,1730],{},"理想的 AI 自迭代闭环是这样运转的：以自然语言描述需求作为输入；Agent 理解需求后自动定位并修改代码；接着调用内置的测试 Skill，在沙盒里自动化自测验证；最后自动沉淀出交付文档——变更说明、前后对比、测试报告。人到最后只需要审阅三件事：到底改了什么、前后对比如何、又增加了哪些测试来确保稳定。",[1165,1732],{},[1096,1734,1736],{"id":1735},"构建可复用工作流从-claude-到插件化","构建可复用工作流：从 .claude\u002F 到插件化",[1101,1738,1740],{"id":1739},"用-claude-描述你的-agent-系统","用 .claude\u002F 描述你的 Agent 系统",[1106,1742,1743],{},"要把零散的能力沉淀成体系，可以在项目里约定一个配置目录，把所有 Agent、Skill、Command 编排进去：",[1182,1745,1748],{"className":1746,"code":1747,"language":1187,"meta":1191},[1185],".claude\u002F\n  agents\u002F\n    planner.yaml        # 规划 Agent：写 Spec\u002FRFC\u002FPlan\n    worker.yaml         # 执行 Agent：按 Plan 实现代码\n    reviewer.yaml       # 审查 Agent：检查质量与安全\n  skills\u002F\n    ci-debug\u002F           # CI 诊断 SOP\n    generate-tests\u002F     # 自动生成测试\n    refactor-module\u002F    # 模块重构流程\n  commands\u002F\n    migrate-payment.yaml  # 支付迁移全流程\n    fix-issue.yaml        # 根据 Issue ID 修 Bug\n",[1189,1749,1747],{"__ignoreMap":1191},[1101,1751,1753],{"id":1752},"commands-串联多-agent","Commands 串联多 Agent",[1106,1755,1756],{},"一条 Command 就能编排出一整套完整的工作流：先调 Planner Agent 生成或更新 Plan，再 spawn 多个 Sub Agent 并行去 Explore 旧系统，接着用 Worker Agent 按 Plan 执行迁移，然后让 Reviewer Agent 做质量审查，关键步骤再通过 AskUserQuestion 把人拉进来确认。最终呈现给你的，就是一句话的事：",[1182,1758,1761],{"className":1759,"code":1760,"language":1428,"meta":1191},[1426],"claude \"migrate-payment 从旧网关迁到 v2 网关\"\n# 背后执行的是你设计好的整套工作流，而不是「临时拍脑袋的 prompt」\n",[1189,1762,1760],{"__ignoreMap":1191},[1101,1764,1766],{"id":1765},"打包为团队级预设-插件","打包为团队级预设 \u002F 插件",[1106,1768,1769,1770,1773],{},"当你把 AGENTS 宪法、成熟的 Agent 配置、若干 Skill 和一批 Commands 都打磨成型之后，就可以把整个 ",[1189,1771,1772],{},".claude\u002F"," 打包成模板或插件，放到团队内部、甚至公开的\"市场\"里，让其他项目一键安装、直接复用整套工作流。这一步完成的转变意味深远——从\"每个人自己写 prompt、自己踩坑\",走向\"团队和社区沉淀出一套 Agent 系统,大家一键复用\"。",[1101,1775,1777],{"id":1776},"ai-native-工具的代表midscenejs","AI Native 工具的代表：Midscene.js",[1106,1779,1780],{},"传统的网页操作，是让 Agent 去模仿人类：获取 DOM 树、解析截图、定位元素、模拟点击。活还没真正开始干，光这一套下来上下文就已经消耗了三四万 token。",[1106,1782,1783],{},"AI Native 的解法完全换了思路：让 Agent 直接用自然语言描述意图——\"点击登录按钮\"\"验证购物车里有 3 件商品\"——工具原生地去理解并执行，自主定位、自动适配、自愈重试。两种方式的差距很直观:传统方式要获取几千行的 DOM 结构、靠截图识别吃掉大量 token、做易错的坐标计算、再脆弱地模拟点击;而 AI Native 方式既不获取 DOM,也不截图,更不模拟人类操作,自然语言本身就是操控接口。",[1220,1785,1786],{},[1106,1787,1788],{},"好的 Harness，就是为 Agent 量身打造 Native 工具。Token 大幅下降，效果大幅提升。",[1165,1790],{},[1096,1792,1793],{"id":1793},"总结",[1101,1795,1796],{"id":1796},"从底层到应用",[1106,1798,1799],{},"主要有七层",[1106,1801,1802,1805],{},[1116,1803,1804],{},"L1 模型物理层","是 Transformer 自回归，逐 token 生成是物理铁律，对策是精简上下文、治理而非堆砌;",[1106,1807,1808,1811],{},[1116,1809,1810],{},"L2 推理优化层","是 KV Cache 与 Prompt Cache,追加便宜、修改昂贵,要靠保护前缀稳定性来降本九成;",[1106,1813,1814,1817],{},[1116,1815,1816],{},"L3 上下文工程层","讲 Prompt 布局与 Compaction,记住头部是宪法、尾部是工作区、中部是噪音,落地手段是 AGENTS.md 加 Snapshot 加文件系统外包;",[1106,1819,1820,1823],{},[1116,1821,1822],{},"L4 工具设计层","是 Agent 可读性,工具要结构化、秒级、有痛觉反馈,配合 LSP 闭环、自动分页和错误建议;",[1106,1825,1826,1829],{},[1116,1827,1828],{},"L5 协作架构层","是 MCP、Skill、Sub Agent 的\"原子→SOP→并行外包\"三级,用隔离上下文来对抗熵增;",[1106,1831,1832,1835],{},[1116,1833,1834],{},"L6 人机交互层","是 Spec、Plan、AskUser,谋定而后动、不确定就问,Spec 答 What、Plan 答 How;最顶上的",[1106,1837,1838,1841],{},[1116,1839,1840],{},"L7 工作流层","则是把 .claude\u002F 配置化,让经验沉淀成可执行的工作流,通过 Commands、插件市场实现团队复用。",[1101,1843,1845],{"id":1844},"ai-时代的研发","AI 时代的研发",[1106,1847,1848],{},"Harness Engineering 的工作就是为 AI 提供工具、上下文和反馈,编写代码本身的价值在急速下降,而设计 Agent 工作环境的价值在急速上升。个人认为从编码者到驾驭模型，为模型提供上下文，为代码质量负责的 Builder，是将来一段时间内程序员的很大的转变",[1106,1850,1851],{},"模型说到底只是一个巨大的函数,于是我们需要摸清 Transformer 自回归、KV Cache、Prompt Cache 这些边界,越是封装就越要弄明白其过程，而不是控制黑盒输入输出",[1106,1853,1854],{},"模型能在多大程度上影响现实,取决于你给它什么状态、什么工具,精准的工具加上结构化的上下文,让模型与我们的物理世界交互，才能更好的进行落地",[1106,1856,1857],{},"时间是稀缺资源**,人的时间永远是最稀缺的,把验证、测试、文档这些繁琐活交给 AI,才能把人的创造力释放到决策和设计上去（虽然现在资本家都偏向于裁掉一半研发序列让剩下的干两倍活）",[1101,1859,1861],{"id":1860},"agentsmd-模板","AGENTS.md 模板",[1182,1863,1868],{"className":1864,"code":1866,"language":1867,"meta":1191},[1865],"language-markdown","# AGENTS.md — 项目 Agent 宪法\n\n## 项目概述\n\n- **项目名称**: [你的项目名]\n- **技术栈**: TypeScript \u002F React 18 \u002F Node.js 20 \u002F PostgreSQL\n- **包管理器**: pnpm (严禁使用 npm \u002F yarn)\n- **构建工具**: Vite 5.x\n- **测试框架**: Vitest + React Testing Library\n- **代码风格**: ESLint (airbnb-typescript) + Prettier\n\n## 代码规范\n\n### 命名约定\n\n- 组件: PascalCase (`UserProfile.tsx`)\n- 工具函数: camelCase (`formatDate.ts`)\n- 常量: SCREAMING_SNAKE_CASE\n- 类型\u002F接口: PascalCase, 接口不加 I 前缀\n- 测试文件: `*.test.ts` \u002F `*.spec.ts`\n\n### 错误处理\n\n- 所有 async 函数必须 try-catch，禁止 unhandled rejection\n- 错误必须结构化: `{ code, message, context }`\n- 面向用户的错误信息必须友好且可操作\n- 日志使用 `logger.error()` 不用 `console.error()`\n\n### 文件组织\n\n- 每个文件单一职责，不超过 300 行\n- 公共逻辑提取到 `src\u002Futils\u002F` 或 `src\u002Fshared\u002F`\n- 业务逻辑与 UI 分离（hooks \u002F services \u002F components）\n\n## 安全边界（禁止做的事情）\n\n### 绝对禁止\n\n- ❌ 删除 `migrations\u002F` 目录下的任何文件\n- ❌ 修改 `.env.production` 或任何生产环境配置\n- ❌ 执行 `rm -rf`、`DROP TABLE`、`TRUNCATE` 等破坏性命令\n- ❌ 在代码中硬编码密钥、token、密码\n- ❌ 绕过 TypeScript 类型检查 (禁止 `@ts-ignore`，`as any` 需注释原因)\n\n### 需要确认才能做\n\n- ⚠️ 修改数据库 schema (migration)\n- ⚠️ 修改公共 API 的入参\u002F出参\n- ⚠️ 升级主要依赖版本 (major version)\n- ⚠️ 修改 CI\u002FCD 配置\n\n## 工作流程\n\n### 开发流程\n\n1. 先写测试（或至少先写测试骨架）\n2. 实现功能\n3. 跑 `pnpm lint` + `pnpm typecheck` 确认无错误\n4. 跑 `pnpm test` 确认测试通过\n5. 写有意义的 commit message (Conventional Commits)\n\n### Commit 规范\n\n- `feat:` 新功能\n- `fix:` 修复 bug\n- `refactor:` 重构（不改变行为）\n- `test:` 测试相关\n- `docs:` 文档\n- `chore:` 构建\u002F工具链\n\n### 不确定时的行为\n\n- 如果需求不明确 → AskUserQuestion，不要猜\n- 如果有多种实现方案 → 列出 2-3 个方案的 tradeoff，让人选\n- 如果涉及安全边界 → 必须确认，不要自行决定\n- 如果改动范围超过 5 个文件 → 先写 Plan 让人确认\n\n## 常用命令\n\n```bash\npnpm dev          # 启动开发服务器\npnpm build        # 构建生产版本\npnpm test         # 运行测试\npnpm lint         # Lint 检查\npnpm typecheck    # TypeScript 类型检查\npnpm db:migrate   # 运行数据库迁移\n```\n","markdown",[1189,1869,1866],{"__ignoreMap":1191},[1106,1871,1872,1873,1875,1876,1879,1880,1883,1884,1887],{},"对于大型项目，AGENTS.md 还可以按角色分层管理。根目录的 ",[1189,1874,1436],{}," 是全局宪法,写技术栈、安全边界和通用规范;",[1189,1877,1878],{},"src\u002Fapi\u002FAGENTS.md"," 作用于后端 API 层,写路由规范、中间件约定和错误码标准;",[1189,1881,1882],{},"src\u002Fcomponents\u002FAGENTS.md"," 管前端组件层,写组件设计规范、Props 命名和状态管理;",[1189,1885,1886],{},"tests\u002FAGENTS.md"," 则管测试层,写测试命名、mock 策略和覆盖率要求。这里有个关键原则:AGENTS.md 会被自动放到 Prompt 最前面、不会被压缩或总结,所有 Agent 默认遵守,所以它装的应该是\"稳定的长期规则\"而非\"临时性目标\"——一次性需求请放进 Spec 或 Plan 文件。",[1101,1889,1891],{"id":1890},"skill-模板","Skill 模板",[1106,1893,1894],{},"一个完整的 Skill 目录长这样：",[1182,1896,1899],{"className":1897,"code":1898,"language":1187,"meta":1191},[1185],".claude\u002Fskills\u002Fci-debug\u002F\n│\n├── skill.md              # [必须] Skill 说明文档 — 模型按需读取\n├── run.sh                # [推荐] 主执行脚本\n├── parse_log.py          # [可选] 辅助脚本\n├── examples.md           # [推荐] 示例输入输出\n└── config.yaml           # [可选] Skill 元配置\n",[1189,1900,1898],{"__ignoreMap":1191},[1106,1902,1903],{},"其中最核心的 skill.md 可以参照下面的模板来写：",[1182,1905,1908],{"className":1906,"code":1907,"language":1867,"meta":1191},[1865],"# CI Debug Skill\n\n## 何时使用\n\n当 CI\u002FCD pipeline 失败时，使用本 Skill 诊断问题根因。\n\n## 前置条件\n\n- 需要 MR 编号或 Pipeline URL\n- 需要 `bash` 和 `webfetch` 工具可用\n\n## 执行步骤\n\n### Step 1: 获取 Pipeline 状态\n\n```bash\n.\u002Frun.sh status \u003Cpipeline_url>\n```\n\n输出: JSON 格式的 job 列表及状态\n\n### Step 2: 定位失败 Job\n\n从 Step 1 输出中找到 status=failed 的 job\n\n### Step 3: 拉取关键日志\n\n```bash\n.\u002Frun.sh logs \u003Cjob_id> --tail 200\n```\n\n输出: 最后 200 行日志\n\n### Step 4: 分析错误\n\n根据日志内容分析根因。常见模式:\n\n- `ENOMEM` → 内存不足，检查资源限制\n- `exit code 137` → OOM Killed\n- `timeout` → 执行超时，检查是否有死循环\n- `permission denied` → 权限问题，检查 CI 变量\n\n### Step 5: 给出修复建议\n\n基于分析结果，给出具体的修复建议。\n如果不确定根因 → 调用 AskUserQuestion 问人。\n\n## 注意事项\n\n- 本 Skill 仅做诊断，不直接修改代码\n- 涉及 secret\u002Ftoken 的日志行自动脱敏\n- 如果 3 轮分析仍无法定位，请求人工介入\n",[1189,1909,1907],{"__ignoreMap":1191},[1101,1911,1912],{"id":1912},"后续行动",[1106,1914,1915],{},"其实实践这一套方法论也不难：\n在项目根目录建一份 AGENTS.md，写清技术栈、代码风格和安全边界；凡是重复了三次以上的流程，就为它建一个 Skill 文件夹（CI debug、MR review、重构 SOP 都是好候选）",[1106,1917,1918],{},"给关键工具加上结构化的错误返回，至少包含 error_type、file、line 和 suggestion；在 Agent 工作流里接入 LSP 和 Lint 闭环，让编辑之后自动 typecheck；",[1106,1920,1921],{},"用 Spec 和 Plan 模式取代\"直接让 Agent 干活\"，先 RFC 再实现；把 AskUserQuestion 的策略写进 AGENTS.md，明确\"不确定就问人\"；\n对那些超过二十轮的长任务，用 Sub Agent 做上下文隔离；并且定期做主动 Compaction，把冗长的对话浓缩成 Snapshot 文件。",[1106,1923,1924],{},"关于这一块也没有什么最佳实践和SOP,所以最后的最后，具体的场景还是要看具体的解决方案会好些",{"title":1191,"searchDepth":1926,"depth":1926,"links":1927},4,[1928,1934,1942,1948,1955,1962,1969,1975],{"id":1098,"depth":1929,"text":1099,"children":1930},2,[1931,1933],{"id":1103,"depth":1932,"text":1104},3,{"id":1122,"depth":1932,"text":1123},{"id":1169,"depth":1929,"text":1170,"children":1935},[1936,1937,1938,1939,1940,1941],{"id":1176,"depth":1932,"text":1177},{"id":1200,"depth":1932,"text":1201},{"id":1227,"depth":1932,"text":1228},{"id":1249,"depth":1932,"text":1250},{"id":1294,"depth":1932,"text":1295},{"id":1318,"depth":1932,"text":1319},{"id":1327,"depth":1929,"text":1328,"children":1943},[1944,1945,1946,1947],{"id":1331,"depth":1932,"text":1332},{"id":1364,"depth":1932,"text":1365},{"id":1392,"depth":1932,"text":1393},{"id":1414,"depth":1932,"text":1415},{"id":1445,"depth":1929,"text":1446,"children":1949},[1950,1951,1952,1953,1954],{"id":1452,"depth":1932,"text":1453},{"id":1462,"depth":1932,"text":1462},{"id":1502,"depth":1932,"text":1503},{"id":1547,"depth":1932,"text":1548},{"id":1554,"depth":1932,"text":1555},{"id":1577,"depth":1929,"text":1578,"children":1956},[1957,1958,1959,1960,1961],{"id":1581,"depth":1932,"text":1581},{"id":1599,"depth":1932,"text":1600},{"id":1606,"depth":1932,"text":1607},{"id":1622,"depth":1932,"text":1623},{"id":1635,"depth":1932,"text":1635},{"id":1643,"depth":1929,"text":1644,"children":1963},[1964,1965,1966,1967,1968],{"id":1647,"depth":1932,"text":1648},{"id":1654,"depth":1932,"text":1655},{"id":1667,"depth":1932,"text":1668},{"id":1705,"depth":1932,"text":1706},{"id":1723,"depth":1932,"text":1724},{"id":1735,"depth":1929,"text":1736,"children":1970},[1971,1972,1973,1974],{"id":1739,"depth":1932,"text":1740},{"id":1752,"depth":1932,"text":1753},{"id":1765,"depth":1932,"text":1766},{"id":1776,"depth":1932,"text":1777},{"id":1793,"depth":1929,"text":1793,"children":1976},[1977,1978,1979,1980,1981],{"id":1796,"depth":1932,"text":1796},{"id":1844,"depth":1932,"text":1845},{"id":1860,"depth":1932,"text":1861},{"id":1890,"depth":1932,"text":1891},{"id":1912,"depth":1932,"text":1912},"https:\u002F\u002Fpicx.zhimg.com\u002F80\u002Fv2-d775deb465a9936f4e7b3f0098982c3b_720w.webp?source=d16d100b","随着llm的发展，程序员的角色正在发生转变：不再是逐行敲代码的执行者，而是负责给出方向、保障代码质量、指挥模型干活的 \"Builder\"","md",true,{"uuid":1987,"slots":1988},"b8d70910-c4f4-11f0-83bd-25018b9748b8",{},29,{"title":1085,"description":1983},"posts\u002F2026\u002F2026-06-13-从上下文工程到 Agent Harness Engineering",[273,274,275],"_bzN6SDS02TJzTH5arUQ1oOuMMuS2Zb5NNTa-efCQpY",1790443284283]