12-Factor Agents 第 11 因子：Trigger From Anywhere，让 Agent 在用户所在的任何渠道被触发与响应

文档教程人工智能大模型AI Agent【免费下载链接】12-factor-agentsWhat are the principles we can use to build LLM-powered software that is actually good enough to put in the hands of production customers?项目地址https://gitcode.com/GitHub_Trending/12/12-factor-agents点击查看免费下载导读本文深入解读 12-Factor Agents 指南的第 11 条原则——Trigger from anywhere, meet users where they are在任何地方触发 Agent在用户所在的渠道与用户相遇。你将掌握如何让用户从 Slack、Email、SMS 等任意渠道发起 Agent 任务如何让 Agent 通过同一渠道给出响应以及如何借由「Outer Loop Agents」模式让 Agent 被 cron、事件、故障告警等非人类信号触发进而在获得人类授权后安全执行高风险的线上操作。文章以仓库中的 workshops/2025-05 实战代码为佐证展示从 HTTP API 触发、CLI 触发到 Webhook 多渠道回传的完整落地路径。什么是 Factor 11Trigger From Anywhere在第 11 条原则之前我们已经经历了 10 个因子的铺垫Agent 通过 自然语言到工具调用 驱动执行、掌控提示词 与 上下文窗口、工具即结构化输出、统一执行状态与业务状态以及 用简单 API 实现 Launch/Pause/Resume 和 用工具调用联系人类。Factor 11 是这些能力的自然汇聚点它回答一个非常实际的产品问题用户在哪里Agent 就该在哪里被触发并通过同样的渠道给出响应。原文档给出的定义非常简洁但含义深远允许用户从Slack、Email、SMS 或任何他们习惯的渠道触发 Agent允许 Agent通过同样的渠道进行响应。这意味着 Agent 不再被锁死在「网页聊天框」这一个入口上。它可以是你 Slack 工作区里的一个协作者是你邮箱里的一个自动回复者也可以是 SMS 消息背后的执行者。用户不需要学习新工具Agent 直接出现在用户已经熟悉的地方。前置条件与 Factor 6、Factor 7 的协作关系原文档明确指出如果你正在实践 Factor 6 - Launch/Pause/Resume with simple APIs 和 Factor 7 - Contact humans with tool calls你就有条件引入本因子。这三者构成一条完整的因果链Factor 6 提供生命周期能力Agent 是程序应当能被简单 API 启动、查询、暂停和恢复。多渠道触发的前提是任意渠道发来的消息都能「启动」或「续写」一个 Agent 运行实例。Factor 7 提供人类接口当 Agent 运行到需要澄清、反馈或审批的关键节点时它通过request_human_input这类工具调用暂停自身并跨渠道向人类求助。Factor 11 把两者接到真实世界触发源不再局限于你的产品界面而是扩展到 Slack、Email、SMS、Webhook、cron 等一切入口响应也不再回落到单一界面而是沿原渠道返回用户。Factor 6 的文档还特别提醒很多 AI 编排器虽然支持 pause/resume却无法在「工具选择」与「工具执行」之间暂停——而这恰恰是 Factor 7 与 Factor 11 需要补上的缝隙详见 factor-06-launch-pause-resume.md。Trigger from anywhere 的落地本质上就是让这个缝隙暴露为可被任意渠道填充的接口。核心机制多渠道触发同渠道响应从仓库实战代码看这套机制围绕一个统一的「线程Thread」模型展开。以 workshops/2025-05/final/src/agent.ts 中的实现为例export class Thread { events: Event[] []; constructor(events: Event[]) { this.events events; } serializeForLLM() { return this.events.map(e this.serializeOneEvent(e)).join(\n); } ... awaitingHumanResponse(): boolean { const lastEvent this.events[this.events.length - 1]; return [request_more_information, done_for_now].includes(lastEvent.data.intent); } awaitingHumanApproval(): boolean { const lastEvent this.events[this.events.length - 1]; return lastEvent.data.intent divide; } }关键洞察无论触发渠道是 Slack、Email、SMS 还是 HTTP API最终都归结为「向 Thread 追加一条初始事件然后运行 agentLoop」。Agent 的状态全部沉淀在Thread.events数组中渠道只负责「把人类的话变成事件」和「把 Agent 的话送回人类」。仓库中的 workshops/2025-05/final/src/server.ts 展示了如何用 Express 把这个模型暴露成简单的 HTTP API——这正是 Factor 6 所说的「simple APIs」// POST /thread - Start new thread app.post(/thread, async (req, res) { const thread new Thread([{ type: user_input, data: req.body.message }]); const threadId store.create(thread); const newThread await agentLoop(thread); store.update(threadId, newThread); const lastEvent newThread.events[newThread.events.length - 1]; // 如果 Agent 退出了循环附上 response_url // 让客户端可以把新消息推回该线程 lastEvent.data.response_url /thread/${threadId}/response; res.json({ thread_id: threadId, ...newThread }); });注意response_url这个设计任何渠道的客户端拿到响应后都能通过POST /thread/:id/response继续把人类的新输入推回同一个线程。这正是「从任何地方触发、从任何地方续写」的最小实现单元。三大收益详解原文档为这一因子列出了三条核心收益每一条都值得展开收益一Meet users where they are——让 AI 应用有「人味」这能帮助你构建那些感觉像真实人类、至少像「数字同事」一样的 AI 应用。用户不必切换工具、不必复制粘贴文本。一个部署在 Slack 里的 Agent 会像同事一样出现在频道中一个绑定邮箱的 Agent 会像可协作的助手一样出现在收件箱里。当 AI 应用以用户熟悉的载体出现交互成本趋近于零感知也从「用工具」变成「与协作者共事」。收益二Outer Loop Agents——让非人类信号成为触发源让 Agent 被非人类触发事件events、定时任务crons、故障outages等。它们可能工作 5 分钟、20 分钟甚至 90 分钟但当到达关键节点时它们会联系人类寻求帮助、反馈或审批。这是「Inner Loop」与「Outer Loop」的分水岭。传统 ChatGPT 式交互是Human - Agent的内环人类先开口Agent 才行动。而 Outer Loop 反转为Agent - HumanAgent 由 cron 或事件在后台被启动自主执行长时间任务直到触及需要人类介入的节点才把问题带给人。Factor 7 的文档详细解释了这种模式见 factor-07-contact-humans-with-tools.md控制流与上下文初始化可能完全反过来例如由 cron 触发的 Agent 在凌晨自动处理积压任务遇到无法决断的变更时通过邮件请求审批。Factor 11 与 Factor 7 的配合让这种「Agent 先工作、人类后介入」的流程在 Slack、Email、SMS 任意渠道上都能成立。收益三High Stakes Tools——用快速人工介入换取高风险授权如果你能快速地把多种人类拉进循环就可以把更高风险的操作交给 Agent发送外部邮件、更新生产数据等。保持清晰的规范能让你对执行「更大更漂亮事情」的 Agent 建立可审计性和信心。这里引用到 Factor 10 - Small, Focused Agents 中的观点即使 LLM 未来更强大围绕边界做工程纪律依然会带来长期优势。Factor 11 的贡献在于人类兜底的速度决定了 Agent 被信任的权限上限。当任何渠道都能在数秒内把人拉进审批循环Agent 就可以承担发邮件、改数据这类不可逆操作——前提是每一次授权都有清晰的标准与记录从而获得可审计性auditability。仓库实战从 HTTP API 到多渠道闭环Factor 11 文档本身偏原则性仓库里的 workshop 则给出了可运行的落地证据。以下是完整的渠道矩阵渠道一HTTP API 触发Web/App 集成如前述 workshops/2025-05/final/src/server.ts 所示POST /thread创建线程并运行 Agent 循环GET /thread/:id查询状态POST /thread/:id/response处理澄清响应或审批结果// POST /thread/:id/response - 处理澄清/审批响应 app.post(/thread/:id/response, async (req, res) { let thread store.get(req.params.id); if (thread.awaitingHumanResponse() body.type response) { // 人类给了澄清回答追加为 human_response 事件 thread.events.push({ type: human_response, data: body.response }); } else if (thread.awaitingHumanApproval() body.type approval body.approved) { // 人类批准了高风险工具执行之 await handleNextStep(lastEvent.data, thread); } else if (thread.awaitingHumanApproval() body.type approval !body.approved) { // 人类拒绝了把反馈写回线程 thread.events.push({ type: tool_response, data: user denied the operation with feedback: ${body.comment} }); } // 重新进入 agentLoop直到下一个 stop event const newThread await agentLoop(thread); store.update(req.params.id, newThread); ... });这个端点就是「任何渠道」的统一收口Slack 消息、SMS 回复、邮件正文最终都可以通过 HTTP 代理转换后打到这个 API 上。渠道二CLI 触发开发者场景workshops/2025-05/final/src/cli.ts 演示了最朴素的触发方式——命令行const args process.argv.slice(2); const message args.join( ); const thread new Thread([{ type: user_input, data: message }]); let newThread await agentLoop(thread); let lastEvent newThread.events.slice(-1)[0]; // 当 Agent 需要人类回应时循环询问 while (lastEvent.data.intent ! done_for_now) { const responseEvent await askHuman(lastEvent); thread.events.push(responseEvent); newThread await agentLoop(thread); lastEvent newThread.events.slice(-1)[0]; } console.log(lastEvent.data.message);CLI 版的人类交互有两种路径未配置HUMANLAYER_API_KEY时用readline在终端直接提问配置后则切换到 Email 渠道通过hl.fetchHumanResponse与hl.fetchHumanApproval阻塞等待人类的邮件回复。同一个 agentLoop既可以由终端人机对话驱动也可以由邮件渠道驱动——这正是 Factor 11 想要的渠道无关性。渠道三Webhook 接收人类响应Email/Slack/SMS 回传workshops/2025-05/walkthrough/12b-server.ts 展示了完整的多渠道回传实现。当 Agent 在 05-human-tools 示例 中发出request_more_information后人类通过邮件/Slack 回复由 Webhook 把回复送回线程app.post(/webhook/response, async (req, res) { const response req.body as WebhookResponse; // webhook 保证携带 response 字段 const humanResponse: string response.event.status?.response as string; const threadId response.event.spec.state?.thread_id; const thread store.get(threadId); if (!thread.awaitingHumanResponse()) { return res.status(400).json({ error: Thread is not awaiting human response }); } // 把人类的回复作为 human_response 事件推回线程 thread.events.push({ type: human_response, data: response.event.status?.response }); });这里的关键技巧是spec.state.thread_id在创建人类联系时把 thread_id 编码进请求的 state 里这样无论人类通过哪个渠道回复Webhook 都能据此定位并续写正确的线程。这直接呼应了 Factor 11 的承诺——响应沿原渠道返回但底层始终是同一个可恢复的线程。渠道无关性的基石BAML 人类工具声明多渠道触发的本质是让 LLM「知道」它可以请求人类输入。仓库用 BAML 显式声明这类工具05-agent.bamltype HumanTools ClarificationRequest | DoneForNow class ClarificationRequest { intent request_more_information description(you can request more information from me) message string } class DoneForNow { intent done_for_now message string description(# message to send to the user about the work that was done. #) } function DetermineNextStep(thread: string) - HumanTools | CalculatorTools { client openai/gpt-4o ... }request_more_information就是 Factor 7 中讨论的「用自然语言 token 声明意图」而非「正规工具」的落地方式。当 Agent 输出该意图时确定性代码负责把它转成 Slack/Email/SMS 的实际触达并挂起线程等待回传。状态管理的可替换性以上所有渠道共享同一个 ThreadStore其注释点明了设计意图// you can replace this with any simple state management, // e.g. redis, sqlite, postgres, etc export class ThreadStore { private threads: Mapstring, Thread new Map(); ... }内存 Map 仅用于演示生产环境可平滑替换为 Redis/SQLite/Postgres。这一点与 Factor 5 - Unify Execution State and Business State 一脉相承渠道越多状态的可寻址性就越关键——thread_id 是把所有渠道串起来的唯一主键。与 Factor 12Stateless Reducer 的呼应Factor 11 的文档指向 Factor 12 - Stateless Reducer。这条线索值得点明如果你把「线程 事件数组」看作纯函数式 reducer 的输入输出那么「从任何渠道触发」就等价于「向 reducer 发送一个 action」——Slack 消息、Webhook 回传、cron 触发全部只是不同类型的 action。Agent 不再关心「我是谁触发的」只关心「下一个事件是什么」。这种视角让多渠道架构在数学上变得简单、可测试、可恢复。小结要素内容核心主张用户从 Slack、Email、SMS 等任意渠道触发 AgentAgent 经同一渠道响应前置因子Factor 6Launch/Pause/Resume、Factor 7Contact humans with tool calls关键机制Thread 事件模型 response_url续写 Webhook 回传thread_id收益一Meet users where they are——让 AI 应用像数字同事收益二Outer Loop Agents——被 cron/事件/故障触发长时后台工作关键点联系人类收益三High Stakes Tools——快速人工介入换取高风险授权与可审计性仓库落地final/src/server.ts、final/src/cli.ts、walkthrough/12b-server.ts、05-human-toolsFactor 11 的本质是一条产品原则Agent 的入口应该由用户定义而不是由你的界面定义。把触发和响应从单一 Web 界面中解放出来让 Agent 出现在 Slack 频道、收件箱和短信对话里再配合 Factor 6 的可恢复生命周期与 Factor 7 的人类接口你就能得到真正「在生产客户手里可用」的 LLM 应用——它像同事一样随时在线必要时也会礼貌地停下来问你一句。赞分享文档教程人工智能大模型AI Agent【免费下载链接】12-factor-agentsWhat are the principles we can use to build LLM-powered software that is actually good enough to put in the hands of production customers?项目地址https://gitcode.com/GitHub_Trending/12/12-factor-agents点击查看免费下载相关推荐终极指南如何用Video2X轻松实现视频超分辨率和帧率插值终极指南如何用Video2X轻松实现视频超分辨率和帧率插值 你是否曾经为老旧视频的低分辨率而烦恼是否希望让卡顿的视频变得流畅自然现在通过Video2X这音视频视频处理图像处理深度学习12-Factor Agents伦理考量负责任AI开发的原则12 Factor Agents伦理考量负责任AI开发的原则 引言当AI代理成为生产级软件 你是否曾担心过AI代理在生产环境中失控当LLM驱动的应用开始处文档教程人工智能大模型AI AgentNanoClaw 的 /welcome 技能解析新渠道接入时的 Agent 首秀如何被触发、投递与执行NanoClaw 的 /welcome 技能解析新渠道接入时的 Agent 首秀如何被触发、投递与执行 NanoClaw 中 container/skills人工智能AI 应用AI AgentAgent 沙箱交互助手上一篇NVIDIA Profile Inspector中文指南解锁显卡隐藏性能的3大秘籍下一篇如何利用Windows通知栏高效背单词ToastFish智能学习工具完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考