<?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>MCP on AI + 量化工程</title><link>https://miasyster.github.io/tags/mcp/</link><description>Recent content in MCP 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/tags/mcp/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>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></channel></rss>