Posts

[!TIP] 目标：实现“零侵入”的架构文档同步与 AI 自驱动的系统修复闭环。 1. 零侵入代谢 (Metabolic Governance) 在手搓 Agent 的过程中，维护 ARCHITECTURE.md 和路由表通常是开发者的噩梦。我们的方案是 Metadata-Free 的“新陈代谢”机制： 感知变更：挂载于 Git 钩子，通过 Git Diff 捕获代码变动。 语义推演：AI 自动分析代码意图，更新机器可读的 .anti_bot_map.md (RAG 路由表) 和人类可读的 ARCHITECTURE.md (架构心法)。 强一致性：彻底消除人工维护文档的成本，文档即代码，代码即地图。 2. 系统的脉搏：Heartbeat 引擎 为了保证 Agent 在无人值守下的稳定性，我们配置了独立的 Heartbeat 进程。它不负责“思考”，只负责定期检查几个容易出问题的状态： def probe_heartbeat_checklist(): """让 AI 定期审计自己的运行状态""" with open(HEARTBEAT_FILE, "r") as f: content = f.read() if "[ ]" in content: # 发现待办或异常 engine = RoleEngine("heartbeat") # 触发 AI 进行自我诊断并更新状态 result = engine.invoke(f"Audit this checklist:\n{content}") 3. 自愈闭环：Self-Repair Agent 当 Heartbeat 探测到网关假死或日志中出现 Traceback 时，会瞬间唤醒 Self-Repair Agent： ...

[!TIP] 目标：通过 CLI 传参实现多模态（视觉/文件）感知，并构建动态加载的插件式技能系统。 1. 让 CLI “看见”世界 多模态能力不一定非要复杂的 SDK。在 VISAGENT 中，我们利用 gemini CLI 对文件路径的天然支持（@path），在 RoleEngine 层实现了感知接入： def _do_raw_invoke(self, message, files=None): # 构造多模态后缀 mm_suffix = "" if files: mm_suffix = "\n" + "\n".join([f"@{f}" for f in files]) # 拼接到最终 Prompt full_input = f"{message}{mm_suffix}" # ... 执行 subprocess 实战经验：为了处理复杂的视觉任务，我们专门封装了 vision_expert 技能，通过 DEEP 模式引导 AI 进行 Chain-of-Thought 推演，从而实现对截图、UI 组件的精确识别。 2. 动态技能树：SkillHandler 手搓系统的灵活性在于 插件化。我们设计了 SkillHandler 模块，它能自动发现 skills/ 目录下的所有能力： 自动化发现：启动时扫描目录。 Manifest 规范：每个技能自带 manifest.json，定义其功能描述与 权限主权 (Sovereignty)。 Sovereignty-Aware：在 Prompt 注入时，系统会明确告知 AI 它被授权访问的 FS 路径和网络域，实现安全约束。 3. 灵活的 Hooks 机制 为了在 AI 调用前后插入逻辑，我们实现了一组 Python Hooks： ...

[!TIP] 目标：从单步对话进化为“计划-模拟-执行”的闭环，并引入基于 YAML 的 DAG 异步编排。 1. 从“聊天”到“执行”：AX (Architect-Executive) 范式 Agent 与普通 Chatbot 的分水岭在于：它是否能将模糊的目标拆解为可操作的步骤。在 VISAGENT 中，我们实现了一套 AX Planner 逻辑： Architect (架构师)：接收需求，输出 TODO.json。此时严禁执行，只准规划。 Simulation (心理演操)：在执行前，让另一个“安全专家”角色对计划进行风险评估。 Executive (执行官)：逐一调用 execute_step 完成任务。 这种“先想后做”的机制，通过简单的 Prompt 约束即可在任意 CLI 上实现： # AX_PLANNING_MODE 核心指令 plan_prompt = ( "You are a specialized Task Architect. Output ONLY valid JSON.\n" "Schema: { 'goal': '...', 'steps': [ {'id': 1, 'desc': '...', 'type': 'EXECUTION'} ] }" ) 2. 线性落后：为什么需要 DAG？ 早期的 AX Planner 是线性的。但现实中，复杂的工程任务往往是拓扑结构：有的步骤可以并行，有的则必须等待前序结果。这就是我们引入 Flow Architect 的原因。 ...

[!TIP] 目标：不依赖框架，通过封装 CLI (如 gemini CLI) 构建具备状态管理与隔离能力的 Agent 引擎。 1. 为什么选择 CLI 而非框架？ VISAGENT 的核心设计哲学是 CLI-Native。相比于黑盒框架，直接封装 CLI (如 gemini CLI) 具有更高的可控性和透明度： 原子性：单次调用即单次推演。 状态透明：Session 的恢复与挂起完全由路径和 Resume 标志控制。 环境隔离：利用系统级工具即可实现权限沙箱。 2. 底层封装：RoleEngineBase 核心逻辑通过 subprocess 触发。为了处理长 Prompt 导致的 Shell 参数溢出，我们坚持使用 stdin 传输： def _do_raw_invoke(self, message: str, context: str = "", files: List[str] = None) -> dict: cmd = [AI_BIN, "--resume", "latest"] if self._get_turns() > 0 else [AI_BIN] # 应对超长 Prompt 使用 stdin use_stdin = len(message + context) > 2000 if use_stdin: cmd += ["-p", "-"] result = subprocess.run( cmd, input=f"{message}\n\n{context}" if use_stdin else None, capture_output=True, text=True, encoding='utf-8' ) if result.returncode == 0: self._inc_turns() return {"ok": True, "output": result.stdout} 3. 隔离与会话管理 凭证沙箱 (Symlink) 为了实现多角色、多项目并发而不产生凭证污染，我们利用 软链接 (Symlink) 动态注入 .gemini 配置： ...

