Agently Talk to Control
项目链接
- GitHub: AgentEra/Agently-Talk-to-Control
定位
这是一个基于 Agently v4 的“自然语言 -> 控制动作”示例项目。它适合回答这类问题：
- 用户的话能不能直接根据当前状态回答
- 如果不能，是否需要拆成一组有顺序的控制动作
- 如果也不能安全执行，应该如何拒绝并给出建议
和普通聊天 demo 不同，它把状态读取、动作规划、控制执行、拒绝分支、流式回显放进了同一个运行时。
1. 项目分层
如何理解这套结构
app.py只负责 UI 与执行入口，不把控制逻辑塞进界面层。workflows/talk_to_control.py是 owner layer，负责真正的判断、编排与状态更新。SETTINGS.yaml同时描述模型配置、设备初始状态和控制器注册信息。controllers/只承载具体动作，不负责路由与规划。
2. 运行态主链路
关键点
- 第一步不是直接调控制器，而是先判断这条请求属于直接回答 / 执行动作 / 拒绝请求哪一路。
RunActionStage会按资源冲突关系切分 stage；互不冲突的动作可在同一 stage 并行执行。Finalize统一负责整理 transcript、设备状态和已完成动作列表。
3. 它在 Agently-Skills 视角下用了什么
| 能力层 | 对应 skill | 项目中的体现 |
|---|---|---|
| 顶层问题路由 | agently-playbook | 整个项目先判断“回答 / 执行 / 拒绝”哪条路径才是 owner path |
| 结构化规划与动作参数生成 | agently-output-control | 规划请求和动作请求都通过结构化字段与 ensure_keys 保持接口稳定 |
| 单次响应的流式消费 | agently-model-response | 使用 get_response() + instant 流式把计划预览和拒绝理由提前推到 UI |
| 显式控制流与阶段执行 | agently-triggerflow | DirectReply、CannotDo、RunActionStage、Finalize 这些事件分支都由 TriggerFlow 驱动 |
| 模型与环境配置 | agently-model-setup | AGENT_SETTINGS 与 ${ENV.xxx} 配置约定使模型接入和环境变量加载保持清晰边界 |
4. 为什么这个案例值得单独放进文档站
- 它不是“模型返回一个 JSON 然后调用函数”这么简单，而是一个完整的控制型 workflow。
- 它同时覆盖了结构化规划、流式回显、显式状态更新和阶段级并行执行。
- 它证明了“自然语言控制”并不一定先从自定义 agent wrapper 开始，而可以沿着 Agently 的原生能力边界搭起来。
5. 扩展路径
如果你要把这个项目扩到更多设备或控制动作，最直接的路径是：
- 在
SETTINGS.yaml中补设备初始状态与控制器描述。 - 在
controllers/中补控制函数。 - 如果开始出现审批、等待恢复、外部事件驱动或更复杂的阶段依赖，再继续往 TriggerFlow 章节深化。
对应阅读建议：