故障演练不是乱炸——最小半径、可观测、可回滚、有预案、分批次，五道闸把火控制在盆里

上一篇我们聊了搬进新家第一件事是做消防演习——不是开香槟是找灭火器在哪、试烟感器响不响、看逃生通道通不通。敢拉警铃是心智上的转折。但拉警铃之后呢你总不能在客厅中央点一把火说开始演习吧真点了——那不是演习是纵火是拿着全家人的安全赌运气。故障演练不是乱炸——是在你能灭掉的范围内点一团你能看见的火。这一篇卷袖子干活。我给你讲五道闸——最小半径、可观测、可回滚、有预案、分批次——一道一道落下来把火控制在防火盆里、控制在厨房里、控制在你伸手就能够到灭火器的范围里。五道闸焊死你就敢在自己家点火了。往下读。这篇比上篇长因为工程落地的细节偷一个懒就是一颗定时炸弹。一、为什么 Netflix 敢在生产随便杀机器你不敢你肯定听过那个故事——Netflix 做了个 Chaos Monkey工作日白天随机杀生产环境的机器。杀了一年2012 年平安夜 AWS 大面积故障Netflix 的工程师在家过圣诞系统自己切走流量用户看剧一点没耽误。听完你什么反应“牛。”“我们做不到。”“他们技术强人多钱多。”“我们这业务哪敢这么玩。”错。Netflix 敢在生产杀机器不是因为他们牛——而是因为他们有五道闸。不是勇气问题是纪律问题。猴子乱杀到数据库主库怎么办杀了回不来怎么办杀一半监控看不到怎么办不敢。他们比谁都清楚——没有闸的火不叫演习叫灾难。某团队第一次做演练觉得既然要演就演个大的直接断了整个核心机房的网。他们觉得自己有多可用区流量应该能自动切走。结果呢切换脚本半年没跑过数据库 IP 硬编码在备库配置里负载均衡健康检查间隔太长等了四十秒才发现应用连接池没配重连全死等老连接。全量业务挂了两小时。本来是演习演完变成 P0 事故。问题出在哪他们以为故障演练就是炸一下看看。不是。故障演练的核心从来不是敢不敢炸——而是炸了能不能收住。试灭火器——是点燃沙发看能不能灭整个客厅还是在厨房水池里放个铁盆、盆里点一小团纸、对着纸喷一下正常人都选后者。不是因为后者不刺激——而是前者灭不住就是火灾后者灭不住大不了水一冲。Netflix 敢在白天杀机器是因为他们已经做了无数次水池里点纸团——从单机、单实例、单服务一路杀到单可用区。杀了一年盆里的火每次都能灭他们才敢在更大的盆里点火。他们不是不怕炸——而是把炸了收不住的可能性用五道闸挡在了门外。这五道闸一道都不能少。第一道不过不准进第二道。二、第一道闸最小半径——在防火盆里点火不在客厅放野火第一道闸最根本——爆炸半径。故障演练不是比谁胆子大——而是比谁能把火点得够小又够准。爆炸半径就是注入故障后最坏影响多少用户、多少业务、多少数据。半径越小越好小到就算灭不掉也不会有真用户受影响。从一粒火星开始最早的 Chaos Monkey 只杀单机单实例——一个服务跑十台只杀一台看负载均衡能不能切走、新实例能不能拉起来、用户有没有感知。单机杀了三个月每次都能自动恢复才敢杀一个服务一个服务杀了半年才敢杀一个可用区杀可用区又练了半年——才有了平安夜那次工程师在家过圣诞。这不是保守——这是纪律。你想试烟感器响不响不会真放一把火而是拿一根冒烟的香凑到烟感器底下看它响不响。用一粒火星验证警报不用一场大火。一上来就拔机房电源是自杀前面反面教材——第一次演练直接断整个核心机房这不是勇敢是把所有鸡蛋从十楼扔下去看有没有不碎的。更常见的新手错误第一次演练主从切换就在高峰时段全量生产上做。结果切换成功了应用连接池没配重连连不上新主库业务挂了四十分钟。这不是演练的错——是半径选错了。正确分五步测试环境单从库→测试环境主从切换→预发切换→生产凌晨单从库模拟故障→生产凌晨手动切换。五步走完脚本跑过七八遍你心里才有底才敢白天做。起点小到灭不掉也没事逐级扩大每一级都有上一级的信心做底——这才叫最小半径。用白名单焊死半径工程上控制爆炸半径不靠大家小心点——靠系统。主流混沌工具都支持按 namespace、label、白名单控制范围RBAC 权限隔离Chaos Mesh 默认不开启、显式打标才注入、默认什么都不炸。这叫安全默认值——不配置就是安全的配错了最多炸你选的那一小撮。翻译成家里的话——你点防火盆会把盆放水池里周围没可燃物手边就是水龙头。不是放餐桌中央旁边堆着报纸离窗帘半米远。防火盆放水池里——哪怕灭火器坏了水一开就灭。这才叫最小半径。最小半径不是怂——而是对你的业务、用户、和凌晨三点被电话叫醒的同事负责。三、第二道闸可观测打底——没装烟感器别点火烟感器、燃气报警器、温度计装好了你才知道家里有没有出事。没有它们就点火——火着没着你都看不见。没装监控就做故障演练不是演练——是蒙着眼拆炸弹。看不见 盲炸我见过最离谱的演练——主从切换完数据库层看一眼监控说切换成功所有人鼓掌准备喝咖啡。四十分钟后客服炸锅用户全打不开页面。数据库是切过去了但应用连接池用的老 IP 连不上新主库。数据库层监控说我这没问题应用层没看、业务指标没人盯。四十分钟错误率 100%但没人看成功率——全盯着数据库切成功了没。数据库切成功有什么用用户根本用不了。这就像厨房里只装了看煤气罐压力的表没装烟感器——煤气罐没炸但一氧化碳已经弥漫了还在那说压力正常。故障注入了但你看不见系统什么状态——这就是盲炸。三大件指标、日志、追踪前面聊可观测性讲过三大支柱指标、日志、追踪。三大件演练前必须全部到位。指标 电表、水表、燃气表 烟感器 温度计。一眼扫过去就知道家里正常不正常。演练前必须备齐五类指标业务黄金指标请求量/成功率/P99 延迟——这三个直接代表用户体验异常无条件停、系统资源CPU/内存/磁盘/IO、服务健康实例数/重启、依赖健康DB/缓存/MQ、用户侧指标端到端成功率/页面打开时间。日志 家里的日记本。什么时候换的电池、上次煤气报警器什么时候响的——都在里面。演练前日志必须结构化——每个字段清晰、能按 trace_id 串、能按时间排序不然出事翻半小时找不到哪行是哪次请求。追踪 顺丰快递单。一个请求从进网关到返回经过哪些服务、每站花多久、在哪步报错——trace_id 一串到底清清楚楚。追踪必须从网关到最后一个数据库查询全部打通不然你只知道请求慢了不知道慢在哪。一条业务指标是红线五类指标里业务黄金指标是绝对红线。成功率掉一个点、P99 延迟翻倍、请求量骤降——任何一个越阈值不需要讨论、不需要请示、不需要再观察一下——立刻停。烟感器一响你第一反应不是我先看看是不是真着火是立刻拿灭火器、关煤气、带家人往门口走。万一是误报虚惊一场万一是真着火犹豫三十秒就是生与死的差距。红色按钮所有人都有权按。包括最资历浅的实习生不需要请示领导、不需要等负责人、不需要确认了再说。宁可误停十次不可硬撑一秒。误停了大不了重新演一次没成本硬撑一秒就是真事故。监控没建好别点火有人说先演练演练中缺什么监控再补。这是错的。这就像先点火点着了再去买烟感器——等买回来房子已经烧没了。正确顺序是先把监控建好、验证监控是准的、确认告警能发到人——再点火。怎么验证准人为造已知故障——手动杀一个测试实例看监控能不能 30 秒内报警、能不能准确告诉你哪个实例挂了、追踪能不能查到哪些请求受影响。能——可以点火不能——回去补监控。烟感器没电就别点火监控没建好就别演练——看不见的火最可怕。四、第三道闸一键回滚——灭火器必须在演练前试过能用你家厨房挂着个崭新的红色灭火器你从来没用过。它真能灭火吗“应该能吧压力指针在绿区。”应该等真着火了你拔保险销发现销子锈死拔不动或者按下去喷不出来或者喷出来方向不对喷不到火根。这时候再说应该能——来不及了。回滚按钮没试过能不能按等于没有回滚。总水阀锈死的故事老运维张哥跟我讲过一个让他养成每季度拧一次总阀门习惯的事故。那年大促前做水管扩容师傅钻到主水管水哗地喷出来。张哥冲去水阀井拧总阀——拧不动锈死了十年没人动过。水喷了四十分钟直到自来水公司关整栋楼总阀机房泡了半间大促前一天全站停了六小时。总水阀不是没有——而是从来没试过能不能拧动。故障演练的回滚按钮就是这个总水阀——注入故障之前你必须亲手按一次终止按钮确认它真的能停、能恢复、能在十秒内把火灭掉。一键终止三原则第一TTL 自动到期。任何故障都必须设自动过期时间——注入 5 分钟延迟5 分钟一到不管你在不在故障自动消失。怕你电脑死机、SSH 断了、人突然拉肚子离开工位——时间一到火自己灭。就像防火盆旁边放个定时水龙头五分钟自动开水哪怕你接电话忘了这茬也不怕。第二一键终止按钮真的好用。一条命令、一个 API、一个按钮按下去立刻停止恢复原状。不能藏在三层菜单后面不能需要改三个配置不能需要重启服务。而且——演练开始之前在测试环境真的按一次。确认它能停、停得干净、没有残留。很多团队回滚脚本是写了——但从来没跑过真出事一跑脚本报错路径硬编码的是去年的服务器 IP。没跑过的回滚脚本等于没有。第三注入工具本身必须高可用。用来点火的工具自己不能是单点——它挂了它注入的故障撤不回来那就是假戏真做。Chaos Mesh 的做法是控制器多副本、故障信息存在 CRD 里、TTL 由控制器统一管理不依赖客户端连接。就像你用的打火机必须是一松手就灭的安全款——火在你手里你说了算手一松火就灭哪怕你晕倒了火自己灭。SSH 断了的故事某团队用自制脚本打延迟脚本通过 SSH 连到目标机器打 tc 规则后挂着等 CtrlC。一次演练办公室网络闪断SSH 断了脚本异常中断没走到清理步骤——延迟规则一直留在机器上。大家以为演练结束了业务慢慢变卡半小时后用户大量报错四十分钟后才发现 tc 规则没清。这不是演练——这是自杀式袭击。车都没刹车你就敢开上路不是有回滚命令就叫能回滚——而是回滚命令在最糟糕的情况下网络断了、人不在了、工具挂了依然能把系统拉回来才叫能回滚。灭火器不是买了就算——是你亲手喷过一次确认它能喷出来才叫有灭火器。五、第四道闸有预案Runbook——逃生路线画在墙上不是临时想你肯定经历过这种消防演习——警铃一响整栋楼的人往外跑楼道里有人往回跑拿手机、有人在电梯门口等电梯、有人不知道往哪跑、有人在走廊喊到底怎么回事。踩踏比火灾本身还危险。问题出在哪出在没有预案。不是没有警铃、不是没有灭火器、不是没有逃生通道——而是大家不知道警铃响了自己该干嘛。警铃响了爸爸关煤气、妈妈拿湿毛巾真正的消防演习是提前约好的——爸爸关煤气拿灭火器、妈妈带孩子拿湿毛巾低姿势走、老人带应急包不拿贵重物品、集合点在楼下那棵大槐树下、任何人发现火比预想的大都有权喊撤不需要问爸爸同意。这就叫预案——Runbook。每个场景、每个注入点、每个可能的异常演练前都写清楚谁做什么、什么情况停、什么情况继续、停了怎么办。不是警铃响了大家才想我该干嘛——而是警铃响之前每个人就知道自己的位置、动作、权限。Runbook 七要素一份能救命的 Runbook 写清七件事基本信息演什么、什么时候、谁参加、影响范围、预计时长。实验假设注入后系统会怎么反应——“杀一个从库集群 30 秒内自动切换成功率不低于 99.5%”。假设就是判断成功还是失败的标准没假设你就不知道什么叫好什么叫坏。注入方式怎么注入、用什么工具、参数是什么、在哪注入、注入多久——一笔一笔写清楚执行的人照着做就行不用临场发挥。观测指标盯哪些指标、每个指标阈值、谁盯哪几个。三级终止条件最关键暂停预期外小异常不影响核心先暂停观察、回滚业务指标明显异常但用户未大规模感知立刻回滚、紧急止损用户已感知立刻按红钮。每级写数字的、可判断的标准——不是觉得不对就停是成功率99% 持续 60 秒立刻回滚。而且——红色按钮所有人都有权按不需要请示。喊错了不追责不喊才追责。很多团队演练出事故都是因为大家都看到异常了但没人敢喊停都在等负责人发话等负责人发话用户已经在投诉了。回滚步骤按完按钮怎么验证真的回滚了——工具显示已终止、实例恢复、指标回位、无残留配置脏数据、手动验证核心功能。五步全绿才算回滚成功。演练后验证回滚完要做完整业务验证确认系统真的回到正常。就像撤到楼下后要清点人数、确认没人受伤、确认火真的灭了才能上楼。七要素写齐才算能用少任何一块——大概齐、差不多在真实故障面前最要命。不按预案临场发挥是聚众搞破坏某团队做主从切换Runbook 写了但没开准备会对齐。注入后一个工程师看到错误率略有上升其实是切换中正常抖动 30 秒会恢复他一慌没在群里说话直接重启了整个应用集群。结果本来正在切换的数据库连接全部中断健康的实例也被重启新实例连不上还没切完的数据库——本来 30 秒能自己恢复的事变成全站挂 40 分钟。这就是没有预案对齐的后果——一个人慌了临场发挥把小问题变成大事故。如果 Runbook 里写清楚切换期间错误率上升不超 2 分钟不处理、如果开准备会讲过切换期间看到什么是正常的——就不会出这个事。警铃一响爸爸还没关煤气呢孩子一盆水泼过去——火是灭了但煤气还漏着大家差点煤气中毒。不是孩子坏——是孩子不知道先关煤气再灭火这个顺序。Runbook 不是一张纸——而是每个人在混乱中知道自己该干嘛的定海神针。不按预案临场发挥的演练不是演练是聚众搞破坏。逃生路线画在墙上、每个人职责写在纸上、红色按钮所有人有权按——这才叫预案。六、第五道闸分批次推进——一层一签一层炸了不影响下一层前面四道闸讲了在盆里点火、看得见火、灭得回火、大家知道火起来怎么跑。但你不能第一次就在真房子里点火——你得先在空地上练会再进厨房。先空桶练姿势再到楼下空地上喷你刚买灭火器不会立刻在自家厨房喷——你先在楼下空旷地方对着火盆喷一次试试手感、距离、喷射时间。确认自己真的会用了再拿回家里挂墙上备用。故障演练也一样五批次递进开发环境dev楼下空地。数据假的、用户假的、流量假的炸了天塌不下来。所有场景先跑一遍跑通注入、监控、回滚每一步。不通不准进第二批。预发环境staging跟你家真房一模一样装修的样板房。版本一致、配置一致、拓扑一致、容量一致唯一区别是没真用户流量是模拟的。在这里验证回滚不伤人——回滚后有没有残留数据、脏配置、没恢复的服务。不通不准进第三批。生产小流量第一次进真房子。凌晨两点流量最低的时候在一个单独的实例、一个独立分片、1% 都不到的流量上做。小流量炸了只影响一小撮秒级回滚。不通不准进第四批。生产单可用区小流量验过了可以在一个 AZ 范围内做。流量是真的范围是一个机房其他 AZ 兜着。Netflix 的 Chaos Gorilla断整个 AZ就在这个批次。不通不准进第五批。生产全量最后一步——工作日白天、工程师都在、监控全开、回滚按钮在手边全量生产注入。到这一步你已经做了多少准备开发环境跑过、预发跑过、生产小流量凌晨跑过、单 AZ 跑过——每一步都验过签过字。这时候白天注入不是赌是基于前四批信心的有准备之仗。Netflix 的 Chaos Monkey 工作日白天随机杀实例看起来随便杀——实际上前面走了将近一年。一层炸了不影响下一层分批次核心逻辑——每一层失败都不炸到真用户。开发炸了开发者自己看、预发炸了测试知道、小流量炸了 1% 用户受影响秒回滚、单 AZ 炸了其他 AZ 兜着、全量炸了前四批都过了概率极低且预案齐备。翻译成家里的话——拿空桶练姿势→楼下空地喷→厨房水池点小纸团开着水龙头旁边有人看→厨房油盆模拟小火关着门全家人都在灭火器在手边→最后你才敢说家里消防没问题真着火我们能接住。你不会从刚买灭火器直接跳到客厅点火——那是疯子。但很多团队就是从什么都没准备直接跳生产全量注入出了事说演练风险太大。不是演练风险大——是你没分批。测试过了没问题是最危险的一句话某团队在测试环境跑了一次主从切换成功了工程师一拍手测试过了没问题高峰时段直接切。结果一切应用连不上新主库全站挂了。为什么因为测试环境数据量是生产 1%连接池配置不一样负载不一样缓存不一样。“测试过了不等于生产没问题”。环境和流量不一样系统行为就不一样。所以必须经过测试过→预发过→生产小流量过→生产单 AZ 过四道门才能到全量。这不是保守——是对用户负责。不是敢在生产上炸才叫勇敢——而是在生产上炸之前已经在四批环境里炸过一百次才叫真敢。分批次不是拖慢节奏——是让你在节奏里不摔跟头。一层一签一层炸了不影响下一层。七、故障注入点菜单——家里能模拟的故障对应系统五层五道闸是框架但具体在什么地方点火、点什么火你得心里有数。家里可能出事断电、断网、漏水、燃气漏、灯泡坏、下水道堵、快递堵门、孩子磨洋工。系统也一样分五层——每层讲三件事模拟什么、预期什么、怎么验。基础设施层——断电跳闸家里最常见的是灯泡憋了、插座跳闸、一个房间断电。系统对应Pod 被杀、节点宕机、DNS 故障、AZ 挂掉。模拟杀一个服务实例、杀一个节点、让 DNS 解析失败、断一个可用区。预期杀实例负载均衡 30 秒内切走新实例拉起用户无感杀节点 Pod 其他节点重建 1 分钟恢复DNS 故障有本地缓存和降级不会整体雪崩断 AZ 流量自动切走 RTO2 分钟 RPO0。验证看业务黄金指标杀实例成功率短暂掉一点马上回来就是健康的掉了 10% 以上回不来说明你的负载均衡/健康检查/自动扩容有问题。应用层——孩子买酱油磨磨蹭蹭家里第二类事孩子买酱油二十分钟没回、外卖撒了、保姆请假没人做饭。系统对应接口延迟、异常返回、超时、服务报错。模拟给接口注入 500ms 延迟、注入 500 错误、让服务超时无响应、让依赖返回异常数据。预期下游有合理超时不会被一个慢接口拖死线程池、有有限次数重试2-3 次带退避不会重试风暴、有降级——非核心接口挂了核心功能能用推荐挂了商品还能展示、异常数据不搞崩系统有校验兜底。验证注入后看线程池有没有打满、有没有重试风暴、连接池有没有耗尽、核心业务有没有受影响。一个接口慢 500ms 导致全站变慢——说明你的超时和隔离有问题。网络层——说话十句漏三句家里第三类电话听不清、WiFi 卡、门反锁两边出不去。系统对应丢包、延迟、带宽限制、网络分区脑裂。模拟注入 10% 丢包率、200ms 延迟、带宽限制到 1Mbps、制造网络分区两机房完全不通。预期丢包 10% TCP 重传业务基本不受影响只是延迟略高高延迟有合理超时不卡死带宽受限大请求超时小请求正常不拖垮服务网络分区——这是最危险场景必须提前约定分区时哪边继续服务比如主从分区从库不能私自提升为主否则脑裂数据错该只读就只读该拒绝写就拒绝写。翻译回家里的话——门反锁了爸爸在门外妈妈在门内两人不能各自决定今天全家吃什么否则爸爸点了披萨妈妈做了面晚饭就乱了。必须提前约定门反锁听里面的外面等谁手里拿着饭勺谁说了算。这就是共识算法Raft/Paxos解决的问题——不是谁嗓门大听谁的是提前约好规则真出事时不打架。数据层——大暖壶碎了家里第四类大暖壶碎了备用的能不能顶、厕所坑位全占、找毛衣翻半小时找不到。系统对应主从切换、慢查询、磁盘满、连接池耗尽。模拟主库宕机、注入慢查询、磁盘写满、打满数据库连接池。预期主库宕机自动切从库 30 秒内恢复数据零丢失应用自动重连慢查询有超时熔断不拖垮DB磁盘满有告警提前发现核心功能不因为日志盘满就挂连接池耗尽有排队快速失败机制不让所有请求死等。验证数据层最危险——服务挂了重启就行数据错了找不回来。所以数据层演练一定从小开始测试反复主从切换验数据不丢不错应用能重连再到预发、再生产小流量。备胎放五年没打过气真爆胎才发现备胎也是瘪的。主从切换不演练等于没有主从切换——等真出问题那天你才发现连接池没配、IP硬编码了、脚本过期了就全晚了。资源层——一个人干所有家务忙不过来家里第五类一个人干十个人的活分身乏术、快递堆玄关走不了路、冰箱塞满门关不上。系统对应CPU 打满、内存耗尽、IO 高、文件句柄耗尽。模拟CPU 打到 100%、内存泄漏到 OOM、磁盘 IO 打满、耗尽文件句柄。预期CPU 满核心业务优先级高有分流限流非核心可降级排队内存耗尽 OOM Killer 杀最不重要进程核心服务保留IO 高有限流不会让刷日志吃光业务 IO句柄耗尽有合理回收连接池不泄漏。验证最常暴露的问题——没有限流、没有优先级、没有资源隔离。一个非核心后台任务打满 CPU核心业务跟着受影响这是最冤的死法。演练失败也是成功讲到这你可能会问——演练时发现问题了算成功还是失败算成功而且是最大的成功。Netflix 工程师名言“Chaos Monkey doesn’t cause outages — it reveals them.”混沌猴子不制造故障它只是提前暴露本来就存在的问题。演练时发现切换脚本 IP 硬编码了——好事修了。发现连接池没配重连——好事配上。发现业务指标没人盯——好事安排人。发现回滚脚本跑不起来——好事修好。演练发现问题不是失败——是白赚的。问题在演练里炸修一个成本一小时在业务高峰炸修一个成本一百万。没有任何一次演练是失败的——除非你什么问题都没发现那才要怀疑是不是演练太浅太假太没打到真痛点。写在最后五道闸、五层故障注入点讲完了。我把最核心的几件事凝练成几句话你记一辈子——故障演练不是乱炸——是在你能灭掉的范围内点一团你能看见的火。五道闸不是给你添麻烦的——而是让你敢点火、点得安心、灭得回来。最小半径让你在盆里点火、可观测让你看得见火、一键回滚让你灭得回火、有预案让大家知道火起来怎么跑、分批次让你从火星练到大火。在防火盆里点火是演习在客厅放野火是纵火。区别不是火的大小——而是你有没有那五道闸。不是一上来就炸机房才叫勇敢——而是从一粒火星开始每一步都确认灭得掉才叫真勇敢。烟感器没电就别点火监控没建好就别演练——看不见的火最可怕。灭火器不是买了就算——而是你亲手喷过一次确认它能喷出来才叫有灭火器。回滚按钮没跑过等于没有。逃生路线不是装在脑子里的——而是画在墙上每个人都知道往哪跑的。红色按钮所有人都有权按。不是测试过了没问题就是真没问题——样板间练消防练得再熟回自己家还是要试一次。一层一签一层炸了不影响下一层。备胎放五年没打过气真爆胎了才发现备胎也是瘪的。没演练过的灾备不是灾备是心理安慰。Chaos Monkey 不制造故障——它只是把本来就存在的问题提前暴露。问题在演练里炸总比在业务高峰炸好一万倍。演练发现问题不是失败——是白赚的。系统不会因为你祈祷它不出问题就不出问题——它只会因为你经常在防火盆里点火真着火的时候就不再是大问题。过日子是这样——你不在家点小火试试烟感器、试试灭火器、试试逃生通道真着火了你就只能靠命。敢点火是勇气能收住才是本事。关于 ArchAIHarness这篇文章是「看懂 AI 与智能体」专栏的一部分由ArchAIHarness持续输出。ArchAIHarness 是一套面向 AI 时代软件工程的人机协同架构哲学与公开工程资产主张架构师定义秩序AI 在秩序中生长。人立法AI 执行体系审计。如果你也希望 AI 在明确的架构边界内协作而不是在混沌中碰运气欢迎到 GitHub 上看看我们在做什么组织主页github.com/ArchAIHarness — 了解完整理念与资产全景本专栏zhuanlan-ai-and-agents— 所有文章的源码与发布记录实践指南docs— 架构哲学、工程方法和落地指南开源工具agent-workflows— 可复用的 AI 协作 Agents、Skills 与 Tools工程样例framework— DDD AI 协作的工程底座展示如何在开发中融合 AIEngineered by Architects · Empowered by AI · Audited by Discipline