这里放的是我愿意公开讲清楚的内容。

这次给 Aido Planner 做 harness 改造，最有价值的不是省了多少 token，而是过程里三次被数据推翻预期，又一次次把结论纠正回来的记录。

模型负责想，harness 负责做。这篇整理业界对 agent harness 的定义和五个核心职责，再用我自己在 Aido Planner 上做的一次真实改造，把抽象概念钉在一个具体案例上。

几个月前一次关系危机里，我把聊天记录喂给 AI 求安慰，事后重新完整翻看那段对话，发现它推动我做决定的方式，比我当时以为的更系统。

把零散的提示词整理成结构化的 Skill 体系，中间踩过的坑和最后收敛出的分层模型，是一次很典型的从“能用”到“可维护”的工程化过程。

一个"跑不通"的测试用例让我意识到：人工操作不是一个点，而是一条贯穿前置准备、中置交互、后置确认的时间线。这篇文章不讲代码，讲我从这次重构中学到的设计思维。

这次 Aido Planner 优化，我真正想解决的不是再把 today 任务重排得更花，而是让智能体开始从未完成任务、偏好、自然语言、长期计划和模板里判断“今天最该做什么”。

这次做 Aido Preference Memory V1，我真正想清楚的不是抽象概念本身，而是 web、backend、agent 三端应该怎么分工，后端为什么必须接住偏好记忆的落库、版本管理和加载链路。

AI 可以陪你说话、帮你整理情绪，甚至暂时缓解痛苦，但它并不适合承担关系判断和情感裁决。一次真实经历之后，我开始重新理解它的边界。

结合这次真实搭站过程，聊清楚我为什么选 Astro、岛屿架构到底解决了什么，以及 Cloudflare Pages 和阿里云域名应该怎么接。

第一篇站点日志，解释这个网站为什么存在。