跨模型评审是架构，不是经验
单 LLM 的自省有结构性盲点——它倾向于确认自己的输出。QuantGPT 在 factor-mine SKILL 的 Phase 0.5 强制 Claude 调用 DeepSeek 评审，是硬性规则，不是建议。这不是冗余，是结构性偏见的解药。
AI Agent
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 自己决定调用顺序。不是因为循环链不酷，而是因为它把决策权放错了地方。
让 AI 写的代码跑起来，但别让它跑出去
AI 生成的代码必须被执行，否则它就只是文本。但执行意味着风险。我没有选择容器隔离，也没有用 RestrictedPython，而是设计了一个三层防御：先在编译期用 AST 拒绝危险结构，再在运行时替换整个 builtins，最后用操作系统级资源限制兜底。三层各解决不同类别的风险，重叠但不冗余。
为什么我没有用 LangChain——自研 FSM 编排引擎的设计逻辑
LangChain、LangGraph、CrewAI、PydanticAI——AI 编排框架从不缺选择。我全部评估后决定自研。不是 NIH 心态，而是当你需要按失败模式选变异策略、按阶段路由不同模型和温度、在轨迹分析的基础上自适应进化时，通用框架给你的抽象层反而变成了需要绕过的障碍。
AI as Operator, Kernel as Law — 为什么 AI 不应该有架构决策权
让 AI 驱动研究流程，不等于让 AI 决定系统怎么运行。我在设计 AI 编排系统时做了一个关键分离：AI 只是操作员，执行引擎才是法律。这个决策源于一次失败的经验。
MCP 的问题不在协议层，在语义层
MCP 的 JSON-RPC 传输没有问题。真正的问题是自然语言规则没有代码级强制力——LLM 可以完全无视你的 instructions。我设计了 Intent Validator 模式来补上这个缺口。
为什么我没有用多智能体架构做量化研究系统
多智能体是当前 AI 工程的热门范式。但我在设计 AI 驱动的量化研究系统时选择了单 Agent + 状态机。不是因为多智能体太难，而是因为问题结构不匹配。