<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Posts on AI + 量化工程</title><link>https://miasyster.github.io/posts/</link><description>Recent content in Posts on AI + 量化工程</description><generator>Hugo</generator><language>zh</language><lastBuildDate>Fri, 08 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://miasyster.github.io/posts/index.xml" rel="self" type="application/rss+xml"/><item><title>跨模型评审是架构，不是经验</title><link>https://miasyster.github.io/posts/cross-model-review-is-architecture/</link><pubDate>Fri, 08 May 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/posts/cross-model-review-is-architecture/</guid><description>单 LLM 的自省有结构性盲点——它倾向于确认自己的输出。QuantGPT 在 factor-mine SKILL 的 Phase 0.5 强制 Claude 调用 DeepSeek 评审，是硬性规则，不是建议。这不是冗余，是结构性偏见的解药。</description></item><item><title>Agent-Native 架构：为 Agent 设计系统，不是为人</title><link>https://miasyster.github.io/posts/agent-native-architecture/</link><pubDate>Fri, 01 May 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/posts/agent-native-architecture/</guid><description>当系统的操作员从人类变成 LLM Agent 时，设计原则需要根本性改变。人类需要 GUI 和文档，Agent 需要语义清晰的工具和会报错的约束。我在 QuantGPT 中实践的 Agent-Native 设计原则：为调用者的认知模式设计，不是为设计者的审美设计。</description></item><item><title>Harness 即治理：用代码约束 Agent，不用 Prompt</title><link>https://miasyster.github.io/posts/harness-is-governance/</link><pubDate>Fri, 01 May 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/posts/harness-is-governance/</guid><description>Agent 治理的主流方案是在 prompt 里写规则。但 LLM 可以无视 prompt。真正有效的治理不在 Agent 内部，在 Agent 外部的 Harness 层——工具定义了能做什么，错误定义了不能做什么，代码定义了边界在哪。</description></item><item><title>为什么我做 Agent 基建，而不是做 Agent</title><link>https://miasyster.github.io/posts/why-agent-infra-not-agent/</link><pubDate>Fri, 01 May 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/posts/why-agent-infra-not-agent/</guid><description>当所有人都在卷 Agent 框架的时候，我选择了另一条路：不做 Agent，做 Agent 的基建。不是因为做不了 Agent，而是因为 Agent 层是消耗品，基建层是资产。做资产，不做消耗品。</description></item><item><title>Skill 编排 > Agent 循环链：为什么笨管道 + 聪明工具优于聪明管道 + 笨工具</title><link>https://miasyster.github.io/posts/skill-orchestration-over-agent-loops/</link><pubDate>Thu, 30 Apr 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/posts/skill-orchestration-over-agent-loops/</guid><description>当前 AI Agent 框架热衷于构建复杂的循环链：规划器 → 执行器 → 反思器 → 再规划。我选择了反过来：工具是无状态纯函数，LLM 自己决定调用顺序。不是因为循环链不酷，而是因为它把决策权放错了地方。</description></item><item><title>表达式解析器是编译器，不是 eval()</title><link>https://miasyster.github.io/posts/expression-parser-is-a-compiler/</link><pubDate>Wed, 29 Apr 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/posts/expression-parser-is-a-compiler/</guid><description>QuantGPT 的核心是一个 870+ 行的手写递归下降解析器，支持 80+ 算子、截面/时序自动分组、双模式编译。不是因为不知道 eval() 更简单，而是因为 eval() 做不到的事情恰好是最重要的。</description></item><item><title>API Guard Pattern：为什么直接调用函数是被禁止的</title><link>https://miasyster.github.io/posts/api-guard-pattern/</link><pubDate>Tue, 28 Apr 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/posts/api-guard-pattern/</guid><description>QuantGPT 用 threading.local 实现了一个运行时守卫：所有回测调用必须经过 API 边界，直接调用函数会抛异常。不是因为函数有什么危险，而是因为没有边界的系统无法被审计。</description></item><item><title>反过拟合是架构，不是插件</title><link>https://miasyster.github.io/posts/anti-overfit-is-architecture/</link><pubDate>Mon, 27 Apr 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/posts/anti-overfit-is-architecture/</guid><description>大多数回测系统把反过拟合当作可选的附加检查——跑完回测再测一下。QuantGPT 把它内建到评分系统和进化引擎里：反过拟合结果直接影响因子得分，进化引擎读反过拟合指标决定下一步策略。不验证稳健性的因子，连参与迭代的资格都没有。</description></item><item><title>让 AI 写的代码跑起来，但别让它跑出去</title><link>https://miasyster.github.io/posts/sandbox-defense-in-depth/</link><pubDate>Fri, 03 Apr 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/posts/sandbox-defense-in-depth/</guid><description>AI 生成的代码必须被执行，否则它就只是文本。但执行意味着风险。我没有选择容器隔离，也没有用 RestrictedPython，而是设计了一个三层防御：先在编译期用 AST 拒绝危险结构，再在运行时替换整个 builtins，最后用操作系统级资源限制兜底。三层各解决不同类别的风险，重叠但不冗余。</description></item><item><title>为什么我没有用 LangChain——自研 FSM 编排引擎的设计逻辑</title><link>https://miasyster.github.io/posts/why-i-built-my-own-fsm-engine/</link><pubDate>Fri, 03 Apr 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/posts/why-i-built-my-own-fsm-engine/</guid><description>LangChain、LangGraph、CrewAI、PydanticAI——AI 编排框架从不缺选择。我全部评估后决定自研。不是 NIH 心态，而是当你需要按失败模式选变异策略、按阶段路由不同模型和温度、在轨迹分析的基础上自适应进化时，通用框架给你的抽象层反而变成了需要绕过的障碍。</description></item><item><title>研究不可复现，就不是研究</title><link>https://miasyster.github.io/posts/atomic-versioning/</link><pubDate>Fri, 03 Apr 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/posts/atomic-versioning/</guid><description>ML 研究中最常见的谎言是&amp;rsquo;上次跑的结果很好&amp;rsquo;。上次用的什么代码？什么数据版本？什么参数？没人说得清。我用文件系统事务（临时目录 → 原子重命名）实现了每次迭代的不可变快照，让&amp;rsquo;上次的结果&amp;rsquo;变成一个可查询的事实而不是一段记忆。</description></item><item><title>AI as Operator, Kernel as Law — 为什么 AI 不应该有架构决策权</title><link>https://miasyster.github.io/posts/ai-as-operator/</link><pubDate>Thu, 02 Apr 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/posts/ai-as-operator/</guid><description>让 AI 驱动研究流程，不等于让 AI 决定系统怎么运行。我在设计 AI 编排系统时做了一个关键分离：AI 只是操作员，执行引擎才是法律。这个决策源于一次失败的经验。</description></item><item><title>MCP 的问题不在协议层，在语义层</title><link>https://miasyster.github.io/posts/mcp-semantic-gap/</link><pubDate>Thu, 02 Apr 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/posts/mcp-semantic-gap/</guid><description>MCP 的 JSON-RPC 传输没有问题。真正的问题是自然语言规则没有代码级强制力——LLM 可以完全无视你的 instructions。我设计了 Intent Validator 模式来补上这个缺口。</description></item><item><title>为什么我没有用多智能体架构做量化研究系统</title><link>https://miasyster.github.io/posts/why-not-multi-agent/</link><pubDate>Thu, 02 Apr 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/posts/why-not-multi-agent/</guid><description>多智能体是当前 AI 工程的热门范式。但我在设计 AI 驱动的量化研究系统时选择了单 Agent + 状态机。不是因为多智能体太难，而是因为问题结构不匹配。</description></item><item><title>终局思维：先想清楚怎么被审计，再决定怎么运行</title><link>https://miasyster.github.io/posts/design-for-the-endgame/</link><pubDate>Thu, 02 Apr 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/posts/design-for-the-endgame/</guid><description>多数系统先设计功能，再补审计。我反过来做——先确定系统在出事后需要回答哪些问题，再倒推每一层应该记录什么。这个思维倒置改变了整个架构。</description></item></channel></rss>