核心观点：LLM的角色边界与Harness的必要性
在构建基于大语言模型（LLM）的应用时，一个常见的误区是让模型自主决定流程的走向。以语音导师（Voice Tutor）为例，LLM并不决定课程何时结束，也不判断用户答案的对错，更不决定下一步该执行什么操作。这些关键的控制权完全由外部的“Harness”（控制框架/编排器）接管。LLM的唯一职责是“出现并对话”，即执行具体的语言交互任务，而流程的逻辑控制、状态跳转和结果验证则由外部系统严格管理。
"The LLM in my voice tutor doesn't decide when the lesson is over. It doesn't decide whether the user got the answer right. It doesn't decide which step comes next. A harness does all of that. The LLM just shows up and talks."
这种架构设计的核心在于解决多步流代理（Multi-step flow agent）在实际落地中的痛点。任何尝试部署此类系统的工程师都会遇到模型过早结束对话、跳过必要检查、陷入步骤循环或悄悄丢弃部分程序的问题。提示工程（Prompting）只能解决大部分问题，工具使用纪律（Tool-use discipline）能解决更多问题，但最终的区别在于是否将流程控制权掌握在模型之外。正是这种对流程的外部掌控，决定了产品是从一个演示Demo转变为用户每天真正登录使用的可靠系统。
案例解析：Ace语音导师的状态机架构
以实际投入生产环境的语音导师产品“Ace”为例，其课程设计为一个小型的状态机（State Machine）。整个课程流程被划分为六个明确的节点：介绍（Intro）、教学（Teach）、检查（Check）、评分（Grade）、推进（Advance）和总结（Wrap）。这种结构化的设计确保了每一步都有明确的输入和输出预期。
在每个节点中，系统向LLM交付一个狭窄的契约（Narrow Contract），即明确指示模型“做什么”以及“返回什么”。Harness负责验证LLM的返回结果，推进状态机，并决定下一步的操作。这种机制有效地防止了模型的不可控行为：当LLM试图跳过步骤时，Harness会忽略其指令；当LLM试图宣布课程结束时，Harness会检查实际的完成信号（Completion Signal）而非依赖模型的口头声明。
"Each node hands the LLM a narrow contract: do this, return that. The harness validates the return, advances the state, decides what comes next."
这种模式不仅适用于课程流程，还延伸至共享画布（Shared Canvas，即代理绘制的界面）、评分逻辑以及中断处理（Interruption Handling）等场景。通过这种严格的契约和验证机制，系统确保了即使在LLM出现幻觉或逻辑错误时，整体业务流程依然保持正确和稳定。这是构建生产级AI应用的关键基础设施。
架构决策：为何要限制LLM的权限
在构建Ace的过程中，团队经历了七分钟的架构迭代，包括状态机的设计、契约形状的确定，以及几次尝试赋予LLM更多权限但最终回滚的经历。这些经验总结出了一份“LLM在任何流程代理中绝不应拥有的决策权”清单。这一部分的核心在于通过具体的试错案例，揭示赋予LLM过多自主权带来的风险。
团队曾尝试让LLM自行决定某些流程节点，结果发现模型容易在复杂逻辑中迷失，导致用户体验断裂或数据不一致。每一次回滚都强化了一个共识：LLM擅长生成内容，但不擅长执行严格的逻辑控制。因此，将流程控制、状态管理和最终决策权保留在代码层（Harness），是保证系统可靠性的唯一路径。
"Seven minutes. The state machine, the contract shape, a few places where I tried to give the LLM more authority and rolled it back, and a short list of decisions the LLM should never own in any flow agent."
这种架构选择并非否定LLM的能力，而是明确其能力边界。在需要高可靠性的生产环境中，确定性优于灵活性。通过外部Harness固化流程，团队能够更轻松地调试、监控和优化系统，而不是在模型的黑盒行为中寻找Bug。这是从实验性项目走向规模化应用的关键一步。
演讲者背景与项目定位
本次内容的分享者包括Ornella Bahidika和Joel Allou，他们分别从产品管理和独立开发者的角度，提供了对AI代理架构的深入见解。Ornella Bahidika是微软的产品经理，专注于帮助组织优化协作、 workplace technology（工作场所技术）以及AI驱动的体验。她的背景为理解企业级AI应用的需求和落地挑战提供了宏观视角。
"Ornella Bahidika is a Product Manager at Microsoft, where she develops solutions that help organizations optimize collaboration, workplace technology, and AI-driven experiences."
另一位分享者Joel Allou则是Ace语音导师的独立创始人，专注于构建语音优先的AI导师系统。他的研究兴趣集中在个性化学习的代理系统，特别是使流程代理（Flow Agents）可靠的基础设施。Joel的视角更贴近一线开发实践，他通过实际案例展示了如何在资源有限的情况下，通过架构设计解决AI代理的稳定性问题。
"Joel builds voice-first AI tutors. Solo founder focused on agentic systems for personalized learning, with a particular interest in infrastructure that makes flow agents reliable."
两人的结合体现了从理论架构到实际落地的完整闭环。Ornella提供了企业级应用的严谨性标准，而Joel展示了独立开发者如何通过创新架构实现这一标准。这种跨角色的视角有助于读者更全面地理解AI代理系统在开发、部署和维护过程中面临的挑战与解决方案。
关键结论：从Demo到生产系统的跨越
总结而言，构建可靠的AI代理系统，关键在于明确LLM的角色边界。LLM应被视为内容生成器和对话执行者，而非流程控制器。通过引入外部Harness来管理状态机、验证输出和决定下一步操作，开发者可以显著降低系统的不确定性，提高用户体验的一致性。
"The last stretch, the difference between a demo and a system real users sign into every day, is owning the flow outside the model."
这一结论不仅适用于语音导师，也适用于所有涉及多步流程的AI应用，如客服机器人、自动化工作流助手等。在追求AI能力的同时，不要忽视工程架构的基础作用。只有将LLM的能力与外部系统的确定性逻辑相结合，才能打造出真正可用、可靠的生产级AI产品。
"Prompting gets you most of the way. Tool-use discipline gets you closer. The last stretch... is owning the flow outside the model."
最终，成功的AI应用不是由模型有多聪明决定的，而是由系统有多稳健决定的。通过严格限制LLM的权限，采用契约化的交互方式，开发者可以构建出既智能又可靠的AI代理系统，满足用户在真实场景中的需求。