<?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>Orchestration on AI + 量化工程</title><link>https://miasyster.github.io/tags/orchestration/</link><description>Recent content in Orchestration on AI + 量化工程</description><generator>Hugo</generator><language>zh</language><lastBuildDate>Thu, 30 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://miasyster.github.io/tags/orchestration/index.xml" rel="self" type="application/rss+xml"/><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>为什么我没有用 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></channel></rss>