<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[Guangfox的博客]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/Guangfox</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; Guangfox]]></copyright><item><title><![CDATA[Context Engineering 实战 04｜Memory 不是聊天记录：长期记忆系统的工程设计]]></title><link>https://blog.youkuaiyun.com/Guangfox/article/details/160832724</link><guid>https://blog.youkuaiyun.com/Guangfox/article/details/160832724</guid><author>Guangfox</author><pubDate>Wed, 06 May 2026 20:49:32 +0800</pubDate><description><![CDATA[Crashsight 的崩溃分析 Agent。用户在第 5 轮告诉它：“这个 crash 是从 v3.2.1 的热修复开始出现的。Agent 记住了。后续 20 轮分析都围绕这个线索展开——查 v3.2.1 的 changelog、对比 v3.2.0 的 stacktrace、分析热修复改了哪些模块。第 32 轮，Agent 突然问：“请问这个 crash 是从哪个版本开始出现的？你告诉它了。它忘了。第 40 轮更糟。它给出了一个修复建议——“建议重启相关服务并观察”。]]></description><category></category></item><item><title><![CDATA[Context Engineering 实战 03｜运行时该给模型看什么：动态上下文组装]]></title><link>https://blog.youkuaiyun.com/Guangfox/article/details/160832712</link><guid>https://blog.youkuaiyun.com/Guangfox/article/details/160832712</guid><author>Guangfox</author><pubDate>Wed, 06 May 2026 20:49:00 +0800</pubDate><description><![CDATA[AIReview 的 code review 系统有 200 条 review 规则，早期全量塞进 context。上线第一周就发现问题：模型给一个纯前端的 React 组件提了"SQL 查询应该加索引"的 review 意见。排查后发现不是个例。只有 12% 的规则被正确使用。更多的规则被忽略或乱用。改成动态选择后——按文件类型 + diff 内容选 10-15 条相关规则注入——遵循率从 45% 到 83%，误报（强行套用不相关规则）从 22% 降到 4%。]]></description><category></category></item><item><title><![CDATA[Context Engineering 实战 02｜System Prompt 是架构决策，不是写说明书]]></title><link>https://blog.youkuaiyun.com/Guangfox/article/details/160596498</link><guid>https://blog.youkuaiyun.com/Guangfox/article/details/160596498</guid><author>Guangfox</author><pubDate>Tue, 28 Apr 2026 16:28:32 +0800</pubDate><description><![CDATA[Config Risk Assessment 系统上线第一周，指令遵循率 67%。System prompt 4000 token，把风险评估的所有规则、所有场景定义、所有输出格式都写在一起——一份完整的"操作手册"。团队做的第一件事：排查模型具体在哪些指令上不遵循。中间 1500 token 的遵循率只有 48%——接近抛硬币。而这 1500 token 恰好放着最细致的评估规则：“数值类配置变化超过 50% 视为高风险”“开关类配置的核心功能关闭标记高风险”。]]></description><category></category></item><item><title><![CDATA[Context Engineering 实战 01｜Context Engineering ≠ Prompt Engineering 2.0：到底在“工程“什么]]></title><link>https://blog.youkuaiyun.com/Guangfox/article/details/160596481</link><guid>https://blog.youkuaiyun.com/Guangfox/article/details/160596481</guid><author>Guangfox</author><pubDate>Tue, 28 Apr 2026 16:27:58 +0800</pubDate><description><![CDATA[AIReview 有 8 个工具（search_code、read_file、run_test 等），每个工具的 description + parameter schema 大约 100-150 token。这 900 token 是隐性固定开销，每次请求都在，你的规则和 diff 要跟它们竞争注意力。]]></description><category></category></item><item><title><![CDATA[Harness Engineering 06｜从单个 Harness 到 Harness Platform]]></title><link>https://blog.youkuaiyun.com/Guangfox/article/details/160566051</link><guid>https://blog.youkuaiyun.com/Guangfox/article/details/160566051</guid><author>Guangfox</author><pubDate>Mon, 27 Apr 2026 19:48:47 +0800</pubDate><description><![CDATA[activity-dev-harness 最成熟，Crashsight 最薄弱。但即使是最成熟的项目，也没法把自己的 Harness 能力直接给别人用——因为。四个项目的 Eval 回归脚本写了四遍，Trace 记录方案设计了四遍，工具分级逻辑实现了四遍。]]></description><category></category></item><item><title><![CDATA[Harness Engineering 05｜Safety & HITL Harness：边界、接管与回滚]]></title><link>https://blog.youkuaiyun.com/Guangfox/article/details/160566039</link><guid>https://blog.youkuaiyun.com/Guangfox/article/details/160566039</guid><author>Guangfox</author><pubDate>Mon, 27 Apr 2026 19:47:36 +0800</pubDate><description><![CDATA[activity-dev-harness 早期有一次事故：Developer Agent 修复一个 UI 问题时，判断"根因在配置文件"，然后改了——这是构建产物目录，每次构建会被覆盖。修改被覆盖后 Agent 检测到"修复没生效"，于是再改一次，再被覆盖，再改……陷入死循环，3 轮全部浪费。问题不是 Agent"不够聪明"。它的修复思路合理，代码也写对了。一个写权限没有边界的 Agent，能力越强，做出越界修改的概率就越高。]]></description><category></category></item><item><title><![CDATA[Harness Engineering 04｜能力 Harness：工具和检索的可靠性工程]]></title><link>https://blog.youkuaiyun.com/Guangfox/article/details/160533026</link><guid>https://blog.youkuaiyun.com/Guangfox/article/details/160533026</guid><author>Guangfox</author><pubDate>Sun, 26 Apr 2026 20:40:29 +0800</pubDate><description><![CDATA[activity-dev-harness 最初给 Developer Agent 配了 12 个工具。逻辑很直觉：能力越多 → 覆盖越全 → 效果越好。同样的故事在 RAG 上也发生了：AIReview 接入规则知识库后，团队以为"有知识就更准"。实测发现某些场景下接入 RAG 反而导致准确率下降——检索噪声污染了原本正确的判断。]]></description><category></category></item><item><title><![CDATA[Harness Engineering 03｜Eval & Trace Harness：验证和追溯的工程组织]]></title><link>https://blog.youkuaiyun.com/Guangfox/article/details/160533018</link><guid>https://blog.youkuaiyun.com/Guangfox/article/details/160533018</guid><author>Guangfox</author><pubDate>Sun, 26 Apr 2026 20:39:58 +0800</pubDate><description><![CDATA[手记 03 已经覆盖了评测和可观测性的基础概念：AI 测试金字塔、非确定性回归、5 层可观测模型。这篇不重复那些内容。当你有一套 Agent 系统，Eval 和 Trace 应该怎么组织成闭环，才能真正防住质量退化？手记 03 的视角 本篇的视角什么是 Eval Eval 在 Harness 里怎么组织什么是可观测性 Trace 记什么、怎么用、服务谁评测集怎么分类 Eval + Trace 怎么串成闭环非确定性回归的原理 真实系统里的 Eval 流水线长什么样。]]></description><category></category></item><item><title><![CDATA[Harness Engineering 02｜Repo Harness：让仓库对 Agent 可读]]></title><link>https://blog.youkuaiyun.com/Guangfox/article/details/160507956</link><guid>https://blog.youkuaiyun.com/Guangfox/article/details/160507956</guid><author>Guangfox</author><pubDate>Sat, 25 Apr 2026 21:14:51 +0800</pubDate><description><![CDATA[activity-dev-harness 第一次接入真实仓库时，Developer Agent 的表现让人意外：在 playground 里能写出 90% 正确的 Lua 代码，但进入真实项目后，35 个 case 只通过了 12 个。]]></description><category></category></item><item><title><![CDATA[Harness Engineering 01｜从 Prompt Engineering 到 Harness Engineering]]></title><link>https://blog.youkuaiyun.com/Guangfox/article/details/160507951</link><guid>https://blog.youkuaiyun.com/Guangfox/article/details/160507951</guid><author>Guangfox</author><pubDate>Sat, 25 Apr 2026 21:14:21 +0800</pubDate><description><![CDATA[activity-dev-harness 项目的 Prompt 调优阶段，团队在 system prompt 上反复打磨了三周：角色定义、输出约束、few-shot 示例、CoT 引导。每改一版，跑几个 case 看起来都有进步。第三周末拉全量 35 个 case 回归，通过率 45%，波动范围 30%-65%。也就是说，同一份 Prompt，今天跑 65% 明天跑 30%。后来真正让通过率稳定到 78%（波动 72%-85%）的，不是某一版"更好的 Prompt"。]]></description><category></category></item><item><title><![CDATA[AI Agent 实战避坑 06｜给 AI 的工具越多越好？Tool Use 设计的减法哲学]]></title><link>https://blog.youkuaiyun.com/Guangfox/article/details/160478840</link><guid>https://blog.youkuaiyun.com/Guangfox/article/details/160478840</guid><author>Guangfox</author><pubDate>Fri, 24 Apr 2026 17:10:13 +0800</pubDate><description><![CDATA[一个 Developer Agent 初始配了 12 个工具：读文件、写文件、运行命令、搜索代码、查文档、跑测试、看 git log、看 diff、格式化代码、检查类型、检查 lint、查依赖。看起来很全面——Agent 应该什么都能干了。工具少了 58%，通过率反而提高了 16 个百分点。]]></description><category></category></item><item><title><![CDATA[AI Agent 实战避坑 05｜AI 版 TDD：Eval-Driven Development 完全指南]]></title><link>https://blog.youkuaiyun.com/Guangfox/article/details/160478826</link><guid>https://blog.youkuaiyun.com/Guangfox/article/details/160478826</guid><author>Guangfox</author><pubDate>Fri, 24 Apr 2026 17:09:27 +0800</pubDate><description><![CDATA[格式检查（硬门槛）try:except:return results # 格式都不对，后面不用看了# 内容检查。]]></description><category></category></item><item><title><![CDATA[AI Agent 实战避坑 04｜别让 AI 边想边做：Planning/Execution 分离实战]]></title><link>https://blog.youkuaiyun.com/Guangfox/article/details/160448168</link><guid>https://blog.youkuaiyun.com/Guangfox/article/details/160448168</guid><author>Guangfox</author><pubDate>Thu, 23 Apr 2026 18:37:58 +0800</pubDate><description><![CDATA[让 Agent 实现一个 694 行的模块——real_wiring.py，负责活动系统的真实布线逻辑。Agent 上来就开始写代码，前 50 行还不错，到第 100 行发现前面的数据结构选错了，但它没有回头改，而是在错误的基础上继续往下堆了 400 行补丁逻辑。最后交出来的代码"能跑"，但维护性为零。这不是 Agent “笨”。这是自回归生成的结构性问题——每个 token 都基于前面已生成的内容，一旦前面走错了方向，后面要"推翻重来"在概率上极其困难。]]></description><category></category></item><item><title><![CDATA[AI Agent 实战避坑 03｜AI 的“我修好了“不能信：置信度校准入门]]></title><link>https://blog.youkuaiyun.com/Guangfox/article/details/160448165</link><guid>https://blog.youkuaiyun.com/Guangfox/article/details/160448165</guid><author>Guangfox</author><pubDate>Thu, 23 Apr 2026 18:37:24 +0800</pubDate><description><![CDATA[让 Developer Agent 修 100 个 bug。直觉上你会觉得：第一档最靠谱，第三档最不靠谱。AI 的自信程度和它的正确率之间，几乎没有正相关关系。这不是个别模型的问题，而是当前 LLM 的结构性缺陷。]]></description><category></category></item><item><title><![CDATA[AI Agent 实战避坑 02｜为什么你的 Prompt 越写越长，效果却越来越差]]></title><link>https://blog.youkuaiyun.com/Guangfox/article/details/160417624</link><guid>https://blog.youkuaiyun.com/Guangfox/article/details/160417624</guid><author>Guangfox</author><pubDate>Wed, 22 Apr 2026 20:29:18 +0800</pubDate><description><![CDATA[上个月优化一个 Code Review Agent 的 system prompt。初版 800 token，效果还行，能抓住主要问题。团队陆续加了各种要求：代码规范要检查、安全漏洞要扫描、性能问题要提醒、文档一致性要校验……两周后 prompt 膨胀到 6200 token。跑了一轮 eval，通过率从 78% 跌到 52%。加了三倍的细节，效果反而砍了三分之一。这不是个例——几乎每个认真做 Agent 的团队都会走到这一步。]]></description><category></category></item><item><title><![CDATA[AI Agent 的 8 种“死法“：一份来自生产环境的失败模式手册]]></title><link>https://blog.youkuaiyun.com/Guangfox/article/details/160417613</link><guid>https://blog.youkuaiyun.com/Guangfox/article/details/160417613</guid><author>Guangfox</author><pubDate>Wed, 22 Apr 2026 20:28:47 +0800</pubDate><description><![CDATA[AI Agent 的失败不是随机的，它有可预测的模式——这意味着可预测 = 可防御。很多人抱怨"AI 不好用"，本质上是把 AI 当黑盒在用：输入 prompt，祈祷输出正确。理解模型的激励结构（Reward），承认它和你的目标（Target）之间有 gap，然后用分层防御去系统性地缩小这个 gap。不要问"AI 为什么这么笨"，要问"我的系统哪层防御没做到位"。]]></description><category></category></item><item><title><![CDATA[AI 工程化手记 02｜推理服务：一条请求的生命与代价]]></title><link>https://blog.youkuaiyun.com/Guangfox/article/details/160373417</link><guid>https://blog.youkuaiyun.com/Guangfox/article/details/160373417</guid><author>Guangfox</author><pubDate>Tue, 21 Apr 2026 15:04:58 +0800</pubDate><description><![CDATA[activity-dev-harness 的一次验收循环里，Developer Agent 推理一次生成代码，Reviewer Agent 推理一次生成 findings，FAIL 了再来一轮。3 轮循环 = 至少 6 次推理调用，每次都带着越来越长的上下文。Demo 阶段跑得很顺。]]></description><category></category></item><item><title><![CDATA[AI 工程化手记 01｜AI 工程不是调模型]]></title><link>https://blog.youkuaiyun.com/Guangfox/article/details/160373390</link><guid>https://blog.youkuaiyun.com/Guangfox/article/details/160373390</guid><author>Guangfox</author><pubDate>Tue, 21 Apr 2026 15:04:26 +0800</pubDate><description><![CDATA[activity-dev-harness 第一版 Demo 两天跑通：Agent 读 case JSON，生成 Lua 代码，跑 smoke test，演示效果不错。团队觉得"核心能力有了"。]]></description><category></category></item><item><title><![CDATA[【Unity工程化】08_Profiler实战完整定位流程]]></title><link>https://blog.youkuaiyun.com/Guangfox/article/details/153736839</link><guid>https://blog.youkuaiyun.com/Guangfox/article/details/153736839</guid><author>Guangfox</author><pubDate>Wed, 22 Oct 2025 16:09:06 +0800</pubDate><description><![CDATA[案例1：战斗场景帧率暴跌玩家反馈（紧急）："打BOSS的时候卡到怀疑人生""技能释放的瞬间直接1帧""手机发烫到不敢碰"测试数据：- 正常场景：60 FPS- 进入战斗：45 FPS- BOSS战：15-20 FPS（严重）- 玩家流失：+35%案例2：UI界面莫名卡顿测试反馈："打开背包界面卡顿500ms""滑动列表不流畅"Profiler数据：- 背包UI：初始化耗时600ms- DrawCall：从5个→120个- SetPass Call：78个。]]></description><category></category></item><item><title><![CDATA[【Unity工程化】07_Addressables_Catalog加载机制详解]]></title><link>https://blog.youkuaiyun.com/Guangfox/article/details/153680989</link><guid>https://blog.youkuaiyun.com/Guangfox/article/details/153680989</guid><author>Guangfox</author><pubDate>Tue, 21 Oct 2025 10:26:07 +0800</pubDate><description><![CDATA[Addressables Catalog 文件加载机制摘要 Catalog文件是Unity Addressables系统的核心组件，作为资源定位的&quot;地址簿&quot;，记录着所有资源的存储位置、依赖关系和版本信息。本文深入解析： 文件结构：Catalog采用JSON格式存储，包含资源路径、依赖关系、加载器类型等关键数据，通过Base64编码压缩优化存储空间 加载流程：包含初始化→加载本地Catalog→检查远程更新→下载合并→最终就绪六个步骤，确保版本一致性 查询机制：采用哈希桶加速定位，通过Ad]]></description><category></category></item></channel></rss>