VSX-Agent 构建实践记录 — 基于 Claude Code 的 VSX-Agent
1. 系统由六个 subagent 组成：
doc-scanner 根据输入的参考文件夹和已有知识，对资料进行结构化拆分，形成用于学习的基础块；
knowledge-curator 负责整合各块输出，并基于新增信息对知识库进行持续修正与更新；
researcher 聚焦于学习过程中的具体问题分析与模糊认知的澄清；
architect 基于知识库设计代码整体架构；
code-writer 根据架构实现具体代码；
reviewer 结合知识库、编码规范及 gotchas（陷阱）对代码进行系统性回顾与审查。
2. 系统提供四个核心调用命令：
/learn 文件夹路径
/generate 描述生成代码的任务
/review 回顾生成的代码
/correct 人为干预，通过输入金标准或已验证代码，对当前知识库进行修正与更新。
我的使用经验是：在能够完成任务的前提下，应尽量保持知识库的最小化，且 /learn 的输入范围应“小而精”。agent 是一个可持续进化的系统，一次性将整个项目文件夹输入不仅会导致上下文与 token 的爆炸，还可能引入噪声，使学习效果下降。更有效的方式是分阶段构建知识：例如，先使用 L7-11 的代码库建立基础认知，再引入已验证的定制探头代码，学习特定参数模式，最后生成基于该探头的 CEUS 代码；若出现问题，再针对性补充 help text 中的标准文档。
换言之，不应一次性将所有信息输入 agent，否则容易导致知识杂糅、后期难以矫正。更合理的策略是让知识库的边界随任务逐步扩展，而非一开始就构建一个冗余且含有杂质的知识体系。需要特别强调的是，/learn 的输入必须是正确且经过验证的内容，这直接决定了学习效果和知识可靠性。错误的知识带来的偏差会在后续生成中持续传播且难以察觉。
一个典型案例是：在官方示例代码和 help 文档中，并不存在切换 mode 的实现方式。在这一前提下，即使经过多轮调试也无法获得正确结果。最终，寇博士提供了一份经过验证的可运行代码。将其作为新的学习样本输入 agent 后，系统能够识别此前失败的根本原因，并在新一轮调试中得到正确结果。
这一过程表明，人为干预依然不可替代。agent 的能力上限受限于其知识库，即便学习了标准文档，如果缺乏人为校正，也难以纠正理解偏差。因此，尽管 agent 可以作为高效的信息处理与生成工具，但作为自然语言输入方，人所提供的“金标准”依然至关重要。我个人的理解是，当前 LLM 的能力本质上是对人类既有知识的高度提纯，其边界对应于人类历史知识的积累边界。而真正的创新、发明以及有意义的软硬件系统组合，仍然依赖专业人士对模型进行持续校正。LLM 可以替代通用能力，但在专业领域中，专家仍然不可替代，至少在其知识完全被固化为私有 agent 之前。
所谓“知识库最小化”不仅是为了控制 token，更关键在于知识密度：当知识密度降低时，agent 在检索与推理过程中的信噪比会下降，而精炼的知识库可以为每一步决策提供更清晰的依据。这一现象本质上符合 RAG 系统设计中的通用原则，质量优先于数量。
“金标准输入”的重要性同样常被低估。agent 的学习本质上是一种无监督的模式提取过程，它无法区分“常见写法”与“正确写法”，只有通过人为标注边界，才能建立可靠认知。这与 RLHF 的核心机制在原理上是一致的，只是在更小规模的专业场景中被复现。
LLM提纯过程本身会引入偏差，它更倾向于强化被大量记录的显性知识，而工程实践中大量的 tacit knowledge（隐性知识）往往未被记录。寇博士的代码之所以有效，正是因为其承载了这类隐性经验。这也解释了为什么“经验丰富但不撰写文档”的专家，在当前阶段对 agent 的价值反而更高。
#life
1. 系统由六个 subagent 组成：
doc-scanner 根据输入的参考文件夹和已有知识，对资料进行结构化拆分，形成用于学习的基础块；
knowledge-curator 负责整合各块输出，并基于新增信息对知识库进行持续修正与更新；
researcher 聚焦于学习过程中的具体问题分析与模糊认知的澄清；
architect 基于知识库设计代码整体架构；
code-writer 根据架构实现具体代码；
reviewer 结合知识库、编码规范及 gotchas（陷阱）对代码进行系统性回顾与审查。
2. 系统提供四个核心调用命令：
/learn 文件夹路径
/generate 描述生成代码的任务
/review 回顾生成的代码
/correct 人为干预，通过输入金标准或已验证代码，对当前知识库进行修正与更新。
我的使用经验是：在能够完成任务的前提下，应尽量保持知识库的最小化，且 /learn 的输入范围应“小而精”。agent 是一个可持续进化的系统，一次性将整个项目文件夹输入不仅会导致上下文与 token 的爆炸，还可能引入噪声，使学习效果下降。更有效的方式是分阶段构建知识：例如，先使用 L7-11 的代码库建立基础认知，再引入已验证的定制探头代码，学习特定参数模式，最后生成基于该探头的 CEUS 代码；若出现问题，再针对性补充 help text 中的标准文档。
换言之，不应一次性将所有信息输入 agent，否则容易导致知识杂糅、后期难以矫正。更合理的策略是让知识库的边界随任务逐步扩展，而非一开始就构建一个冗余且含有杂质的知识体系。需要特别强调的是，/learn 的输入必须是正确且经过验证的内容，这直接决定了学习效果和知识可靠性。错误的知识带来的偏差会在后续生成中持续传播且难以察觉。
一个典型案例是：在官方示例代码和 help 文档中，并不存在切换 mode 的实现方式。在这一前提下，即使经过多轮调试也无法获得正确结果。最终，寇博士提供了一份经过验证的可运行代码。将其作为新的学习样本输入 agent 后，系统能够识别此前失败的根本原因，并在新一轮调试中得到正确结果。
这一过程表明，人为干预依然不可替代。agent 的能力上限受限于其知识库，即便学习了标准文档，如果缺乏人为校正，也难以纠正理解偏差。因此，尽管 agent 可以作为高效的信息处理与生成工具，但作为自然语言输入方，人所提供的“金标准”依然至关重要。我个人的理解是，当前 LLM 的能力本质上是对人类既有知识的高度提纯，其边界对应于人类历史知识的积累边界。而真正的创新、发明以及有意义的软硬件系统组合，仍然依赖专业人士对模型进行持续校正。LLM 可以替代通用能力，但在专业领域中，专家仍然不可替代，至少在其知识完全被固化为私有 agent 之前。
所谓“知识库最小化”不仅是为了控制 token，更关键在于知识密度：当知识密度降低时，agent 在检索与推理过程中的信噪比会下降，而精炼的知识库可以为每一步决策提供更清晰的依据。这一现象本质上符合 RAG 系统设计中的通用原则，质量优先于数量。
“金标准输入”的重要性同样常被低估。agent 的学习本质上是一种无监督的模式提取过程，它无法区分“常见写法”与“正确写法”，只有通过人为标注边界，才能建立可靠认知。这与 RLHF 的核心机制在原理上是一致的，只是在更小规模的专业场景中被复现。
LLM提纯过程本身会引入偏差，它更倾向于强化被大量记录的显性知识，而工程实践中大量的 tacit knowledge（隐性知识）往往未被记录。寇博士的代码之所以有效，正是因为其承载了这类隐性经验。这也解释了为什么“经验丰富但不撰写文档”的专家，在当前阶段对 agent 的价值反而更高。
#life
