问题
想象你写道：「把我周五晚饭那家餐厅的地址发给所有客人」。要做到这一点，需要读取你的日历，找到这顿晚饭，从中取出地点，在你的联系人里查找每一位客人，然后准备一封邮件。五个动作，三个服务。
把这一切一股脑儿交给一个语言模型，让它面对所有工具，效果并不好。它看到的工具越多，就越犹豫，也越容易选错工具。每次调用都更贵。而一旦出错，根本无从知道错在哪里。
我想要的
我希望 LIA 像一个组织有序的小团队那样工作：有人给请求分类，有人准备计划，有人检查计划，有人执行，有人回答你。每个角色只做一件事。在它们周围，每个领域都带来自己的工具和使用说明：邮件、日历、联系人、任务、文件、天气、地点、路线、网页搜索，甚至还有你自己添加的 MCP 服务器。
为了把这些角色连接起来，我选择了 LangGraph，这是一个把处理过程描述成图的库：一些步骤，加上决定下一步是哪一个的规则。你的消息从头到尾都沿着这张图走。
具体怎么进行
- 分类。路由器读取你的消息，判断它是一次对话还是一个行动请求，以及涉及哪些领域。「谢谢，太完美了」会直接去往回答。周五的晚饭则去往规划器，带上日历、联系人和邮件。
- 计划。规划器只拿到这些领域的工具。它写出一个计划：哪些步骤，用什么参数，以及哪些步骤要等另一个步骤的结果。
- 检查。在任何调用之前，LIA 会检查这个计划：一个编造的工具，一个在等一个找不到的步骤的步骤，一个超出范围的值。能修复的就修复，仍有疑问的就退回给规划器。
- 执行。彼此独立的步骤同时出发，其他步骤等它们需要的东西。在这里：先查日历，然后并行查找所有客人，再生成邮件草稿，你在发送之前确认它。
- 额外的一点。结果回来之后，LIA 会看看是否还缺一个她只需读取就能得到的信息。如果一封邮件提议周四开会，她可以顺便看一眼你周四的日历。她也可以向你建议一个操作，但不会执行它。
- 回答。最后一个角色汇总发生的一切，写给你，并区分哪些成功了、哪些失败了。
两种工作方式
这套流程就是 Pipeline 模式：先计划，后执行。它是最经济、最可预测的，也是默认模式。但有些问题没法事先计划。「这个周末我们做点什么？」取决于 LIA 一路上会发现什么。对于这类问题，你可以用屏幕顶部的模式按钮一键切换到 ReAct 模式：LIA 一步一步推进，读取每个结果，再决定下一步。两种模式共享同样的记忆和同样的确认，并在同一个回答步骤汇合。
不会断的线索
每一步之后，对话的状态都会保存到数据库（PostgreSQL）中。当 LIA 在等你确认时，只要问题还没有过期，一旦你回答，她就会从停下的地方原样继续。如果你关掉标签页，回答会在服务器端继续生成，等你回来。而当一段对话变得很长时，LIA 会为自己总结前面的部分，但不会删除你看到的任何历史记录。
局限
分类可能出错。当路由器真的拿不准时，它会回答你，不采取行动，换个说法往往就够了。Pipeline 模式在看到结果之前就定好了计划：如果某一步失败，它会告诉你，不会临时改走另一条路。而且只有在服务已连接时，LIA 才有这个领域：没有你的日历，任何计划都读不了它。
完整的流程在技术页面上有说明。
延伸阅读：先有计划再行动：LIA 如何准备和检查你的多步请求；Pipeline 还是 ReAct：LIA 处理你请求的两种方式。