[{"data":1,"prerenderedAt":2983},["ShallowReactive",2],{"blog-taxonomies":3,"blog-stats":507,"post-rfc_agentic_project\u002F2026-07-25-rfc-glushkov_ogas":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":156,"body":1086,"category":5,"cover":1670,"date":156,"description":2971,"extension":2972,"mathjax":2973,"meta":2974,"navigation":2973,"path":795,"published":797,"readingMinutes":2978,"seo":2979,"stem":2980,"sticky":156,"swiper_index":156,"tags":2981,"updated":156,"words":796,"__hash__":2982},"posts\u002Fposts\u002FRFC_Agentic_project\u002F2026-07-25-[RFC]-Glushkov_OGAS.md","2026-07-25-[RFC]-Glushkov_OGAS",{"type":1087,"value":1088,"toc":2891},"minimark",[1089,1094,1101,1106,1111,1114,1118,1121,1124,1127,1133,1220,1222,1225,1228,1233,1260,1275,1296,1304,1308,1323,1327,1347,1349,1352,1356,1359,1362,1365,1368,1372,1375,1403,1407,1410,1436,1438,1441,1444,1448,1455,1490,1496,1502,1506,1515,1521,1526,1530,1553,1558,1563,1567,1582,1592,1597,1601,1604,1650,1653,1655,1658,1664,1671,1675,1678,1681,1685,1692,1695,1699,1702,1709,1716,1720,1730,1736,1755,1758,1762,1768,1771,1787,1793,1797,1800,1803,1806,1808,1811,1814,1817,1821,1824,1850,1856,1860,1865,1868,1872,1875,1878,1895,1913,1916,1925,1928,1931,1937,1941,1946,1949,1955,1958,1961,1986,1989,1996,2001,2015,2020,2034,2037,2040,2045,2058,2063,2070,2077,2082,2085,2104,2109,2112,2116,2121,2124,2128,2131,2145,2148,2152,2155,2160,2174,2179,2196,2199,2202,2205,2225,2228,2232,2237,2240,2243,2252,2258,2261,2270,2273,2276,2279,2282,2308,2311,2321,2324,2327,2330,2336,2348,2351,2354,2360,2373,2376,2380,2383,2386,2447,2453,2459,2462,2469,2473,2478,2481,2487,2501,2505,2517,2521,2524,2527,2530,2533,2536,2549,2552,2555,2558,2560,2563,2566,2569,2573,2579,2595,2601,2607,2611,2616,2621,2626,2634,2638,2643,2648,2653,2658,2660,2663,2667,2670,2679,2685,2695,2698,2705,2708,2711,2714,2717,2720,2731,2735,2738,2740,2744],[1090,1091,1093],"h1",{"id":1092},"rfc-0802-ogas-operational-generate-agent-system","RFC-0802: OGAS (Operational Generate Agent System)",[1095,1096,1097],"blockquote",{},[1098,1099,1100],"p",{},"项目 Glushkov ── OGAS, Operational Generate Agent System",[1095,1102,1103],{},[1098,1104,1105],{},"状态 Draft",[1095,1107,1108],{},[1098,1109,1110],{},"关联材料 项目 specs(monorepo\u002Fspec 规范)、ADR-0001~0004",[1112,1113],"hr",{},[1115,1116,1117],"h2",{"id":1117},"概述",[1098,1119,1120],{},"OGAS（Operational Generate Agent System，以下简称 OGAS）是一个自托管的 Agent 研发生命周期协作平台。它让整个团队能以受控、可编排、可回滚的方式驱动 Agent，从一个需求的知识检索，一路自动推进到代码交付和线上部署。",[1098,1122,1123],{},"当前研发链路中的痛点集中在三处：单个编码 Agent 虽然好用，但它只是\"某个人在自己机器上跑的一个 loop\"，团队其他人无法 review 执行链路；多个任务之间有先后依赖，但没有编排机制将它们串联起来自动执行；从代码到部署之间，评审、CI、部署这些可验证环节仍靠人肉衔接，没有形成闭环。OGAS 正是为了打通这三个缺口而设计的。",[1098,1125,1126],{},"OGAS 由五个组件构成，分别覆盖入口、编排、控制、执行和能力五个层面：",[1098,1128,1129],{},[1130,1131,1132],"strong",{},"OGAS 组件总览",[1134,1135,1136,1152],"table",{},[1137,1138,1139],"thead",{},[1140,1141,1142,1146,1149],"tr",{},[1143,1144,1145],"th",{},"OGAS 组件",[1143,1147,1148],{},"角色",[1143,1150,1151],{},"底层\u002F来源",[1153,1154,1155,1169,1181,1194,1207],"tbody",{},[1140,1156,1157,1163,1166],{},[1158,1159,1160],"td",{},[1130,1161,1162],{},"OGAS-Gate",[1158,1164,1165],{},"入口面：飞书机器人适配服务",[1158,1167,1168],{},"自研",[1140,1170,1171,1176,1179],{},[1158,1172,1173],{},[1130,1174,1175],{},"OGAS-Flow",[1158,1177,1178],{},"编排面：跨任务 DAG 依赖调度",[1158,1180,1168],{},[1140,1182,1183,1188,1191],{},[1158,1184,1185],{},[1130,1186,1187],{},"OGAS-Dispatcher",[1158,1189,1190],{},"控制面：任务队列、状态机、WebSocket 枢纽、开发机守护进程",[1158,1192,1193],{},"上游 Multica",[1140,1195,1196,1201,1204],{},[1158,1197,1198],{},[1130,1199,1200],{},"Liskin_Agent",[1158,1202,1203],{},"执行面：编码 Agent 内核",[1158,1205,1206],{},"上游 Liskin_Agent",[1140,1208,1209,1214,1217],{},[1158,1210,1211],{},[1130,1212,1213],{},"OGAS-Arkhiv",[1158,1215,1216],{},"知识面：业务知识库 MCP Server",[1158,1218,1219],{},"上游 EagleRAG",[1112,1221],{},[1115,1223,1224],{"id":1224},"背景与问题",[1098,1226,1227],{},"研发链路中的痛点可以分三层来看，分别对应 Agent 的能力边界、团队协作方式和链路打通程度。",[1229,1230,1232],"h3",{"id":1231},"_11-执行面单个编码-agent-的能力边界","1.1 执行面：单个编码 Agent 的能力边界",[1098,1234,1235,1236,1243,1244,1249,1250,1255,1256],{},"通用编码 Agent 在大型代码库上会暴露出一组相似的问题。模型本身足够聪明，但它拿不到正确的上下文——要么一次读入太多文件导致判断分散，要么模块边界和领域术语只能靠猜测推进，搜索过程中又充满噪音",[1237,1238,1242],"a",{"href":1239,"rel":1240},"https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F2043016346271839700",[1241],"nofollow","[1]","。Coding Agent 的大多数演示是从零搭建一个简单的 Todo 类应用，而真实代码库往往是\"有十五年历史、充满未文档化的隐性契约、蔓延到四十个文件的服务层\"",[1237,1245,1248],{"href":1246,"rel":1247},"https:\u002F\u002Ftianpan.co\u002Fzh\u002Fblog\u002F2026-04-19-ai-coding-agents-brownfield-legacy-code",[1241],"[2]","。Anthropic 提出的方向是让\"代码库适配 AI\"而不是只靠模型",[1237,1251,1254],{"href":1252,"rel":1253},"https:\u002F\u002Fdeveloper.aliyun.com\u002Farticle\u002F1737453",[1241],"[3]","，但在长期迭代、历史包袱重的大型仓库中，我们更需要一种让 AI Agent 主动适应现有代码的方案（这一点在作者博客中有过专门论述 ",[1237,1257,1258],{"href":1258,"rel":1259},"https:\u002F\u002Fzhongye1.github.io\u002Fp\u002Ff77cee45\u002F",[1241],[1098,1261,1262,1263,1268,1269,1274],{},"生成代码的质量同样堪忧。AI 可能引用不存在的函数、使用想象出来的 API、或者写出语法正确但逻辑错误的代码",[1237,1264,1267],{"href":1265,"rel":1266},"https:\u002F\u002Farxiv.org\u002Fhtml\u002F2404.00971v3",[1241],"[4]","。业界常见的做法叫\"给 AI 制定 coding guidelines\"，把团队规范做成 spec 喂给 Agent",[1237,1270,1273],{"href":1271,"rel":1272},"https:\u002F\u002Fblog.jetbrains.com\u002Fidea\u002F2025\u002F05\u002Fcoding-guidelines-for-your-ai-agents\u002F",[1241],"[5]","。我们要做的是把这套方法论内化到 Agent 内核中，而不是外挂一份规范文档了事。",[1098,1276,1277,1278,1283,1284,1289,1290,1295],{},"复杂任务的长程执行是另一个难题。Agent 容易出现上下文腐烂（context rot）和跑偏（drift）：前 20 个回合一切正常，到第 40 个回合 Agent 开始改不该改的文件、重复调用失败的工具、甚至忘了最初要解决什么问题",[1237,1279,1282],{"href":1280,"rel":1281},"https:\u002F\u002Fwww.tinyash.com\u002Fblog\u002Fmindlas-ai-agent-drift-problem\u002F",[1241],"[6]","。长上下文压缩也可能导致任务链断裂",[1237,1285,1288],{"href":1286,"rel":1287},"https:\u002F\u002Fwww.80aj.com\u002F2026\u002F07\u002F23\u002Fai-agent-context-compression\u002F",[1241],"[7]","。针对这些问题，需要为长任务 Agent 设计有效的 harness",[1237,1291,1294],{"href":1292,"rel":1293},"https:\u002F\u002Fwww.anthropic.com\u002Fengineering\u002Feffective-harnesses-for-long-running-agents",[1241],"[8]","。",[1098,1297,1298,1299,1295],{},"最后是质量反馈的缺失。当前阶段仍存在\"AI 信任鸿沟\"——开发者希望以最少的人工审查将 AI 生成代码部署到生产，但 Agent 的运行过程和最终结果都缺乏科学、客观的质量评估",[1237,1300,1303],{"href":1301,"rel":1302},"https:\u002F\u002Fstackoverflow.blog\u002F2026\u002F02\u002F18\u002Fclosing-the-developer-ai-trust-gap\u002F",[1241],"[9]",[1229,1305,1307],{"id":1306},"_12-协作面agent-高自主性带来的团队可见性缺失","1.2 协作面：Agent 高自主性带来的团队可见性缺失",[1098,1309,1310,1311,1316,1317,1322],{},"Agent 的高自主性与不透明推理对传统可观测性方法构成了显著挑战",[1237,1312,1315],{"href":1313,"rel":1314},"https:\u002F\u002Farxiv.org\u002Fhtml\u002F2411.03455v3",[1241],"[10]","。即便单个 Agent 好用，它本质上只是\"某个人在自己机器上跑的一个 loop\"——任务不透明，团队其他人无法 review Agent 的执行链路，也无法知道它为什么做了某个决策。业界至今缺少一个正式的过程模型来定义 Agent 之间及其与人类监督者如何贯穿整个研发生命周期协作",[1237,1318,1321],{"href":1319,"rel":1320},"https:\u002F\u002Farxiv.org\u002Fpdf\u002F2510.23664",[1241],"[11]","。这就意味着，Agent 的能力再强，也停留在个人工具的层面，无法升级为团队协作的基础设施。",[1229,1324,1326],{"id":1325},"_13-链路面从需求到上线各环节未打通","1.3 链路面：从需求到上线各环节未打通",[1098,1328,1329,1330,1335,1336,1341,1342,1295],{},"Agent 擅长写代码，但它只覆盖了生命周期的一段。现有软件工程 Agent 大多是各自解决孤立子问题的\"专才\"，缺少一个把整条链路贯通的统一体",[1237,1331,1334],{"href":1332,"rel":1333},"https:\u002F\u002Fwww.cs.purdue.edu\u002Fhomes\u002Flintan\u002Fpublications\u002FUSEagent-icse26.pdf",[1241],"[12]","。然而恰恰是评审、CI、部署这些后期阶段，因其产出可以通过可执行反馈客观评估，才是 Agent 最能落地的地方；工业界的普遍做法是把 Agent 动作限制在可验证、有边界的空间里",[1237,1337,1340],{"href":1338,"rel":1339},"https:\u002F\u002Farxiv.org\u002Fhtml\u002F2605.15245",[1241],"[13]","。但今天这些环节的衔接仍然靠人肉——issue 到代码、代码到 PR、PR 到 CI、CI 到部署，每一步都需要人手动触发，没有一个把 issue、代码、部署串成闭环的编排机制，而这层工作流管理本身就是公认的开放难题",[1237,1343,1346],{"href":1344,"rel":1345},"https:\u002F\u002Fwww.arxiv.org\u002Fpdf\u002F2510.02557",[1241],"[14]",[1112,1348],{},[1115,1350,1351],{"id":1351},"设计目标",[1229,1353,1355],{"id":1354},"_21-功能目标","2.1 功能目标",[1098,1357,1358],{},"这套架构要让团队能做到以下三件事：",[1098,1360,1361],{},"第一，团队成员在 IM（飞书）中发起任务时，Agent 自动执行并实时回流状态——从任务创建、指派到运行进展、终态结果，整个团队在群里看得见、可 review。",[1098,1363,1364],{},"第二，多个有依赖关系的任务能按 DAG 自动串联执行。一个任务完成并解锁下游后，下游任务自动派发，不需要人手动衔接。",[1098,1366,1367],{},"第三，部署环节有发布门拦截。代码推上去之后，Vercel 构建完成、域名分配之前，先由 liskin 跑一轮验证（测试、lint、类型检查），验证通过才放行，不通过就把坏版本卡在门外。",[1229,1369,1371],{"id":1370},"_22-架构约束","2.2 架构约束",[1098,1373,1374],{},"以下约束贯穿全部设计决策，在任何阶段都不得违反：",[1376,1377,1378,1385,1391,1397],"ul",{},[1379,1380,1381,1384],"li",{},[1130,1382,1383],{},"控制面与执行面分离","：Dispatcher 只做调度和状态跟踪，不碰代码、不碰密钥、不碰 prompt 内容。",[1379,1386,1387,1390],{},[1130,1388,1389],{},"编排层保持确定性","：OGAS-Flow 不调用 LLM、不含随机数、不介入 Agent 内部推理，节点之间的推进完全确定。",[1379,1392,1393,1396],{},[1130,1394,1395],{},"高危操作必须人工确认","：生产回滚、promote 等动作硬性设为 ask 确认，不允许 Agent 自主完成。",[1379,1398,1399,1402],{},[1130,1400,1401],{},"自托管，数据不出内网","：所有组件自托管部署，不依赖外部 SaaS 托管控制面。",[1229,1404,1406],{"id":1405},"_23-非目标","2.3 非目标",[1098,1408,1409],{},"为明确范围，以下事项不在本 RFC 的设计范围内：",[1376,1411,1412,1418,1424,1430],{},[1379,1413,1414,1417],{},[1130,1415,1416],{},"不自研编码 Agent 内核","：执行面使用 liskin，不自行开发 Agent 推理内核。",[1379,1419,1420,1423],{},[1130,1421,1422],{},"Dispatcher 不做模型推理","：控制面只做调度，不做任何模型调用。",[1379,1425,1426,1429],{},[1130,1427,1428],{},"不做云端 runtime","：MVP 阶段只支持本地开发机上的 runtime，云端执行暂不涉及。",[1379,1431,1432,1435],{},[1130,1433,1434],{},"不锁定接口签名和数据表结构","：本 RFC 只做架构设计，具体接口、schema、prompt 内容属于后续设计文档。",[1112,1437],{},[1115,1439,1440],{"id":1440},"现状与依赖",[1098,1442,1443],{},"本节逐个梳理 OGAS 所依赖的五个上游组件或平台，统一按\"现有能力 → 缺什么 → 对 OGAS 的意义\"三段来写。",[1229,1445,1447],{"id":1446},"_31-执行面core_agent_runtime","3.1 执行面：Core_Agent_Runtime",[1098,1449,1450,1451],{},"目前 liskin（作者自建，设计思想参考pi） 是 OGAS 的 Agent 执行内核，后续会考虑通过SDK支持其他SOTA Agent（claude code，codex）liskin 的项目地址：",[1237,1452,1453],{"href":1453,"rel":1454},"https:\u002F\u002Fgithub.com\u002FZhongye1\u002Fliskin_code_agent",[1241],[1098,1456,1457,1460,1461,1465,1466,1469,1470,1473,1474,1473,1477,1480,1481,1486,1487,1489],{},[1130,1458,1459],{},"现有能力。"," liskin 的架构已经为\"被外部调度\"做好了准备。它的 Kernel 与 Client 是解耦的，对外通过 ",[1462,1463,1464],"code",{},"agent exec"," 提供 headless 的无头执行模式，内部走 InProcessKernelClient，天然适合被守护进程以 stdin\u002Fstdout 的方式驱动。liskin 自带 Harness 长任务框架，任务状态落在 ",[1462,1467,1468],{},".liskin\u002Fharness\u002F"," 目录里，节点可中断、可恢复、可审计——这正是任务级容错想要的底座。其 Sandbox 用路径白名单加命令黑名单，再叠加 auto\u002Fask\u002Fdeny 三档确认，给了在自动化链路里插入人工卡点的抓手。liskin 的内核与外壳解耦体现在三个端口上：",[1462,1471,1472],{},"LLMPort","\u002F",[1462,1475,1476],{},"ToolPort",[1462,1478,1479],{},"StorePort","，内核只跟抽象契约打交道，换模型、换工具来源、换存储都不动内核",[1237,1482,1485],{"href":1483,"rel":1484},"https:\u002F\u002Fraw.githubusercontent.com\u002FZhongye1\u002Fliskin_code_agent\u002Fmain\u002FReadme.md",[1241],"[15]","。OGAS 正是利用 ",[1462,1488,1476],{}," 这一点，把外部能力作为 MCP 工具注入。",[1098,1491,1492,1495],{},[1130,1493,1494],{},"在建能力。"," liskin 的 MCP client 支持目前处于 Phase-1 进行中，对 GitHub\u002FVercel 的集成也标注为在建。这两块能力明确会做完，其完整形态对齐 pi agent 的能力边界。也就是说，MCP 接入、GitHub\u002FVercel 的原生集成不是要不要有的问题，而是时间问题。排期假设是在阶段二、阶段三可以放心地把这些能力算进 liskin 的既定路线，不必自己造完整实现，只需在集成落地前用最小 shim 过渡。",[1098,1497,1498,1501],{},[1130,1499,1500],{},"对 OGAS 的意义。"," liskin 为 OGAS 提供了执行面的全部基础：headless 模式让 Daemon 可以用进程方式驱动它；Harness 框架让长任务可中断可恢复；Sandbox 三档确认让高危操作可以拦截；三个端口让外部能力可以透明注入。OGAS 不需要修改 liskin 内核，只需在集成层做适配。",[1229,1503,1505],{"id":1504},"_32-知识面eaglerag","3.2 知识面：EagleRAG",[1098,1507,1508,1510,1511,1514],{},[1130,1509,1459],{}," EagleRAG 已经是一个成熟的 MCP Server，提供 streamable HTTP 的 ",[1462,1512,1513],{},"\u002Fmcp"," 端点和 stdio 两种接入方式。核心工具覆盖 ingest\u002Fquery\u002Fretrieve，并用 plugin_namespace 到 Milvus 的映射做多租户隔离。",[1098,1516,1517,1520],{},[1130,1518,1519],{},"缺什么。"," EagleRAG 当前是面向通用场景的知识检索服务，缺少面向团队协作的权限管理和命名空间封装。在 OGAS 中，不同业务线的 PRD、接口契约、UI 规范需要隔离，团队成员的检索权限需要按 workspace 区分。",[1098,1522,1523,1525],{},[1130,1524,1500],{}," 将它改造成 OGAS-Arkhiv，主要是围绕权限和命名空间做团队化封装，底层检索能力可以直接复用。改造工作量不大，不需要改动 EagleRAG 的核心检索引擎。",[1229,1527,1529],{"id":1528},"_33-控制面multica","3.3 控制面：Multica",[1098,1531,1532,1534,1535,1540,1541,1546,1547,1552],{},[1130,1533,1459],{}," Multica 是一个开源的 Go 平台",[1237,1536,1539],{"href":1537,"rel":1538},"https:\u002F\u002Fwww.multica.ai\u002F",[1241],"[24]","，其形态可以作为控制平面底座。它的 Server 负责协调、workspace\u002Fissue\u002F队列\u002F权限管理和 WebSocket hub，明确不做模型推理也不做 Agent 执行",[1237,1542,1545],{"href":1543,"rel":1544},"https:\u002F\u002Fnotemi.cn\u002Fmultica--integrating-ai-agents-into-team-collaboration-flow.html",[1241],"[16]","。它的 Daemon 装在开发机上，扫描本地的 AI CLI、注册 runtime、在隔离工作区里调用工具并返回结果。Runtime 是 daemon 与某个 AI 工具的配对，目前只支持本地，云端在等候名单上。任务通过 WebSocket 下发，状态机是 Queued → Dispatched → Running → Completed\u002FFailed\u002FCancelled，带 dispatch 五分钟、running 两个半小时的超时和可重试的失败处理，而且它原生就支持 pi runtime",[1237,1548,1551],{"href":1549,"rel":1550},"https:\u002F\u002Fmultica.ai\u002Fdocs\u002Finstall-agent-runtime",[1241],"[17]","。它以 Docker Compose、二进制或 K8s 自托管。",[1098,1554,1555,1557],{},[1130,1556,1519],{}," 唯一缺的是跨任务的 DAG 编排——这恰好是 OGAS-Flow 要自建的那一层。此外，Multica 假设的是全自主执行，没有 human-in-the-loop 的 ask 通道，而 OGAS 要求生产回滚、promote 这类高危动作必须人工确认。",[1098,1559,1560,1562],{},[1130,1561,1500],{}," Multica 的 Server\u002FDaemon 双进程结构、任务状态机、WebSocket 枢纽正好是控制面需要的东西。fork Multica 后，改动集中在五处（详见第四节 4.2），不侵入核心调度路径，方便周期性 rebase 上游。但有一个前置合规风险：Multica 的许可证为 NOASSERTION（非标准开源许可），商用和二次开发的合规性需要法务确认，这直接决定 fork 路线是否成立。",[1229,1564,1566],{"id":1565},"_34-部署面vercel","3.4 部署面：Vercel",[1098,1568,1569,1571,1572,1575,1576,1581],{},[1130,1570,1459],{}," Vercel 的构建与发布是解耦的。它的 Deployment Checks 能以阻塞式检查的形式，在生产构建完成、域名分配之前把版本卡住，检查可以通过 GitHub Actions 或 Checks API 的 webhook（deployment.created\u002Fready\u002Fsucceeded\u002Ferror）来驱动。它的 Instant Rollback（",[1462,1573,1574],{},"vercel rollback [id|url]","）把域名指回上一个部署，不需要重新构建",[1237,1577,1580],{"href":1578,"rel":1579},"https:\u002F\u002Fvercel.com\u002Fdocs\u002Finstant-rollback",[1241],"[18]","。检查到底阻塞还是不阻塞，以及超时后放行还是拦截，都由开发者按项目自行配置。",[1098,1583,1584,1587,1588,1591],{},[1130,1585,1586],{},"缺什么 \u002F 需要注意的坑。"," 回滚之后自动分配会被关掉——版本被 pin 住，后续想恢复正常发布得走 ",[1462,1589,1590],{},"vercel promote"," 才能恢复。这一步在流程里必须显式记住，否则部署会莫名其妙不生效。",[1098,1593,1594,1596],{},[1130,1595,1500],{}," Vercel 的 Deployment Checks 天然适合做成 OGAS-Flow 里的 GATE 节点：构建完成后触发 liskin 验证，验证结果通过 Checks API 回写，通过则放行上线，不通过则拦截。回滚作为兜底手段，由人工确认后触发。",[1229,1598,1600],{"id":1599},"_35-编排面学术与工业参考","3.5 编排面：学术与工业参考",[1098,1602,1603],{},"关于编排层怎么工程化实现，近期的学术与工业工作给出了相当一致的方向，以下四条结论共同支撑了 OGAS-Flow 的设计取向：",[1376,1605,1606,1617,1628,1639],{},[1379,1607,1608,1611,1612,1295],{},[1130,1609,1610],{},"Agint"," 把软件工程任务先编译成图再执行，主张即便 AI 步骤不确定、图的执行也要保持确定，并用 SHIM 节点做\"含 AI 组件却仍确定性推进\"的混合执行",[1237,1613,1616],{"href":1614,"rel":1615},"https:\u002F\u002Fwww.arxiv.org\u002Fpdf\u002F2511.19635",[1241],"[19]",[1379,1618,1619,1622,1623,1295],{},[1130,1620,1621],{},"微软 Conductor"," 论证了\"结构已知的工作流不该让 LLM 动态路由\"，而应把编排做成声明式、确定性、消耗零 token 的一层，并把执行、上下文流转、人工监督显式拆开",[1237,1624,1627],{"href":1625,"rel":1626},"https:\u002F\u002Fopensource.microsoft.com\u002Fblog\u002F2026\u002F05\u002F14\u002Fconductor-deterministic-orchestration-for-multi-agent-ai-workflows\u002F",[1241],"[20]",[1379,1629,1630,1633,1634,1295],{},[1130,1631,1632],{},"OrchBench"," 给出了\"把编排计划从执行中剥离、用确定性模拟单独评估\"的方法，沿结构、覆盖、缺失子任务、依赖正确性、冗余、并行合理性六个维度检验 DAG",[1237,1635,1638],{"href":1636,"rel":1637},"https:\u002F\u002Farxiv.org\u002Fhtml\u002F2607.25656v1",[1241],"[21]",[1379,1640,1641,1644,1645,1295],{},[1130,1642,1643],{},"Temporal \u002F durable execution"," 的成熟做法是用事件历史确定性重放来替代手搓状态机，实现崩溃恢复",[1237,1646,1649],{"href":1647,"rel":1648},"https:\u002F\u002Ftemporal.io\u002Fblog\u002Ftemporal-replaces-state-machines-for-distributed-applications",[1241],"[22]",[1098,1651,1652],{},"这四条结论的共识是：编排的确定性部分和 Agent 的非确定性部分要彻底分开，不确定性全部关进节点内部，节点之间的推进保持确定、零推理、可单独验证。OGAS-Flow 逐条落地这四点，具体设计见第四节 4.4。",[1112,1654],{},[1115,1656,1657],{"id":1657},"任务派发流程设计",[1098,1659,1660,1661],{},"OGAS 的任务派发流程横跨五个组件，整条链路是",[1130,1662,1663],{},"飞书群 → Gate 翻译 → Flow 编排 → Dispatcher 派发 → Daemon 拉起 liskin → MCP 工具执行 → 结果原路回流 → Flow 解锁下游 → Gate 推回群里",[1098,1665,1666],{},[1667,1668],"img",{"alt":1669,"src":1670},"","https:\u002F\u002Fpic4.zhimg.com\u002Fv2-c7e8e75221bb2c108789f34db132c601_r.jpg",[1229,1672,1674],{"id":1673},"第一步任务发起飞书群-ogas-gate","第一步：任务发起（飞书群 → OGAS-Gate）",[1098,1676,1677],{},"团队成员在飞书群里 @机器人，用自然语言下达指令——比如\"让 liskin-frontend 实现登录页\"。OGAS-Gate 作为 IM 适配服务，接住飞书的事件回调，把群聊指令翻译成 Dispatcher 的 REST API 调用：创建 issue、指派 Agent、设定任务参数。Gate 不直连 Multica 内部数据表，而是走 Dispatcher 的 API facade 层（见 RFC 4.2 第四层改动），这样上游 schema 变化时只影响适配层。",[1098,1679,1680],{},"如果任务属于某个 DAG 的一部分，Gate 还会通知 OGAS-Flow 有新节点需要编排。",[1229,1682,1684],{"id":1683},"第二步dag-编排ogas-flow-ogas-dispatcher","第二步：DAG 编排（OGAS-Flow → OGAS-Dispatcher）",[1098,1686,1687,1688,1691],{},"OGAS-Flow 拿到 DAG 定义后，调用纯函数 ",[1462,1689,1690],{},"next_ready(dag, completed_set)"," 计算当前哪些节点的前驱已全部完成、可以派发。这个函数是确定性的——不调用 LLM、不含随机数，给定相同输入永远输出相同结果。",[1098,1693,1694],{},"对于刚启动的 DAG，入口节点没有前驱依赖，立刻进入 ready 状态。Flow 把 ready 节点对应的 issue 派发指令发给 Dispatcher：\"把这个 issue 派给 liskin-frontend runtime\"。Flow 自己不执行任何代码，只做图推进。",[1229,1696,1698],{"id":1697},"第三步任务派发dispatcher-server-daemon","第三步：任务派发（Dispatcher Server → Daemon）",[1098,1700,1701],{},"Dispatcher Server 收到派发指令后，查到 liskin-frontend runtime 注册在哪台开发机上，通过 WebSocket 通知那台机器上的 Daemon。",[1098,1703,1704,1705,1708],{},"任务状态机随之流转：",[1130,1706,1707],{},"Queued → Dispatched","。Dispatcher 有超时规则——派发后 5 分钟内 Daemon 必须接单（拉起进程），否则判超时；进入 Running 后有指定小时的执行窗口。瞬时失败（比如进程崩溃）由 Dispatcher 自己重试，重试耗尽后才向上层发出一个可区分的\"重试已耗尽\"终态，而不是普通 Failed。",[1098,1710,1711,1712,1715],{},"Dispatcher 全程不碰代码、不碰密钥、不碰 prompt 内容。GitHub token、Vercel token、Arkhiv 的 MCP 端点都配在 Agent 级的 ",[1462,1713,1714],{},"custom_env"," 里，Daemon 在 spawn 进程时原样透传，Dispatcher 只是转发。",[1229,1717,1719],{"id":1718},"第四步agent-执行daemon-liskin","第四步：Agent 执行（Daemon → liskin）",[1098,1721,1722,1723,1726,1727,1729],{},"Daemon 收到 WebSocket 通知后，在隔离工作目录里拉起 ",[1462,1724,1725],{},"liskin agent exec"," 进程。任务描述通过 stdin 写入，结果从 stdout 拿回。Daemon 只管进程生命周期——拉起、喂提示词、收结果，不管 kernel 内部状态。liskin 的 Harness 框架自管内部的任务节点状态（落在 ",[1462,1728,1468],{}," 目录里），这两层状态刻意解耦。",[1098,1731,1732,1733,1735],{},"liskin 在执行过程中通过 ",[1462,1734,1476],{}," 调用三类 MCP 工具：",[1376,1737,1738,1743,1749],{},[1379,1739,1740,1742],{},[1130,1741,1213],{},"：查询 PRD、接口契约、UI 规范等业务知识",[1379,1744,1745,1748],{},[1130,1746,1747],{},"GitHub MCP","：领 issue、读代码、开 PR、查 CI 结果",[1379,1750,1751,1754],{},[1130,1752,1753],{},"Vercel MCP","：触发部署、查询部署状态",[1098,1756,1757],{},"这些工具调用对上层完全透明，Dispatcher 不感知 Agent 在用什么工具，Flow 同理。",[1229,1759,1761],{"id":1760},"第五步结果回流与下游解锁","第五步：结果回流与下游解锁",[1098,1763,1764,1765,1295],{},"liskin 执行完毕后，结构化结果从 stdout 返回给 Daemon，Daemon 回传给 Server，任务状态流转为 ",[1130,1766,1767],{},"Completed \u002F Failed \u002F Cancelled",[1098,1769,1770],{},"这条终态事件同时推给两个消费者：",[1376,1772,1773,1782],{},[1379,1774,1775,1777,1778,1781],{},[1130,1776,1175],{},"：消费 Completed 事件，把该节点加入已完成集合，重新调用 ",[1462,1779,1780],{},"next_ready"," 计算下游是否有新节点解锁。如果有，立刻把下游节点派发给 Dispatcher——整个链路自动推进，不需要人手动衔接。",[1379,1783,1784,1786],{},[1130,1785,1162],{},"：把状态流转翻译成飞书群消息推回给团队。回流粒度可配置（全量模式 \u002F 终态模式 \u002F 混合模式），让团队看得见 Agent 跑到了哪一步。",[1098,1788,1789,1790,1792],{},"如果进程崩溃，Dispatcher 重启后，Flow 不需要从 checkpoint 恢复——把 Dispatcher 的终态事件流重放一遍就能重建当前的已完成集合，再调用 ",[1462,1791,1780],{}," 继续推进。这就是事件溯源的基本思路。",[1229,1794,1796],{"id":1795},"旁路高危操作的人工确认通道","旁路：高危操作的人工确认通道",[1098,1798,1799],{},"当 liskin 的 Sandbox 遇到 ask 档操作（比如生产回滚、promote），原本单向的\"派任务—回结果\"链路会切换成双向交互子通道：",[1098,1801,1802],{},"liskin 抛出 ask 提示 → Daemon 通过 WebSocket 上报 Server → Server 推给 Gate → Gate 在飞书群里高亮告警。但实际的确认动作不在群消息里完成——成员需要跳转到有更强身份校验的界面（比如飞书内嵌 H5 审批页）。确认后，决策沿原路回灌：Gate → Server → Daemon → liskin 的 stdin，Agent 继续执行或终止。",[1098,1804,1805],{},"这条 ask 通道复用现有的 WebSocket 连接基础设施，是原生 Multica 没有、OGAS 必须加的一段设计。",[1112,1807],{},[1115,1809,1810],{"id":1810},"工程方案",[1098,1812,1813],{},"本 RFC 不锁定具体的接口签名、数据表结构和 prompt 内容，后续设计文档会详细说明。",[1098,1815,1816],{},"整体思路是控制面与执行面彻底分离，再在两端分别接上入口和编排，形成四层各司其职的结构。各组件统一遵循\"是什么 → 输入输出 → 设计细节 → 边界约束\"的叙述框架，以下逐层展开。",[1229,1818,1820],{"id":1819},"_40-架构总览","4.0 架构总览",[1098,1822,1823],{},"OGAS 的四层架构如下：",[1376,1825,1826,1832,1838,1844],{},[1379,1827,1828,1831],{},[1130,1829,1830],{},"入口面（OGAS-Gate）","：连接飞书群聊和 Dispatcher，是团队成员发起任务的统一入口。",[1379,1833,1834,1837],{},[1130,1835,1836],{},"编排面（OGAS-Flow）","：维护 DAG 依赖关系，消费 Dispatcher 的任务终态事件，按依赖解锁下游节点。",[1379,1839,1840,1843],{},[1130,1841,1842],{},"控制面（OGAS-Dispatcher）","：中心化任务调度器，把任务派到正确的开发机和 Agent 上，跟踪状态，不做模型推理。",[1379,1845,1846,1849],{},[1130,1847,1848],{},"执行面（liskin + MCP 工具）","：编码 Agent 内核，通过 ToolPort 注入业务知识库、GitHub、Vercel 三类 MCP 能力。",[1098,1851,1852,1853,1855],{},"核心设计原则是",[1130,1854,1383],{},"：Dispatcher 只做调度和状态跟踪，永远不碰代码、不碰密钥、不碰 prompt 内容；编排层保持确定性，不介入 Agent 内部推理。这条原则贯穿所有设计决策，后面每一层的设计都建立在这个前提上。",[1229,1857,1859],{"id":1858},"_41-执行面liskin","4.1 执行面：liskin",[1098,1861,1862],{},[1667,1863],{"alt":1669,"src":1864},"https:\u002F\u002Fpicx.zhimg.com\u002Fv2-9777b251deba03398d66d6a3419ccd6d_r.jpg",[1098,1866,1867],{},"liskin 是 OGAS 的编码 Agent 执行内核。它在系统中的角色是\"被 Dispatcher 驱动的编码引擎\"——收到任务后自主完成代码编写、测试、提交，完成后返回结构化结果。",[1869,1870,1871],"h4",{"id":1871},"输入输出",[1098,1873,1874],{},"输入是 Dispatcher Daemon 通过 stdin 写入的任务描述（提示词），输出是 stdout 返回的结构化执行结果。Agent 在执行过程中可以通过 ToolPort 调用三类 MCP 工具：OGAS-Arkhiv（业务知识检索）、GitHub（代码操作 \u002F PR \u002F CI 结果读取）、Vercel（部署触发与状态查询）。",[1869,1876,1877],{"id":1877},"设计",[1098,1879,1880,1881,1473,1883,1473,1885,1887,1888,1891,1892,1894],{},"liskin 的关键价值在于内核与外壳解耦。",[1462,1882,1472],{},[1462,1884,1476],{},[1462,1886,1479],{}," 三个端口让内核只跟抽象契约打交道，换模型、换工具来源、换存储都不动内核",[1237,1889,1485],{"href":1483,"rel":1890},[1241],"。OGAS 利用 ",[1462,1893,1476],{}," 把三类外部能力作为 MCP 工具注入：",[1376,1896,1897,1902,1907],{},[1379,1898,1899,1901],{},[1130,1900,1213],{}," 作为业务知识库以 MCP Server 形态常驻，补上 liskin 自带的代码侧检索所缺的业务侧知识——PRD、接口契约、UI 规范、历史决策。",[1379,1903,1904,1906],{},[1130,1905,23],{}," 以 MCP 接入，让 Agent 能领 issue、开 PR、读 CI 结果。",[1379,1908,1909,1912],{},[1130,1910,1911],{},"Vercel"," 以 MCP 接入，负责部署触发与状态查询。",[1098,1914,1915],{},"这些注入对上层完全透明——上层只知道\"把任务派给某个 Agent\"，Agent 内部有多少业务知识和部署能力是执行面自己的事。",[1098,1917,1918,1919,1921,1922,1924],{},"liskin 自带的 Harness 长任务框架是任务级容错的底座。任务状态落在 ",[1462,1920,1468],{}," 目录里，节点可中断、可恢复、可审计。这意味着 Daemon 只需要管进程生命周期（拉起 ",[1462,1923,1725],{},"、通过 stdin 喂提示词、从 stdout 拿结果），不需要管 kernel 内部状态——kernel 状态由 Harness 框架自管。",[1098,1926,1927],{},"liskin 的 Sandbox 用路径白名单加命令黑名单，再叠加 auto\u002Fask\u002Fdeny 三档确认。auto 档自动放行安全操作，deny 档直接拒绝危险操作，ask 档把决策抛回给调用方。在 OGAS 中，ask 档被串联到 Daemon → Server → Gate → 飞书群的双向通道，最终由人在群里确认（详见 4.2 的 ask 通道设计和 4.3 的 Gate 交互协议）。",[1869,1929,1930],{"id":1930},"边界约束",[1098,1932,1933,1934,1936],{},"liskin 的 Harness 状态（",[1462,1935,1468],{}," 里的节点状态）是执行面内部的容错机制，不等于 Dispatcher 的任务状态。Dispatcher 只看到\"这个 task 在 running \u002F 完成了\"，liskin 内部跑了多少步、中断恢复了多少次，是它自己的事。这两层状态必须解耦，否则系统会退化成分布式状态泥潭。这一约束在第五节风险分析中有更详细的讨论。",[1229,1938,1940],{"id":1939},"_42-控制面ogas-dispatcher","4.2 控制面：OGAS-Dispatcher",[1098,1942,1943],{},[1667,1944],{"alt":1669,"src":1945},"https:\u002F\u002Fpicx.zhimg.com\u002Fv2-62f3b0bc609bf8efbe35e90553280fab_r.jpg",[1098,1947,1948],{},"OGAS-Dispatcher 是中心化任务调度器。它解决的问题是：团队里有多台开发机、多个 Agent 实例，需要一个中心组件把任务派到正确的机器、正确的 Agent 上，并跟踪每个任务跑到了哪一步。Dispatcher 自己不做任何模型推理、不执行任何代码、不接触密钥和 prompt 内容——这条边界是后续所有设计的前提。",[1098,1950,1951,1954],{},[1130,1952,1953],{},"输入输出。"," Dispatcher 对上给 OGAS-Flow 提供任务状态事件（Completed \u002F Failed \u002F Cancelled），对旁给 OGAS-Gate 提供建\u002F派\u002F查 issue 的 API，对下通过 Daemon 把任务派给 liskin 执行。",[1869,1956,1957],{"id":1957},"构成",[1098,1959,1960],{},"Dispatcher 由三部分构成：",[1376,1962,1963,1969,1980],{},[1379,1964,1965,1968],{},[1130,1966,1967],{},"Server","：协调中枢。管 workspace（工作空间，映射到团队或项目）、issue（任务实体，一个 issue = 一次 liskin exec 调用）、任务队列、成员权限，同时是 WebSocket 枢纽。Server 跑在中心节点上，所有任务创建、派发、状态流转都经过它。",[1379,1970,1971,1974,1975,1295],{},[1130,1972,1973],{},"Daemon","：开发机守护进程。安装在每台开发机上，启动时扫描本地安装了哪些 AI CLI 工具、注册成 runtime，接到任务后建隔离工作目录、调用工具、回传结果。Daemon 与 Agent 通信的底层是 stdin\u002Fstdout——提示词写进进程、结果从 stdout 拿回，任务触发靠 WebSocket 通知后本地客户端拉取",[1237,1976,1979],{"href":1977,"rel":1978},"https:\u002F\u002Fblog.csdn.net\u002Fqq_63691275\u002Farticle\u002Fdetails\u002F162015817",[1241],"[23]",[1379,1981,1982,1985],{},[1130,1983,1984],{},"Runtime","：Daemon 与某个 AI 工具的配对。一台机器上装了 liskin，就注册成一个 liskin runtime；装了 pi，就注册成一个 pi runtime。一个 runtime = 一台机器上的一个 Agent 执行单元。目前只支持本地 runtime，云端在等候名单上。",[1869,1987,1988],{"id":1988},"职责边界与设计",[1098,1990,1991,1992,1995],{},"Multica 的 Server 有一条硬约束：它只做协调、workspace\u002Fissue\u002F队列\u002F权限管理和 WebSocket hub，本身不做任何模型推理、不执行任何 Agent 任务",[1237,1993,1545],{"href":1543,"rel":1994},[1241],"。OGAS-Dispatcher 原样继承这条边界。具体来说：",[1098,1997,1998],{},[1130,1999,2000],{},"Dispatcher 做什么：",[1376,2002,2003,2006,2009,2012],{},[1379,2004,2005],{},"任务派发：把任务派到对应 runtime（开发机上的 Agent 实例）",[1379,2007,2008],{},"状态跟踪：维护任务状态机（Queued → Dispatched → Running → Completed\u002FFailed\u002FCancelled）",[1379,2010,2011],{},"事件推送：把状态流转事件推给 OGAS-Flow 和 OGAS-Gate",[1379,2013,2014],{},"权限管理：管理 workspace 成员和任务权限",[1098,2016,2017],{},[1130,2018,2019],{},"Dispatcher 不做什么：",[1376,2021,2022,2025,2028,2031],{},[1379,2023,2024],{},"不碰代码——代码在 Agent 进程里，Dispatcher 只是转发任务",[1379,2026,2027],{},"不碰密钥——GitHub token、Vercel token 通过 Daemon 的环境变量透传给 Agent，Dispatcher 看不到",[1379,2029,2030],{},"不碰 prompt 内容——提示词由 Gate\u002FFlow 生成或由 issue 模板提供，Dispatcher 只做转发",[1379,2032,2033],{},"不做编排——跨任务 DAG 是 OGAS-Flow 的职责，Dispatcher 只提供单 issue 状态机这块原子能力",[1098,2035,2036],{},"平面底座的设计目标参考Multica，如Server\u002FDaemon 双进程结构、任务状态机、WebSocket 枢纽等。改动集中在适配层和扩展层。",[1098,2038,2039],{},"fork 的改动集中在以下四处，按层次组织：",[1098,2041,2042],{},[1130,2043,2044],{},"第一层：基本集成——把 liskin 注册成一个 runtime。",[1098,2046,2047,2048,2051,2052,2054,2055,2057],{},"这是 fork 的核心工作。Multica 的 Daemon 启动时会扫描 PATH 上的 AI CLI 并注册成 runtime，而且其上游原生就支持 pi 作为 runtime",[1237,2049,1551],{"href":1549,"rel":2050},[1241],"。liskin 的 ",[1462,2053,1464],{}," 是一个 headless、一次性的 stdin\u002Fstdout 入口，内部走 InProcessKernelClient，这跟 Daemon 驱动 pi 的方式在结构上是同一类东西。所以最省事的做法是照着 pi 的 runtime adapter 仿一个 liskin provider：Daemon 拉起 ",[1462,2056,1725],{},"，把提示词写进 stdin，从 stdout 拿回结构化结果。因为 liskin 的 Kernel 与 Client 解耦、headless 模式自管内核生命周期，Daemon 只需要管进程生命周期，不需要管 kernel 状态。MVP 阶段可以先用一个薄 shim 让 liskin\"看起来像\"一个已支持的 provider 过渡，等 liskin 上游把 MCP client 补齐再切正式集成。",[1098,2059,2060],{},[1130,2061,2062],{},"第二层：编排接入——状态事件引出给 Flow。",[1098,2064,2065,2066,2069],{},"Multica 的状态机（Queued → Dispatched → Running → Completed\u002FFailed\u002FCancelled）、超时规则（dispatch 5 分钟、running 2.5 小时）、失败可重试分类全部原样保留",[1237,2067,1545],{"href":1543,"rel":2068},[1241],"。fork 要加的是：让每一次状态流转都发出一个可订阅的事件，OGAS-Flow 的节点完成信号就取自 Dispatcher 的 Completed 事件——走 WebSocket 或单独的事件总线推给 Flow，别让 Flow 去轮询。",[1098,2071,2072,2073,2076],{},"这里有一个必须提前明确的语义：",[1130,2074,2075],{},"重试归 Dispatcher，编排归 Flow。"," Dispatcher 负责单个 issue 内的瞬时失败重试（比如进程崩溃后重启一次），OGAS-Flow 只读终态、绝不自己重试。这也正是 Multica 里 Autopilot 触发的任务被刻意设计成不自动重试的同一考量——避免上下层调度撞车。为此要把\"重试已耗尽\"做成一个和普通 Failed 可区分的终态，Flow 才能干净地判断该阻断还是走补偿分支。",[1098,2078,2079],{},[1130,2080,2081],{},"第三层：安全机制——ask 双向通道。",[1098,2083,2084],{},"这是原生 Multica 没有、OGAS 必须加的一段。Multica 假设的是全自主执行，但本 RFC 要求生产回滚、promote 这类高危动作必须人工确认，而 liskin 的 Sandbox 本身有 auto\u002Fask\u002Fdeny 三档。设计上需要把 liskin 抛出的 ask 提示，通过 Daemon → Server → Gate 一路串回飞书群，再把人的确认从群里回灌进 liskin 进程的 stdin。也就是说，原本单向的\"派任务—回结果\"链路，要为高危动作开一条双向的交互子通道。这条通道也是 WebSocket 上的一个子协议，复用现有的连接基础设施。",[1098,2086,2087,2088,2090,2091,2093,2094,2097,2098,2100,2101,2103],{},"关于 MCP 工具配置的透传，这里一句话带过：Arkhiv、GitHub、Vercel 这三类 MCP 是执行面的事，通过 liskin 的 ",[1462,2089,1476],{}," 注入，对 Dispatcher 完全透明。Multica 的 Agent 配置本来就支持 per-agent 的 ",[1462,2092,1714],{}," \u002F ",[1462,2095,2096],{},"custom_args","，把 Arkhiv 的 MCP 端点、GitHub token、Vercel token 都配成 agent 级的 ",[1462,2099,1714],{},"，Daemon 在 spawn ",[1462,2102,1725],{}," 时原样带下去即可。Dispatcher 只是转发，永远看不到这些密钥和代码。",[1098,2105,2106],{},[1130,2107,2108],{},"第四层：长期可维护——API facade。",[1098,2110,2111],{},"给 Gate 和 Flow 提供一个稳定的 API facade，别让它们直连 Multica 内部。issue 的建\u002F派\u002F改状态\u002F评论、任务状态流转的 WebSocket 订阅、以及那条\"人和 Agent 交错的活动时间线\"（Gate 要把它镜像成飞书群消息），都应该通过一层版本化的 API 门面暴露，而不是让 Gate\u002FFlow 去读 Multica 的内部数据表。这样上游 schema 一变，受影响的只是门面适配层，Gate 和 Flow 不用跟着改——这是 fork 长期可维护的关键纪律。",[1229,2113,2115],{"id":2114},"_43-入口面ogas-gate","4.3 入口面：OGAS-Gate",[1098,2117,2118],{},[1667,2119],{"alt":1669,"src":2120},"https:\u002F\u002Fpicx.zhimg.com\u002Fv2-7a88d3437ab3401054676386878c95ff_r.jpg",[1098,2122,2123],{},"OGAS-Gate 是 OGAS-Dispatcher Server 之外的一个适配服务，一头连飞书事件回调，一头连 Dispatcher 的 API 和 WebSocket。它的角色是\"IM 到系统的翻译器\"——把群聊里的自然语言指令翻译成 Dispatcher 的 API 调用，把 Dispatcher 的状态事件翻译成群消息推回给团队。",[1869,2125,2127],{"id":2126},"与-dispatcher-的接口","与 Dispatcher 的接口",[1098,2129,2130],{},"Gate 通过 Dispatcher 的 API facade（见 4.2 第四层改动）与 Dispatcher 交互，不直连 Multica 内部数据表。交互内容分两类：",[1376,2132,2133,2139],{},[1379,2134,2135,2138],{},[1130,2136,2137],{},"指令类","：建 issue、指派 Agent、查任务状态、加评论——这些通过 Dispatcher 的 REST API 完成。",[1379,2140,2141,2144],{},[1130,2142,2143],{},"事件类","：任务状态流转的 WebSocket 订阅——Gate 订阅 Dispatcher 的状态事件流，每次状态流转都推回飞书群。",[1098,2146,2147],{},"这样 Dispatcher 那条\"人和 Agent 交错的活动时间线\"就映射成了群消息。团队成员在群里 @机器人 下达\"让某 Agent 处理某 issue\"，OGAS-Gate 调 Dispatcher 建\u002F派任务，Server 把任务派到对应 runtime，而 task 每次状态流转都推回飞书群。整个团队看得见 Agent 领了什么活、跑到哪、成功还是卡住，谁都能 review 执行链路并提建议——这正是把个人工具升级为团队协作的关键动作。",[1869,2149,2151],{"id":2150},"群内可触发的操作-vs-需要跳转的操作","群内可触发的操作 vs 需要跳转的操作",[1098,2153,2154],{},"并非所有操作都适合在群消息里一句话完成。操作的交互协议按风险等级分两档：",[1098,2156,2157],{},[1130,2158,2159],{},"可在群内直接触发的操作：",[1376,2161,2162,2165,2168,2171],{},[1379,2163,2164],{},"创建 issue、指派 Agent",[1379,2166,2167],{},"查询任务状态",[1379,2169,2170],{},"给任务加评论",[1379,2172,2173],{},"取消任务（非生产操作）",[1098,2175,2176],{},[1130,2177,2178],{},"必须跳转到更强身份校验界面的操作：",[1376,2180,2181,2188,2193],{},[1379,2182,2183,2184,2187],{},"触发生产回滚（",[1462,2185,2186],{},"vercel rollback","）",[1379,2189,2190,2191,2187],{},"恢复自动部署（",[1462,2192,1590],{},[1379,2194,2195],{},"修改部署检查配置",[1098,2197,2198],{},"高危操作的 ask 确认虽然通过 Gate 的双向通道回流到群里提示，但实际的确认动作不在群消息里完成，而是跳转到有更强身份校验的界面（例如飞书内嵌的 H5 审批页）。这与第四节 Dispatcher 的 ask 通道设计和 OGAS-Flow 的 GATE 节点落点一致。",[1869,2200,2201],{"id":2201},"状态回流粒度",[1098,2203,2204],{},"Gate 把 Dispatcher 的每次状态流转都推回飞书群，但为了控制消息噪音，回流粒度可以配置：",[1376,2206,2207,2213,2219],{},[1379,2208,2209,2212],{},[1130,2210,2211],{},"全量模式","：每次状态流转都推一条消息（适合调试期或关键任务）",[1379,2214,2215,2218],{},[1130,2216,2217],{},"终态模式","：只在任务到达 Completed \u002F Failed \u002F Cancelled 时推送（适合日常使用）",[1379,2220,2221,2224],{},[1130,2222,2223],{},"混合模式","：全量推送 AGENT 节点，终态推送 GATE 节点",[1098,2226,2227],{},"具体粒度配置在 Gate 的项目级设置中管理，不做全局硬编码。",[1229,2229,2231],{"id":2230},"_44-编排面ogas-flow","4.4 编排面：OGAS-Flow",[1098,2233,2234],{},[1667,2235],{"alt":1669,"src":2236},"https:\u002F\u002Fpica.zhimg.com\u002Fv2-3fa40462e3a38f9cd7b77d27723cec50_r.jpg",[1098,2238,2239],{},"OGAS-Flow 是一个 DAG 编排器。它解决的问题是：多个研发任务之间存在先后依赖关系（比如\"先实现功能，再写测试，再提交 PR，再部署\"），需要一个组件按依赖顺序自动串联执行。OGAS-Flow 坐在 Dispatcher 之上，消费 Dispatcher 的任务终态事件来解锁下游节点。它本身不执行代码、不调用 LLM，只做确定性的图推进。",[1869,2241,1871],{"id":2242},"输入输出-1",[1098,2244,2245,2248,2249,1295],{},[1130,2246,2247],{},"输入："," 一个声明式 DAG 定义（YAML\u002FJSON），描述节点类型、绑定的 issue 模板、派给哪个 Agent、依赖哪些上游节点、GATE 节点的判定表达式。DAG 定义可以进 Git、可 review、可 diff，能像 CI 流水线一样被对待",[1237,2250,1627],{"href":1625,"rel":2251},[1241],[1098,2253,2254,2257],{},[1130,2255,2256],{},"输出："," 给 Dispatcher 的派发指令——当下游节点解锁后，告诉 Dispatcher \"把这个 issue 派给那个 Agent\"。",[1098,2259,2260],{},"以下是一个最小 DAG 示例，让读者直观看到输入长什么样：",[2262,2263,2268],"pre",{"className":2264,"code":2266,"language":2267,"meta":1669},[2265],"language-yaml","# DAG 示例：从 issue 到上线\ndag:\n    - id: implement\n      type: AGENT\n      issue: \"实现登录页\"\n      agent: liskin-frontend\n    - id: review-gate\n      type: GATE\n      depends_on: [implement]\n      check: \"pr_review_approved\"\n    - id: deploy\n      type: GATE\n      depends_on: [review-gate]\n      check: \"vercel_deployment_check\"\n    - id: verify\n      type: AGENT\n      issue: \"验证线上功能正常\"\n      agent: liskin-frontend\n      depends_on: [deploy]\n","yaml",[1462,2269,2266],{"__ignoreMap":1669},[1098,2271,2272],{},"这个 DAG 的执行过程是：implement 节点派给 liskin 执行编码 → 完成后 review-gate 检查 PR 是否通过审批 → 通过后 deploy 触发 Vercel 构建并跑检查门 → 检查通过后 verify 节点派给 liskin 验证线上功能是否正常。读者一看就理解了 OGAS-Flow 做的事情。",[1869,2274,2275],{"id":2275},"三类节点的设计动机",[1098,2277,2278],{},"一个研发链路里有两类操作：Agent 干活（不确定，可能成功也可能失败）和人工\u002F自动的检查点（确定性的门，决定要不要继续）。如果只用一种节点，编排器就必须理解 Agent 内部状态才能决定下一步，这就违反了\"编排不碰 Agent 内部\"的原则。所以把\"不确定的执行\"和\"确定的判定\"分成不同类型的节点，编排器只看节点终态，不需要理解内部发生了什么。",[1098,2280,2281],{},"DAG 里的节点显式分成三种：",[1376,2283,2284,2290,2302],{},[1379,2285,2286,2289],{},[1130,2287,2288],{},"AGENT 节点","：绑一个 issue、派给一个 liskin runtime。内部完全不确定——Agent 可能成功、可能失败、可能超时。Flow 只认它的终态事件（Completed \u002F Failed \u002F 重试耗尽 \u002F Cancelled），不关心它内部跑了多少步。",[1379,2291,2292,2295,2296,2299,1295],{},[1130,2293,2294],{},"GATE 节点","：做确定性判定加可选人工确认。自身不写代码，只消费上游产物和人的确认，输出一个确定的分支信号。部署发布门与回滚审批都建模成 GATE 节点，而不是塞进 AGENT 节点内部——这样 Agent 只管写代码，发布决策由编排层做。GATE 节点对应 Agint 的 SHIM 与 Conductor 的人工监督步骤",[1237,2297,1616],{"href":1614,"rel":2298},[1241],[1237,2300,1627],{"href":1625,"rel":2301},[1241],[1379,2303,2304,2307],{},[1130,2305,2306],{},"JOIN 节点","：纯确定性的汇聚点。等多个前驱全部完成才解锁下游。第一版线性串联时退化成单前驱，但类型先留好，后续扩并行不改模型。",[1869,2309,2310],{"id":2310},"执行规则",[1098,2312,2313,2314,2317,2318,1295],{},"Flow 的核心是一个纯函数 ",[1462,2315,2316],{},"next_ready(dag, completed_set) → nodes_to_dispatch","。给定 DAG 与已完成集合，输出完全确定——不调用任何 LLM、不含随机数。这是\"编排零 token、可模拟\"的前提。结构已知的工作流不该让 LLM 动态路由，而应做成声明式、确定、消耗零 token 的一层",[1237,2319,1627],{"href":1625,"rel":2320},[1241],[1098,2322,2323],{},"Flow 只维护两份数据：DAG 拓扑定义和已完成集合。谁是已完成、谁失败了，一律以 Dispatcher 推过来的终态事件为准——Flow 不自己查询 Agent 状态，不自己判断任务成功与否。",[1869,2325,2326],{"id":2326},"状态来源与崩溃恢复",[1098,2328,2329],{},"Flow 的状态管理分两层：",[1098,2331,2332,2335],{},[1130,2333,2334],{},"状态来源。"," Flow 不另存权威副本。Dispatcher 的终态事件流（Completed \u002F 重试耗尽 \u002F Cancelled）是唯一事实源。当前状态等于对事件流做一次 fold——把所有终态事件按顺序应用，得到当前的已完成集合。Flow 自己只维护 DAG 拓扑定义这份静态数据。",[1098,2337,2338,2341,2342,2344,2345,1295],{},[1130,2339,2340],{},"崩溃恢复。"," 进程重启时，Flow 不需要从 checkpoint 恢复。把 Dispatcher 的终态事件重放一遍，就能重建当前的完成集合，再调用 ",[1462,2343,1780],{}," 继续推进。这天然满足幂等——同一批事件重放多次，结果相同。这就是事件溯源的基本思路，对应 durable execution 的重放语义",[1237,2346,1649],{"href":1647,"rel":2347},[1241],[1869,2349,2350],{"id":2350},"校验机制",[1098,2352,2353],{},"DAG 上线前经过两道校验：",[1098,2355,2356,2359],{},[1130,2357,2358],{},"提交时静态校验。"," 由纯 DAG 库直接拒绝非法图：环检测（DAG 不能有环）、依赖可达性（每个节点的上游必须存在）、GATE 表达式可解析（判定表达式语法正确）。这些检查不涉及任何执行，纯图论操作。",[1098,2361,2362,2365,2366,2368,2369,2372],{},[1130,2363,2364],{},"Dry-run 模拟。"," 借 OrchBench 的思路，用一个 mock 掉 liskin 的模拟器给每个 AGENT 节点喂\"成功\u002F失败\u002F超时\"的合成终态，跑一遍 ",[1462,2367,1780],{}," 推进，沿依赖正确性、无冗余派单、无死锁等维度校验，并检查失败时的阻断与补偿路径符合预期",[1237,2370,1638],{"href":1636,"rel":2371},[1241],"。在真跑前抓出编排 bug。",[1098,2374,2375],{},"OGAS-Flow 的定义—校验—推进闭环如下：",[2377,2378],"mermaid",{"code":2379},"flowchart TB\n    classDef def fill:#eff6ff,stroke:#3b82f6,color:#1e3a8a\n    classDef flow fill:#f5f3ff,stroke:#8b5cf6,color:#4c1d95\n    classDef check fill:#fef9c3,stroke:#ca8a04,color:#713f12\n    classDef disp fill:#ecfdf5,stroke:#10b981,color:#064e3b\n\n    Def[\"DAG 定义 (YAML, 进 Git)\u003Cbr\u002F>AGENT \u002F GATE \u002F JOIN 节点\"]:::def\n    Val[\"提交时校验\u003Cbr\u002F>环检测 + 依赖可达 + 表达式解析\"]:::check\n    Sim[\"dry-run 模拟器 (mock liskin)\u003Cbr\u002F>OrchBench 六维度校验\"]:::check\n    Engine[\"OGAS-Flow 推进引擎\u003Cbr\u002F>next_ready() 纯函数 + 事件溯源\"]:::flow\n    Disp[\"OGAS-Dispatcher\u003Cbr\u002F>facade API 派单 \u002F 终态事件流\"]:::disp\n\n    Def --> Val --> Sim --> Engine\n    Engine -->|\"派 ready 节点\"| Disp\n    Disp -->|\"Completed \u002F 重试耗尽 \u002F Cancelled 事件\"| Engine\n    Engine -->|\"GATE: ask 人工确认\"| Disp",[1869,2381,2382],{"id":2382},"库选型",[1098,2384,2385],{},"MVP 走轻量组合，扩张期再换重引擎。",[1134,2387,2388,2401],{},[1137,2389,2390],{},[1140,2391,2392,2395,2398],{},[1143,2393,2394],{},"关注点",[1143,2396,2397],{},"第一版选择",[1143,2399,2400],{},"理由",[1153,2402,2403,2414,2425,2436],{},[1140,2404,2405,2408,2411],{},[1158,2406,2407],{},"图结构校验",[1158,2409,2410],{},"纯 DAG 库",[1158,2412,2413],{},"只需环检测和拓扑排序，不需要执行引擎",[1140,2415,2416,2419,2422],{},[1158,2417,2418],{},"事件存储",[1158,2420,2421],{},"复用 Dispatcher 的 Postgres",[1158,2423,2424],{},"不引入新依赖",[1140,2426,2427,2430,2433],{},[1158,2428,2429],{},"推进逻辑",[1158,2431,2432],{},"自写纯函数",[1158,2434,2435],{},"逻辑简单，不值得上重型框架",[1140,2437,2438,2441,2444],{},[1158,2439,2440],{},"何时升级",[1158,2442,2443],{},"需要条件分支\u002F并行汇聚\u002F自动补偿时",[1158,2445,2446],{},"换成 Temporal\u002FCadence 等引擎",[1098,2448,2449,2450,1295],{},"第一版采用\"纯 DAG 数据结构库（只负责图正确性：顶点\u002F边、环检测、拓扑\u002F祖先后代查询，不含执行或调度）+ 复用 Dispatcher 的 Postgres（事件溯源存储）+ 纯函数推进器\"的组合。线性串联是 DAG 的退化形态，这套组合的风险面最小，而 Conductor 已证明\"确定 + 声明式 + 复用现有基础设施\"的轻量路线在生产可行",[1237,2451,1627],{"href":1625,"rel":2452},[1241],[1098,2454,2455,2456,1295],{},"后续迭代会考虑迭代条件分支、并行汇聚、自动补偿回滚相关的需求，会再升级为 durable execution 引擎（Temporal\u002FCadence 一类），把飞行状态、定时器、重放、saga 补偿交给引擎，并基于自建 workflow\u002Factivity 骨架",[1237,2457,1649],{"href":1647,"rel":2458},[1241],[1869,2460,2461],{"id":2461},"设计纪律",[1098,2463,2464,2465,2468],{},"编排不碰 Agent 内部。这条纪律的具体含义是：OGAS-Flow 节点不去干预 Agent 内部步骤，不把 Harness 状态当 DAG 状态。文献给出的解法与我们的取向一致——把编排做成确定性、零推理的一层，不确定性全部关进 AGENT 节点内部，GATE\u002FJOIN 只做确定判定与汇聚",[1237,2466,1627],{"href":1625,"rel":2467},[1241],"。第一版刻意做窄——只做线性串联和简单依赖解锁，不上条件分支、并行汇聚、自动补偿回滚，等任务粒度和失败语义在真实使用中稳定后再扩。",[1229,2470,2472],{"id":2471},"_45-知识面ogas-arkhiv","4.5 知识面：OGAS-Arkhiv",[1098,2474,2475],{},[1667,2476],{"alt":1669,"src":2477},"https:\u002F\u002Fpicx.zhimg.com\u002Fv2-967b67f7dae3038cd09f004446cc33f5_r.jpg",[1098,2479,2480],{},"OGAS-Arkhiv 是业务知识库 MCP Server。它解决的问题是：编码 Agent 自带的代码侧检索只能理解代码结构，但无法理解 PRD 里写的\"为什么要这么做\"、接口契约里写的\"这个字段代表什么\"、UI 规范里写的\"这个组件长什么样\"、以及历史决策记录里的\"为什么选了方案 A 而不是方案 B\"。OGAS-Arkhiv 补上这块业务侧知识。",[1098,2482,2483,2484,2486],{},"OGAS-Arkhiv 功能实现可参考 EagleRAG ，复用底层检索能力（Milvus 向量检索）。EagleRAG 已经是一个成熟的 MCP Server，提供 streamable HTTP 的 ",[1462,2485,1513],{}," 端点和 stdio 两种接入方式，核心工具覆盖 ingest\u002Fquery\u002Fretrieve，并用 plugin_namespace 到 Milvus 的映射做多租户隔离。相关工作集中在两方面：",[1376,2488,2489,2495],{},[1379,2490,2491,2494],{},[1130,2492,2493],{},"权限封装","：在 EagleRAG 的 plugin_namespace 机制上叠加团队\u002Fworkspace 级别的权限控制，确保不同业务线的知识库隔离。",[1379,2496,2497,2500],{},[1130,2498,2499],{},"命名空间管理","：把 PRD、接口契约、UI 规范、历史决策等不同类型的文档组织成结构化的命名空间，方便 Agent 按需检索。",[1869,2502,2504],{"id":2503},"与-liskin-的对接方式","与 liskin 的对接方式",[1098,2506,2507,2508,2510,2511,2513,2514,2516],{},"OGAS-Arkhiv 以 MCP Server 形态常驻，通过 liskin 的 ",[1462,2509,1476],{}," 注入。liskin 在执行编码任务时，可以通过 MCP client 调用 Arkhiv 的 retrieve 工具，查询与当前任务相关的业务知识。这个对接对 Dispatcher 完全透明——Arkhiv 的 MCP 端点配在 Agent 级的 ",[1462,2512,1714],{}," 里，Daemon 在 spawn ",[1462,2515,1725],{}," 时原样带下去。",[1229,2518,2520],{"id":2519},"_46-部署面vercel-集成","4.6 部署面：Vercel 集成",[1869,2522,2523],{"id":2523},"是什么",[1098,2525,2526],{},"部署面是 OGAS 全链路的最后一环。它解决的问题是：代码推上去之后，怎么确保坏版本不上线，以及坏版本漏过之后怎么快速回滚。部署门在 OGAS-Flow 里被建模成一个 GATE 节点——它只是 DAG 中的一个确定性检查点，不是独立于编排面的组件。",[1869,2528,2529],{"id":2529},"发布门设计",[1098,2531,2532],{},"第一道防线放在发布前拦截。具体做法是把 liskin 的验证结果接到 Vercel 的 Deployment Checks 上，配成阻塞式检查：代码推上去、Vercel 构建完成后，在域名分配之前，先由 liskin 跑一轮验证（测试、lint、类型检查等），验证通过 check 才放行，不通过就把这个生产构建卡在门外，坏版本压根不会上线。整个交互是事件驱动的——Vercel 发出 deployment.created\u002Fready 等 webhook，OGAS 这边接住、触发 liskin 验证、再把结论通过 Checks API 回写。这道发布门在 OGAS-Flow 里正是一个 GATE 节点。",[1869,2534,2535],{"id":2535},"回滚与降级机制",[1098,2537,2538,2539,2541,2542,2545,2546,2548],{},"触发回滚走 ",[1462,2540,2186],{},"，把域名瞬间指回上一个健康部署，不重新构建",[1237,2543,1580],{"href":1578,"rel":2544},[1241],"。但要在流程里显式记住那个坑：回滚后自动分配被 pin 住了，后续想恢复正常发布得走 ",[1462,2547,1590],{},"，这一步写进 runbook，防止部署莫名其妙不生效。Check 的超时行为（超时放行还是拦截）允许各项目按风险等级自行配置，不做全局硬编码。",[1098,2550,2551],{},"回滚本身是高危操作，在 OGAS-Flow 里落成 GATE 节点——必须人工确认后才执行。确认通过 Gate 的双向 ask 通道回流到飞书群提示，但实际的确认动作不在群消息里完成，而是跳转到有更强身份校验的界面。",[1869,2553,2554],{"id":2554},"部署闭环时序",[2377,2556],{"code":2557},"sequenceDiagram\n    participant Dev as liskin(执行内核)\n    participant GH as GitHub\n    participant VC as Vercel\n    participant OGAS as OGAS-Dispatcher\u002FGate\n    participant Human as 审批人(飞书)\n\n    Dev->>GH: push 代码\n    GH->>VC: 触发构建\n    VC-->>OGAS: webhook deployment.created\u002Fready\n    OGAS->>Dev: 触发 liskin 验证(测试\u002Flint\u002F类型)\n    alt 验证通过\n        Dev-->>OGAS: pass\n        OGAS->>VC: Checks API 回写 success(放行)\n        VC->>VC: 分配生产域名(上线)\n    else 验证失败\n        Dev-->>OGAS: fail\n        OGAS->>VC: Checks API 回写 failure(拦截)\n        Note over VC: 生产构建卡在门外,不上线\n    end\n    opt 坏版本漏过 → 兜底回滚\n        OGAS->>Human: ask 确认回滚(human-in-the-loop)\n        Human-->>OGAS: 确认\n        OGAS->>VC: vercel rollback(域名指回上一健康版)\n        Note over VC: 自动分配被 pin,需 vercel promote 恢复\n    end",[1112,2559],{},[1115,2561,2562],{"id":2562},"推进计划",[1098,2564,2565],{},"考虑到复杂度，OGAS 落地严格分三阶段推进。每阶段都有独立价值、可各自验收，任何一阶段不达标都可以停在原地而不影响已交付部分。三阶段的推进与回退关系如下：",[2377,2567],{"code":2568},"flowchart LR\n    classDef p fill:#ecfdf5,stroke:#10b981,color:#064e3b\n    classDef r fill:#fef2f2,stroke:#ef4444,color:#7f1d1d\n\n    P1[\"阶段一\u003Cbr\u002F>OGAS-Arkhiv + liskin\u003Cbr\u002F>验证懂业务\"]:::p\n    P2[\"阶段二\u003Cbr\u002F>OGAS-Dispatcher + OGAS-Gate + GitHub\u003Cbr\u002F>协作可见\"]:::p\n    P3[\"阶段三\u003Cbr\u002F>Vercel 发布门 + OGAS-Flow\u003Cbr\u002F>闭合全链路\"]:::p\n\n    P1 --> P2 --> P3\n\n    P3 -.->|\"发布门不稳→关 Check,回人工审批\"| P2\n    P3 -.->|\"OGAS-Flow 失控→停编排,回逐个手动派单\"| P2\n    P2 -.->|\"Dispatcher 合规受阻→回单机 agent chat\"| P1",[1229,2570,2572],{"id":2571},"阶段一验证-agent-懂业务","阶段一：验证 Agent 懂业务",[1098,2574,2575,2578],{},[1130,2576,2577],{},"目标"," 先把执行面的核心假设跑通，不碰团队协作和编排。只回答\"Agent 懂不懂业务\"这一个问题。",[1098,2580,2581,2584,2585,2588,2589,2591,2592,1295],{},[1130,2582,2583],{},"做什么"," 单独部署 OGAS-Arkhiv，把一个真实业务线的 PRD 和接口文档灌进去，用 liskin 的 ",[1462,2586,2587],{},"agent chat"," 手动验证它能通过 MCP 查到并用上这些业务知识。主要工作量在给 liskin 补 ",[1462,2590,1476],{}," 的 MCP client 实现——这是它路线图里\"价值最大但尚未交付\"的一项",[1237,2593,1485],{"href":1483,"rel":2594},[1241],[1098,2596,2597,2600],{},[1130,2598,2599],{},"验收标准"," Agent 生成的代码显著贴合业务规范——具体表现为：Agent 在生成代码时能正确引用 PRD 中定义的接口契约，不出现对业务术语的臆测，生成结果经人工 review 确认业务逻辑正确率显著提升。",[1098,2602,2603,2606],{},[1130,2604,2605],{},"失败回退"," 停在这一阶段不影响任何已交付部分。即使 MCP client 未补齐，liskin 仍可独立使用，只是没有业务知识注入。",[1229,2608,2610],{"id":2609},"阶段二协作可见","阶段二：协作可见",[1098,2612,2613,2615],{},[1130,2614,2577],{}," 接入控制面和团队入口，让协作可见。",[1098,2617,2618,2620],{},[1130,2619,2583],{}," 自托管 OGAS-Dispatcher，把 liskin 接成一个 runtime（即 4.2 节描述的 liskin provider），再接 GitHub MCP 让 Agent 从 issue 领任务、开 PR，同时上 OGAS-Gate 把任务创建和状态回流搬进群。这一阶段不涉及跨任务编排，也不接生产部署。",[1098,2622,2623,2625],{},[1130,2624,2599],{}," 团队在群里能看见并指派 Agent 干活——具体表现为：成员在飞书群 @机器人 指派任务后，Agent 自动执行并实时回流状态，终态结果可见、可 review。",[1098,2627,2628,2630,2631,2633],{},[1130,2629,2605],{}," 如果 Dispatcher 合规受阻（Multica 许可证问题），回退到阶段一的单机 ",[1462,2632,2587],{}," 模式，不影响已验证的业务知识注入能力。",[1229,2635,2637],{"id":2636},"阶段三闭合全链路","阶段三：闭合全链路",[1098,2639,2640,2642],{},[1130,2641,2577],{}," 打通部署与编排，闭合全链路。",[1098,2644,2645,2647],{},[1130,2646,2583],{}," 接 Vercel，把 liskin 的验证接成 Deployment Checks 发布门（GATE 节点）、把回滚设为人工确认的应急手段；同时上线第一版窄范围的 OGAS-Flow（仅线性串联），消费 Dispatcher 的 Completed 事件解锁下游，并在 DAG 上线前先跑一遍 dry-run 模拟校验。",[1098,2649,2650,2652],{},[1130,2651,2599],{}," 一串有依赖的任务能自动跑完并安全上线——具体表现为：从 issue 创建到 Vercel 部署上线的全链路自动执行，发布门拦截坏版本，回滚需人工确认且 pin 状态有告警。",[1098,2654,2655,2657],{},[1130,2656,2605],{}," 如果发布门不稳定，关掉 Check 回人工审批；如果 OGAS-Flow 失控，停编排回逐个手动派单。两者都不影响阶段二已交付的协作可见能力。",[1112,2659],{},[1115,2661,2662],{"id":2662},"其他关注点",[1229,2664,2666],{"id":2665},"dag状态","DAG状态",[1098,2668,2669],{},"在 Agent core 外自建一层 DAG，一旦分层没守住，整套系统会变成一个难以调试的分布式状态泥潭。具体有两个陷阱：",[1098,2671,2672,2675,2676,2678],{},[1130,2673,2674],{},"其一，别把 liskin 的 Harness 状态当成 Dispatcher 的任务状态。"," liskin 自带 Harness 长任务框架，状态落在 ",[1462,2677,1468],{}," 里、节点可中断可恢复，那是任务内部的容错；Dispatcher 的状态机是任务粒度的（一个 task = 一次 liskin exec）。这两层必须解耦——Dispatcher 只看到\"这个 task 在 running \u002F 完成了\"，liskin 内部跑了多少步是它自己的事。",[1098,2680,2681,2684],{},[1130,2682,2683],{},"其二，别让 Dispatcher 承担编排。"," 跨任务 DAG 是 OGAS-Flow 的职责，Dispatcher 只提供\"单 issue 状态机\"这块原子能力，Flow 坐在其上消费 Completed 事件来解锁下游，Dispatcher 对 DAG 的存在应当是无感的。如果让 Flow 节点去干预 Agent 内部步骤，或把 Harness 状态当 DAG 状态，上下层调度就会撞车，系统退化成分布式状态泥潭。这是自研部分里技术风险最高的一块。",[1098,2686,2687,2688,2691,2692,1295],{},"文献给出的解法与我们的取向一致：把编排做成确定性、零推理的一层，不确定性全部关进 AGENT 节点内部，GATE\u002FJOIN 只做确定判定与汇聚",[1237,2689,1627],{"href":1625,"rel":2690},[1241],"。据此，第一版刻意做窄——只做线性串联和简单依赖解锁，不上条件分支、并行汇聚、自动补偿回滚，等任务粒度和失败语义在真实使用中稳定后再扩；同时用提交时校验加 dry-run 模拟，在真跑前把 DAG 的依赖正确性验掉",[1237,2693,1638],{"href":1636,"rel":2694},[1241],[1229,2696,2697],{"id":2697},"部署安全",[1098,2699,2700,2701,2704],{},"让 Agent 有能力触发生产回滚、promote 覆盖线上，本身是高危操作。叠加回滚后\"钉住\"部署的反直觉状态",[1237,2702,1580],{"href":1578,"rel":2703},[1241],"，如果确认档配置不当或 Agent 误判，可能造成线上服务对象错乱。解决方案是把这类动作硬性设为 ask 人工确认（在 OGAS-Flow 里落成 GATE 节点），并把 pinned 状态显式落盘、在飞书群里高亮告警。高危操作的确认动作不在群消息里完成，而是跳转到有更强身份校验的界面。",[1229,2706,2707],{"id":2707},"端到端可观测性",[1098,2709,2710],{},"OGAS 的链路又长（OGAS-Gate → OGAS-Flow → OGAS-Dispatcher → Daemon → liskin → MCP 工具），一旦某个环节出问题，定位会很痛。这要求我们在自研部分就把结构化日志和 trace 串起来，而不是事后补。每一层都应该在请求入口打上 trace ID，逐层传递，使得一个任务从飞书消息到 Vercel 部署的完整链路可追溯。",[1229,2712,2713],{"id":2713},"执行机形态",[1098,2715,2716],{},"执行机的形态需要拍板：是人手一台常驻开发机各跑守护进程，还是内网集中搭几台专用执行机？后者的资源隔离、多任务抢占、运维归属都要有人认领。这直接影响 Dispatcher 的部署拓扑与 Daemon 注册策略。如果是人手一台，Daemon 注册策略相对简单（每台机器自注册自己的 runtime）；如果是集中执行机，需要设计资源池管理和任务排队策略。这个问题需要在阶段二启动前确定。",[1229,2718,2719],{"id":2719},"语言选型",[1098,2721,2722,2723,2726,2727,2730],{},"OGAS-Flow 的实现取向已基本收敛：不从零手搓、也不上重型编排器，而是走\"纯 DAG 库负责图 + Dispatcher 的 Postgres 负责事件溯源 + 纯函数推进器\"的轻量组合，第一版窄到只做线性串联与简单依赖解锁，把节点显式分成 AGENT\u002FGATE\u002FJOIN 三类、并在上线前用 dry-run 模拟校验依赖正确性",[1237,2724,1638],{"href":1636,"rel":2725},[1241],"；扩到条件分支、并行汇聚、自动补偿时再升级为 durable execution 引擎",[1237,2728,1649],{"href":1647,"rel":2729},[1241],"。仍待定的是和实际业务场景对齐——线性串联覆盖多少真实场景？是否有早期就需要并行汇聚的链路？",[1229,2732,2734],{"id":2733},"gate-交互协议","Gate 交互协议",[1098,2736,2737],{},"OGAS-Gate 的交互协议需要定义：哪些操作允许在群里直接触发（建 issue、指派、查状态大概率可以），哪些高危操作（触发生产回滚、promote）必须跳转到有更强身份校验的界面而非群消息一句话搞定。这与第四节 ask 双向通道、以及 OGAS-Flow 的 GATE 节点落点一致。具体的跳转目标界面（飞书内嵌 H5 审批页？独立 Web 审批系统？）和身份校验强度也需要定义。",[1112,2739],{},[1115,2741,2743],{"id":2742},"references","References",[2745,2746,2747,2753,2759,2765,2771,2777,2783,2789,2795,2801,2807,2813,2819,2825,2831,2837,2843,2849,2855,2861,2867,2873,2879,2885],"ol",{},[1379,2748,2749],{},[1237,2750,2752],{"href":1239,"rel":2751},[1241],"面向大型代码库的 Claude Code 团队落地经验",[1379,2754,2755],{},[1237,2756,2758],{"href":1246,"rel":2757},[1241],"AI 编码智能体在遗留代码库上的实践",[1379,2760,2761],{},[1237,2762,2764],{"href":1252,"rel":2763},[1241],"Claude Code 在大型代码库里的工程实践",[1379,2766,2767],{},[1237,2768,2770],{"href":1265,"rel":2769},[1241],"Exploring Hallucinations in LLM-Generated Code",[1379,2772,2773],{},[1237,2774,2776],{"href":1271,"rel":2775},[1241],"Coding Guidelines for Your AI Agents",[1379,2778,2779],{},[1237,2780,2782],{"href":1280,"rel":2781},[1241],"Mindlas 实时捕捉上下文腐烂",[1379,2784,2785],{},[1237,2786,2788],{"href":1286,"rel":2787},[1241],"AI Agent 落地痛点:长上下文压缩导致任务链断裂",[1379,2790,2791],{},[1237,2792,2794],{"href":1292,"rel":2793},[1241],"Effective harnesses for long-running agents",[1379,2796,2797],{},[1237,2798,2800],{"href":1301,"rel":2799},[1241],"Closing the AI trust gap for developers",[1379,2802,2803],{},[1237,2804,2806],{"href":1313,"rel":2805},[1241],"Agentic AI 可观测性",[1379,2808,2809],{},[1237,2810,2812],{"href":1319,"rel":2811},[1241],"Agent 协作过程模型",[1379,2814,2815],{},[1237,2816,2818],{"href":1332,"rel":2817},[1241],"USEagent: Unified Software Engineering Agent",[1379,2820,2821],{},[1237,2822,2824],{"href":1338,"rel":2823},[1241],"工业界 Agent 落地实践",[1379,2826,2827],{},[1237,2828,2830],{"href":1344,"rel":2829},[1241],"Agent 工作流管理",[1379,2832,2833],{},[1237,2834,2836],{"href":1483,"rel":2835},[1241],"liskin_code_agent Readme",[1379,2838,2839],{},[1237,2840,2842],{"href":1543,"rel":2841},[1241],"Multica:把 AI Agent 真正接入团队协作流",[1379,2844,2845],{},[1237,2846,2848],{"href":1549,"rel":2847},[1241],"Install an agent runtime",[1379,2850,2851],{},[1237,2852,2854],{"href":1578,"rel":2853},[1241],"Instant Rollback",[1379,2856,2857],{},[1237,2858,2860],{"href":1614,"rel":2859},[1241],"Agint: Agentic Graph Compilation for Software Engineering Agents",[1379,2862,2863],{},[1237,2864,2866],{"href":1625,"rel":2865},[1241],"Conductor: Deterministic orchestration for multi-agent AI workflows",[1379,2868,2869],{},[1237,2870,2872],{"href":1636,"rel":2871},[1241],"OrchBench: Evaluating Multi-Agent Orchestration Plans in Isolation via Deterministic Simulation",[1379,2874,2875],{},[1237,2876,2878],{"href":1647,"rel":2877},[1241],"Why Temporal replaces traditional state machines for distributed applications",[1379,2880,2881],{},[1237,2882,2884],{"href":1977,"rel":2883},[1241],"Multica:多机器多 Agent 任务管理",[1379,2886,2887],{},[1237,2888,2890],{"href":1537,"rel":2889},[1241],"Multica — Project Management for Human + Agent Teams",{"title":1669,"searchDepth":2892,"depth":2892,"links":2893},4,[2894,2896,2902,2907,2914,2922,2957,2962,2970],{"id":1117,"depth":2895,"text":1117},2,{"id":1224,"depth":2895,"text":1224,"children":2897},[2898,2900,2901],{"id":1231,"depth":2899,"text":1232},3,{"id":1306,"depth":2899,"text":1307},{"id":1325,"depth":2899,"text":1326},{"id":1351,"depth":2895,"text":1351,"children":2903},[2904,2905,2906],{"id":1354,"depth":2899,"text":1355},{"id":1370,"depth":2899,"text":1371},{"id":1405,"depth":2899,"text":1406},{"id":1440,"depth":2895,"text":1440,"children":2908},[2909,2910,2911,2912,2913],{"id":1446,"depth":2899,"text":1447},{"id":1504,"depth":2899,"text":1505},{"id":1528,"depth":2899,"text":1529},{"id":1565,"depth":2899,"text":1566},{"id":1599,"depth":2899,"text":1600},{"id":1657,"depth":2895,"text":1657,"children":2915},[2916,2917,2918,2919,2920,2921],{"id":1673,"depth":2899,"text":1674},{"id":1683,"depth":2899,"text":1684},{"id":1697,"depth":2899,"text":1698},{"id":1718,"depth":2899,"text":1719},{"id":1760,"depth":2899,"text":1761},{"id":1795,"depth":2899,"text":1796},{"id":1810,"depth":2895,"text":1810,"children":2923},[2924,2925,2930,2934,2939,2948,2951],{"id":1819,"depth":2899,"text":1820},{"id":1858,"depth":2899,"text":1859,"children":2926},[2927,2928,2929],{"id":1871,"depth":2892,"text":1871},{"id":1877,"depth":2892,"text":1877},{"id":1930,"depth":2892,"text":1930},{"id":1939,"depth":2899,"text":1940,"children":2931},[2932,2933],{"id":1957,"depth":2892,"text":1957},{"id":1988,"depth":2892,"text":1988},{"id":2114,"depth":2899,"text":2115,"children":2935},[2936,2937,2938],{"id":2126,"depth":2892,"text":2127},{"id":2150,"depth":2892,"text":2151},{"id":2201,"depth":2892,"text":2201},{"id":2230,"depth":2899,"text":2231,"children":2940},[2941,2942,2943,2944,2945,2946,2947],{"id":2242,"depth":2892,"text":1871},{"id":2275,"depth":2892,"text":2275},{"id":2310,"depth":2892,"text":2310},{"id":2326,"depth":2892,"text":2326},{"id":2350,"depth":2892,"text":2350},{"id":2382,"depth":2892,"text":2382},{"id":2461,"depth":2892,"text":2461},{"id":2471,"depth":2899,"text":2472,"children":2949},[2950],{"id":2503,"depth":2892,"text":2504},{"id":2519,"depth":2899,"text":2520,"children":2952},[2953,2954,2955,2956],{"id":2523,"depth":2892,"text":2523},{"id":2529,"depth":2892,"text":2529},{"id":2535,"depth":2892,"text":2535},{"id":2554,"depth":2892,"text":2554},{"id":2562,"depth":2895,"text":2562,"children":2958},[2959,2960,2961],{"id":2571,"depth":2899,"text":2572},{"id":2609,"depth":2899,"text":2610},{"id":2636,"depth":2899,"text":2637},{"id":2662,"depth":2895,"text":2662,"children":2963},[2964,2965,2966,2967,2968,2969],{"id":2665,"depth":2899,"text":2666},{"id":2697,"depth":2899,"text":2697},{"id":2707,"depth":2899,"text":2707},{"id":2713,"depth":2899,"text":2713},{"id":2719,"depth":2899,"text":2719},{"id":2733,"depth":2899,"text":2734},{"id":2742,"depth":2895,"text":2743},"OGAS 是一个自托管的 Agent 研发生命周期协作平台。它让整个团队能以受控、可编排、可回滚的方式驱动 Agent，从一个需求的知识检索，一路自动推进到代码交付和线上部署。","md",true,{"uuid":2975,"abblink":2976,"slots":2977},"b8d70910-c4f4-11f4-21bd-26018b9748b8","c1xwawys451",{},45,{"title":1085,"description":2971},"posts\u002FRFC_Agentic_project\u002F2026-07-25-[RFC]-Glushkov_OGAS",[303],"ytfGKZ_yexxlLXucBj96pvc3CnibLhC4vJwRrKlHoD4",1790443282507]