<?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>AI + Quant Engineering</title><link>https://miasyster.github.io/en/</link><description>Recent content on AI + Quant Engineering</description><generator>Hugo</generator><language>en</language><lastBuildDate>Fri, 08 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://miasyster.github.io/en/index.xml" rel="self" type="application/rss+xml"/><item><title>Cross-Model Review Is Architecture, Not Heuristic</title><link>https://miasyster.github.io/en/posts/cross-model-review-is-architecture/</link><pubDate>Fri, 08 May 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/en/posts/cross-model-review-is-architecture/</guid><description>Single-LLM self-reflection has a structural blind spot — the model tends to confirm its own output. QuantGPT enforces a hard rule in factor-mine SKILL Phase 0.5: Claude must consult DeepSeek before designing a new factor family. Not a suggestion, a hard rule. This isn&amp;rsquo;t redundancy — it&amp;rsquo;s the antidote to structural bias.</description></item><item><title>Agent-Native Architecture: Designing Systems for Agents, Not Humans</title><link>https://miasyster.github.io/en/posts/agent-native-architecture/</link><pubDate>Fri, 01 May 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/en/posts/agent-native-architecture/</guid><description>When the system operator changes from a human to an LLM Agent, design principles need fundamental rethinking. Humans need GUIs and documentation. Agents need semantically clear tools and constraints that throw errors.</description></item><item><title>Harness Is Governance: Constraining Agents with Code, Not Prompts</title><link>https://miasyster.github.io/en/posts/harness-is-governance/</link><pubDate>Fri, 01 May 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/en/posts/harness-is-governance/</guid><description>The mainstream approach to Agent governance is writing rules in prompts. But LLMs can ignore prompts. Real governance lives outside the Agent, in the Harness layer — tools define what&amp;rsquo;s possible, errors define what&amp;rsquo;s forbidden, code defines where the boundaries are.</description></item><item><title>Why I Build Agent Infrastructure, Not Agents</title><link>https://miasyster.github.io/en/posts/why-agent-infra-not-agent/</link><pubDate>Fri, 01 May 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/en/posts/why-agent-infra-not-agent/</guid><description>While everyone is building Agent frameworks, I chose a different path: build infrastructure for Agents, not the Agent itself. Not because I can&amp;rsquo;t build Agents, but because the Agent layer is a consumable — infrastructure is an asset.</description></item><item><title>Skill Orchestration > Agent Loop Chains: Why Dumb Pipelines + Smart Tools Beat Smart Pipelines + Dumb Tools</title><link>https://miasyster.github.io/en/posts/skill-orchestration-over-agent-loops/</link><pubDate>Thu, 30 Apr 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/en/posts/skill-orchestration-over-agent-loops/</guid><description>Current AI Agent frameworks obsess over building complex loop chains: Planner → Executor → Reflector → Re-planner. I chose the opposite: tools are stateless pure functions, and the LLM decides the call sequence itself. Not because loop chains aren&amp;rsquo;t cool — but because they put decision authority in the wrong place.</description></item><item><title>The Expression Parser Is a Compiler, Not eval()</title><link>https://miasyster.github.io/en/posts/expression-parser-is-a-compiler/</link><pubDate>Wed, 29 Apr 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/en/posts/expression-parser-is-a-compiler/</guid><description>QuantGPT&amp;rsquo;s core is an 870+ line hand-written recursive descent parser supporting 80+ operators, automatic cross-sectional/time-series grouping, and dual-mode compilation. Not because I didn&amp;rsquo;t know eval() is simpler — but because what eval() can&amp;rsquo;t do happens to be what matters most.</description></item><item><title>API Guard Pattern: Why Calling Functions Directly Is Forbidden</title><link>https://miasyster.github.io/en/posts/api-guard-pattern/</link><pubDate>Tue, 28 Apr 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/en/posts/api-guard-pattern/</guid><description>QuantGPT uses threading.local to enforce a runtime guard: all backtest calls must go through the API boundary. Direct function calls raise an exception. Not because the function is dangerous — but because a system without boundaries can&amp;rsquo;t be audited.</description></item><item><title>Anti-Overfit Is Architecture, Not a Plugin</title><link>https://miasyster.github.io/en/posts/anti-overfit-is-architecture/</link><pubDate>Mon, 27 Apr 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/en/posts/anti-overfit-is-architecture/</guid><description>Most backtest systems treat anti-overfit as an optional add-on check — run the backtest, then test for overfitting if you feel like it. QuantGPT builds it into the scoring system and evolution engine: anti-overfit results directly affect factor scores, and the evolution engine reads anti-overfit metrics to decide its next strategy. Factors that haven&amp;rsquo;t proven robustness don&amp;rsquo;t even qualify for iteration.</description></item><item><title>If Research Isn't Reproducible, It Isn't Research</title><link>https://miasyster.github.io/en/posts/atomic-versioning/</link><pubDate>Fri, 03 Apr 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/en/posts/atomic-versioning/</guid><description>The most common lie in ML research is &amp;rsquo;the results looked great last time.&amp;rsquo; What code was used last time? What data version? What parameters? Nobody can say. I used filesystem transactions (temp directory → atomic rename) to create immutable snapshots of every iteration, turning &amp;rsquo;last time&amp;rsquo;s results&amp;rsquo; from a memory into a queryable fact.</description></item><item><title>Let AI's Code Run — But Don't Let It Run Away</title><link>https://miasyster.github.io/en/posts/sandbox-defense-in-depth/</link><pubDate>Fri, 03 Apr 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/en/posts/sandbox-defense-in-depth/</guid><description>AI-generated code must be executed — otherwise it&amp;rsquo;s just text. But execution means risk. I didn&amp;rsquo;t choose container isolation or RestrictedPython. Instead I designed a three-layer defense: reject dangerous structures at compile time via AST, replace the entire builtins at runtime, and enforce OS-level resource limits as a backstop. Each layer handles a different class of risk. Overlapping but not redundant.</description></item><item><title>Why I Didn't Use LangChain — The Design Logic Behind a Custom FSM Orchestration Engine</title><link>https://miasyster.github.io/en/posts/why-i-built-my-own-fsm-engine/</link><pubDate>Fri, 03 Apr 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/en/posts/why-i-built-my-own-fsm-engine/</guid><description>LangChain, LangGraph, CrewAI, PydanticAI — no shortage of AI orchestration frameworks. I evaluated all of them and built my own. Not NIH syndrome. When you need failure-mode-driven mutation strategies, phase-aware multi-model routing with different temperatures, and adaptive evolution based on trajectory analysis, the abstraction layers of general-purpose frameworks become obstacles to route around.</description></item><item><title>AI as Operator, Kernel as Law — Why AI Shouldn't Have Architectural Authority</title><link>https://miasyster.github.io/en/posts/ai-as-operator/</link><pubDate>Thu, 02 Apr 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/en/posts/ai-as-operator/</guid><description>Letting AI drive research workflows doesn&amp;rsquo;t mean letting AI decide how the system runs. I made a key separation: AI is just the operator, the execution engine is the law. This decision came from a failure.</description></item><item><title>Endgame Thinking: Design for the Audit Before You Design the Feature</title><link>https://miasyster.github.io/en/posts/design-for-the-endgame/</link><pubDate>Thu, 02 Apr 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/en/posts/design-for-the-endgame/</guid><description>Most systems are designed to run first, then audited as an afterthought. I inverted the order — first define what questions the system must answer when things go wrong, then work backwards to what each layer must record. This inversion reshaped the entire architecture.</description></item><item><title>MCP's Problem Isn't the Protocol — It's the Semantic Gap</title><link>https://miasyster.github.io/en/posts/mcp-semantic-gap/</link><pubDate>Thu, 02 Apr 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/en/posts/mcp-semantic-gap/</guid><description>MCP&amp;rsquo;s JSON-RPC transport works fine. The real problem: natural language rules have no code-level enforcement — the LLM can completely ignore your instructions. I designed the Intent Validator pattern to close this gap.</description></item><item><title>Why I Didn't Use Multi-Agent Architecture for My Quant Research System</title><link>https://miasyster.github.io/en/posts/why-not-multi-agent/</link><pubDate>Thu, 02 Apr 2026 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/en/posts/why-not-multi-agent/</guid><description>Multi-agent is the hot paradigm in AI engineering. I chose single agent + state machine for my AI-driven quant research system. Not because multi-agent is too hard, but because the problem structure doesn&amp;rsquo;t match.</description></item><item><title>About</title><link>https://miasyster.github.io/en/about/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://miasyster.github.io/en/about/</guid><description>&lt;p>Building AI-driven quantitative research systems. Focused on AI agent architecture, quant engineering, and production-grade system design.&lt;/p>
&lt;p>This blog documents architecture decisions, engineering lessons, and technical judgments from real-world systems. No tutorials, only decisions.&lt;/p>
&lt;p>Contact: &lt;a href="https://github.com/Miasyster">GitHub&lt;/a> · &lt;a href="mailto:qq853777924@gmail.com">Email&lt;/a>&lt;/p></description></item></channel></rss>