跨模型评审是架构，不是经验
单 LLM 的自省有结构性盲点——它倾向于确认自己的输出。QuantGPT 在 factor-mine SKILL 的 Phase 0.5 强制 Claude 调用 DeepSeek 评审，是硬性规则，不是建议。这不是冗余，是结构性偏见的解药。
Posts
Agent-Native 架构：为 Agent 设计系统，不是为人
当系统的操作员从人类变成 LLM Agent 时，设计原则需要根本性改变。人类需要 GUI 和文档，Agent 需要语义清晰的工具和会报错的约束。我在 QuantGPT 中实践的 Agent-Native 设计原则：为调用者的认知模式设计，不是为设计者的审美设计。
Harness 即治理：用代码约束 Agent，不用 Prompt
Agent 治理的主流方案是在 prompt 里写规则。但 LLM 可以无视 prompt。真正有效的治理不在 Agent 内部，在 Agent 外部的 Harness 层——工具定义了能做什么，错误定义了不能做什么，代码定义了边界在哪。
为什么我做 Agent 基建，而不是做 Agent
当所有人都在卷 Agent 框架的时候，我选择了另一条路：不做 Agent，做 Agent 的基建。不是因为做不了 Agent，而是因为 Agent 层是消耗品，基建层是资产。做资产，不做消耗品。
Skill 编排 > Agent 循环链：为什么笨管道 + 聪明工具优于聪明管道 + 笨工具
当前 AI Agent 框架热衷于构建复杂的循环链：规划器 → 执行器 → 反思器 → 再规划。我选择了反过来：工具是无状态纯函数，LLM 自己决定调用顺序。不是因为循环链不酷，而是因为它把决策权放错了地方。
表达式解析器是编译器，不是 eval()
QuantGPT 的核心是一个 870+ 行的手写递归下降解析器，支持 80+ 算子、截面/时序自动分组、双模式编译。不是因为不知道 eval() 更简单，而是因为 eval() 做不到的事情恰好是最重要的。
API Guard Pattern：为什么直接调用函数是被禁止的
QuantGPT 用 threading.local 实现了一个运行时守卫：所有回测调用必须经过 API 边界，直接调用函数会抛异常。不是因为函数有什么危险，而是因为没有边界的系统无法被审计。
反过拟合是架构，不是插件
大多数回测系统把反过拟合当作可选的附加检查——跑完回测再测一下。QuantGPT 把它内建到评分系统和进化引擎里：反过拟合结果直接影响因子得分，进化引擎读反过拟合指标决定下一步策略。不验证稳健性的因子，连参与迭代的资格都没有。
让 AI 写的代码跑起来，但别让它跑出去
AI 生成的代码必须被执行，否则它就只是文本。但执行意味着风险。我没有选择容器隔离，也没有用 RestrictedPython，而是设计了一个三层防御：先在编译期用 AST 拒绝危险结构，再在运行时替换整个 builtins，最后用操作系统级资源限制兜底。三层各解决不同类别的风险，重叠但不冗余。
为什么我没有用 LangChain——自研 FSM 编排引擎的设计逻辑
LangChain、LangGraph、CrewAI、PydanticAI——AI 编排框架从不缺选择。我全部评估后决定自研。不是 NIH 心态，而是当你需要按失败模式选变异策略、按阶段路由不同模型和温度、在轨迹分析的基础上自适应进化时，通用框架给你的抽象层反而变成了需要绕过的障碍。