[!IMPORTANT] 核心痛点：在快速迭代的项目中，由于人工更新文档的成本极高，导致代码与架构文档（README, ARCHITECTURE.md）总是处于“失真”状态。 解决之道：将“文档维护”从人类开发者的心智负担中剔除，移交给具备语义推演能力的 AI Agent，实现架构图谱的“新陈代谢”。 在跟 AI 进行多轮关于文档治理的对话后，我沉淀出了一个关于“AI 原生新陈代谢治理（AI-Native Metabolic Governance）”的 Skill 构思。这不仅仅是一个自动化脚本，更是一种让代码架构“活起来”的治理逻辑。 Skill: AI-Native Metabolic Governance V3.0 (新陈代谢地图治理) 🎯 核心目标 (Objective) 通过“无侵入”感知和 AI 自主驱动，彻底消除文档维护的心智负担。本 Skill 指导 Agent 在代码发生变更时，自主分析物理结构与逻辑意图的变化，自动更新机器可读的寻址地图（Map: .anti_bot_map.md）和人类可读的架构心法（Lore: ARCHITECTURE.md）。 ⚙️ 触发时机 (Trigger Conditions) 主动触发: 接收到指令 执行新陈代谢、Run metabolism 或 更新架构图。 被动拦截: 挂载于 git pre-commit 或部署脚本（如 scripts/remote_deploy.py）执行前。 🔄 执行工作流 (AI-Native Workflow) 当触发本 Skill 时，Agent 必须严格执行以下三步： Step 1: 零侵入发现 (Zero-Intrusion Discovery) 摒弃人工标签: 严禁要求人类开发者书写任何 @identity 类的冗余注释。 AST 物理扫描: 扫描目标域的 src/ 目录，提取所有导出的类名 (Exported Classes)、核心接口 (Interfaces) 和顶层函数 (Top-level Functions)，将其作为天然的 Identity。 Step 2: 语义推演与计算 (Semantic Metabolism) 提取上下文: 获取当前的 Git Diff、最新的 AST 结构，以及旧版的 .anti_bot_map.md。 意图识别: 判断代码变更的性质。 是新增模块？ -> 自动为其总结 Role。 是文件拆分？ -> 追踪旧逻辑流向了哪个新文件。 是废弃删除？ -> 标记为已移除。 计算健康度 (Health Score)：满分 10.0。若存在大量未被文档化的复杂大类，或模块职责严重耦合，酌情扣分。 Step 3: Map 与 Lore 的双向重绘 (Dual-Update) 根据推演结果，覆写以下两个核心文件： ...

[!TIP] 受众：希望能从底层逻辑优化刷宝效率的 D2R 玩家。 核心目标：梳理 /players X 命令与实际掉率之间的数学关系。 问题-方案映射： 误区：认为只需简单开启 8 人难度就能达到最高掉率。 方案：详解 X（总玩家数）与 Y（同图组队玩家数）对 NoDrop 的共同影响。 暗黑 2 重制版进入第 13 赛季，不少老友依然在讨论如何更科学地“出货”。在刷宝的过程中，单凭感觉往往容易产生偏差，理解游戏背后的 NoDrop（空手率）机制，能让我们在选择刷宝难度和效率之间找到更好的平衡点。 所谓的掉落，其实是一场与概率的博弈。 1. 怪物强度与 X 因子 在 D2R 中，玩家数（X）影响怪物的基本属性。这些属性在怪物生成的瞬间即被固定，即使玩家随后离开游戏，数值也不会改变。 以下是玩家数对怪物生命值的影响参考： X (总玩家) 生命周期 (HP) 倍率 示例 (基础 500 HP) P1 100% 500 P2 150% 750 P3 200% 1,000 P4 250% 1,250 P5 300% 1,500 P6 350% 1,750 P7 400% 2,000 P8 450% 2,250 [!NOTE] 在噩梦与地狱难度下，额外的玩家还会提升怪物的伤害与准确率（AR），每位额外玩家约增加 6.25%。 2. NoDrop 机制：X 与 Y 的协同作用 很多时候，大家会发现单机开启 /players 8 的体感掉落并没有想象中那么夸张。这是因为掉落判定是在怪物死亡瞬间计算的，且受到 Y 因子（同地图组队玩家数）的影响。 ...

深度总结 D2R Multi Rust 从 Tauri v1.x 迁移至 v2.0 的“致幻”过程，涵盖 ACL 权限机制变更、Minisign 签名机制更新以及 Github Action 自动化发布的深坑。

D2R Multi Rust 迎来重大更新：全新火焰门户图标、丝滑的自动更新体验，以及更严谨的账号安全校验。

我以为我是在用 AI 写代码，后来发现我只是在当一个疲惫的包工头。直到我决定给 AI 升个职。

AI 降低了编码门槛，但拉高了认知上限。在 AI 驱动的重构中，我们需要的不仅是 prompt，更是面对复杂性时守住架构底线的坚韧。