Agent Zero 邮件集成fw.email.system_context_reply.md如何约束 response 工具、break_loop 语义与附件投递【免费下载链接】agent-zeroAgent Zero AI framework项目地址: https://gitcode.com/GitHub_Trending/ag/agent-zero本文围绕 Agent Zero 邮件插件_email_integration中回复阶段的系统提示词文件 fw.email.system_context_reply.md 展开逐条解析它对 Agent 回复行为的约束——response 工具即邮件出口、break_loop的真假语义、附件数组与多文件打包规则并结合插件的扩展点源码system_prompt 注入器、response 拦截器、自动发信扩展说明这些提示词规则如何被底层代码强制执行最终帮助读者掌握邮件会话中消息—回复—附件的完整投递链路。提示词的定位仅注入到已有邮件会话的系统提示这个文件的定位写在标题里——Email session behavior邮件会话行为。它不是通用系统提示的一部分而是只在某个上下文被标记为邮件会话时才被追加进系统提示。注入逻辑在 system_prompt 扩展 中handler_name self.agent.context.data.get(CTX_EMAIL_HANDLER) if not handler_name: return system_prompt.append( self.agent.read_prompt(fw.email.system_context_reply.md) )判断依据是上下文数据中的email_handler键常量CTX_EMAIL_HANDLER定义于 dispatcher.py。该键在邮件入站被路由到新会话时写入handler.py 的_start_new_chat会把handler_name、发件人、主题、thread_id、Message-Id、References一并存入context.data。也就是说凡是经由该 handler 邮件通道进入的聊天Agent 的系统提示中都会多出一段邮件会话行为契约。同一段注入代码还会检查 handler 配置里的agent_instructions字段若存在则再追加 fw.email.user_message_instructions.md一个只含{{instructions}}占位符的模板。这意味着运维者可以在不改插件代码的前提下为每个 handler 追加个性化邮件规则而本文分析的系统提示文件则是所有 handler 共享的基线契约。原文档核心规则逐条解析原提示词全文极简但每条都对应插件中的一个具体机制user communicates via email response tool send email to user dont use code to send email break_loop true stop working and wait for user reply break_loop false only for mid-task progress updates then keep working include file paths in attachments array multiple files zip first attach single archive1. 用户通过邮件交流response 工具就是发信动作在普通 WebUI 会话中response工具只是把最终答复渲染到界面。而在邮件会话中它被提升为唯一的对外通信通道调用response等价于给用户发一封回信。插件通过两个扩展点把这一点变成硬约束tool_execute_after 拦截器_50_email_response.py当tool_name response且上下文带有CTX_EMAIL_HANDLER时介入处理process_chain_end 扩展_55_email_reply.pyAgent 一轮工作结束时自动提取最后一条response日志内容并通过send_email_reply发出。2. 不要用代码发信提示词明确要求 Agent 不能自己写 Python 调 SMTP 发信dont use code to send email。原因在架构上很直接插件的发送路径是 handler.py 的send_email_reply它负责统一的会话元数据处理——回复主题改写为Re: ... [a0-thread_id]由 dispatcher.py 的build_reply_subject完成、维护In-Reply-To与References头、把上一封来信正文以引用块形式附在回复末尾On previous message:。如果 Agent 绕过response工具自己发信这些线程维护逻辑就会失效收信方邮件客户端也无法把回信折叠进同一会话线程。3.break_loop的两档语义这是原提示词的核心分支规则也是提示词与拦截器代码耦合最紧的地方break_loop取值提示词约定的用途底层行为true停止工作等待用户回复拦截器不做内联发送循环结束process_chain_end 扩展 在链尾自动发信含最多 2 次重试常量MAX_SEND_RETRIES 2false仅用于任务中途的进度更新发完继续干拦截器立即调用send_email_reply内联发出进度邮件并把工具结果改写为更新已发送继续工作或错误提示同时强制response.break_loop False让 Agent 继续循环拦截器中的关键分支_50_email_response.py# 捕获附件供链尾process_chain_end或内联发送使用 attachments tool.args.get(attachments, []) if attachments: context.data[CTX_EMAIL_ATTACHMENTS] attachments # 检查 Agent 给的 break_loop 参数 agent_break tool.args.get(break_loop, True) if agent_break is False and response: await self._send_inline(context, tool, response)_send_inline发送成功后会向历史写入 fw.email.update_ok.md 的一句话——email update sent, continue working失败则写入 fw.email.update_error.md 并带上具体错误。这正对应提示词中break_loop false only for mid-task progress updates then keep working的承诺进度邮件发出后 Agent 不中断例如跑一个耗时任务时先回一句正在处理……然后继续执行最终在break_loop: true的收尾回复里交付结果。4. 附件规则attachments数组 多文件先打包原提示词规定附件只放文件路径include file paths in attachments array多个文件先 zip 成一个归档再作为单个附件multiple files zip first attach single archive。代码侧的执行路径是拦截器把attachments存进context.data[CTX_EMAIL_ATTACHMENTS]注意该键带下划线前缀在 dispatcher.py 中被标注为transient—consumed per-reply, not persisted即每次回复后即消耗、不跨重启持久化真正发信时handler.py 的_read_attachments_via_rfc通过runtime.call_development_function(read_attachment, path)进入执行运行时读取每个文件、base64 解码后交给 SMTP 层。多文件先 zip的建议与这一机制相吻合附件按路径逐个读取打包单个归档在 MIME 构造与网络传输上都更稳健也避免发信方对附件数量/总大小的限制。原提示词给出的两个调用示例原文档最后给出的两段 JSON 是 Agent 在实际循环中调用response工具的两种典型形态此处完整保留形态一中途进度更新break_loop: false无附件发完继续工作{ ... tool_name: response, tool_args: { text: working on it..., break_loop: false } }形态二最终交付break_loop: true带 zip 附件路径{ ... tool_name: response, tool_args: { text: Here is..., attachments: [ /path/file.zip ], break_loop: true } }两个示例恰好覆盖提示词的全部变量组合text正文、break_loop是否收尾、attachments可选的文件路径数组。从源码看_send_inline取正文时兼容text与message两个字段名tool.args.get(text, tool.args.get(message, ))但按提示词约定应使用text。发信链路的纵深内联与链尾双路径、失败重试结合源码可以把这份提示词约束的行为落成两条具体链路break_loop: false内联路径tool_execute_after 拦截器 直接await send_email_reply(...)成功/失败结果即时写回 Agent 历史循环不中断。break_loop: true链尾路径拦截器只负责把attachments暂存进上下文Agent 循环结束后process_chain_end 扩展 异步执行_send_reply从上下文日志中倒序提取最后一条type response的条目作为正文连同暂存的附件一起发送。失败时把错误注入回 Agent使用 fw.email.send_failed.md 模板提示上一条回复并未送达重试或改用其他途径若附件导致问题则去掉附件重试累计失败超过MAX_SEND_RETRIES2 次后放弃并写入错误日志。send_email_reply 内部还体现了几个与提示词互补的细节回复主题始终携带[a0-thread_id]标记使下一封来信能靠 dispatcher.py 的正则_THREAD_ID_RE走快速路径直接路由回同一会话而不必再消耗一次 dispatcher 模型调用SMTP 配置优先取 handler 的smtp_server/smtp_port缺省回落到imap_server端口默认 587。适用前提handler 配置上述一切以 default_config.yaml 中的handlers列表非空为前提。注释里给出的示例 handler 展示了完整参数面# - name: support # enabled: true # provider: gmail # account_type: imap # imap_server: imap.gmail.com # imap_port: 993 # smtp_server: smtp.gmail.com # smtp_port: 587 # username: # password: # poll_mode: seconds # poll_interval_seconds: 15 # poll_interval_cron: */2 * * * * # process_unread_days: 0 # sender_whitelist: [] # project: # dispatcher_model: utility # chat_model_preset: # dispatcher_instructions: # agent_instructions: 与本文提示词直接相关的是agent_instructions非空时会被追加为会话级自定义规则是基线契约 个性化规则分层设计的落点account_type支持imap与exchange两种拉取模式见 README 与 imap_client.py。插件元数据 plugin.yaml 则声明该插件配置位于external设置分区、且不支持按项目/按 Agent 拆分配置即 handler 是全局共享的。小结fw.email.system_context_reply.md全文虽短却是 Agent Zero 邮件通道中Agent 侧契约的核心它把response工具重新定义为邮件出口用break_loop的布尔值区分收尾等待与中途进度两种节奏并规范了附件以路径数组传递、多文件先归档的投递方式。插件的 system_prompt 注入器、response 拦截器 与 链尾自动发信扩展 则保证了这些提示词规则不是软性建议而是有对应执行路径与失败重试机制的硬约束。理解这条链路后读者既能解释邮件会话中 Agent 的行为模式也能在agent_instructions中安全地扩展自己的邮件交互规则。【免费下载链接】agent-zeroAgent Zero AI framework项目地址: https://gitcode.com/GitHub_Trending/ag/agent-zero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Agent Zero 邮件集成：`fw.email.system_context_reply.md` 如何约束 response 工具、break_loop 语义与附件投递
Agent Zero 邮件集成fw.email.system_context_reply.md如何约束 response 工具、break_loop 语义与附件投递【免费下载链接】agent-zeroAgent Zero AI framework项目地址: https://gitcode.com/GitHub_Trending/ag/agent-zero本文围绕 Agent Zero 邮件插件_email_integration中回复阶段的系统提示词文件 fw.email.system_context_reply.md 展开逐条解析它对 Agent 回复行为的约束——response 工具即邮件出口、break_loop的真假语义、附件数组与多文件打包规则并结合插件的扩展点源码system_prompt 注入器、response 拦截器、自动发信扩展说明这些提示词规则如何被底层代码强制执行最终帮助读者掌握邮件会话中消息—回复—附件的完整投递链路。提示词的定位仅注入到已有邮件会话的系统提示这个文件的定位写在标题里——Email session behavior邮件会话行为。它不是通用系统提示的一部分而是只在某个上下文被标记为邮件会话时才被追加进系统提示。注入逻辑在 system_prompt 扩展 中handler_name self.agent.context.data.get(CTX_EMAIL_HANDLER) if not handler_name: return system_prompt.append( self.agent.read_prompt(fw.email.system_context_reply.md) )判断依据是上下文数据中的email_handler键常量CTX_EMAIL_HANDLER定义于 dispatcher.py。该键在邮件入站被路由到新会话时写入handler.py 的_start_new_chat会把handler_name、发件人、主题、thread_id、Message-Id、References一并存入context.data。也就是说凡是经由该 handler 邮件通道进入的聊天Agent 的系统提示中都会多出一段邮件会话行为契约。同一段注入代码还会检查 handler 配置里的agent_instructions字段若存在则再追加 fw.email.user_message_instructions.md一个只含{{instructions}}占位符的模板。这意味着运维者可以在不改插件代码的前提下为每个 handler 追加个性化邮件规则而本文分析的系统提示文件则是所有 handler 共享的基线契约。原文档核心规则逐条解析原提示词全文极简但每条都对应插件中的一个具体机制user communicates via email response tool send email to user dont use code to send email break_loop true stop working and wait for user reply break_loop false only for mid-task progress updates then keep working include file paths in attachments array multiple files zip first attach single archive1. 用户通过邮件交流response 工具就是发信动作在普通 WebUI 会话中response工具只是把最终答复渲染到界面。而在邮件会话中它被提升为唯一的对外通信通道调用response等价于给用户发一封回信。插件通过两个扩展点把这一点变成硬约束tool_execute_after 拦截器_50_email_response.py当tool_name response且上下文带有CTX_EMAIL_HANDLER时介入处理process_chain_end 扩展_55_email_reply.pyAgent 一轮工作结束时自动提取最后一条response日志内容并通过send_email_reply发出。2. 不要用代码发信提示词明确要求 Agent 不能自己写 Python 调 SMTP 发信dont use code to send email。原因在架构上很直接插件的发送路径是 handler.py 的send_email_reply它负责统一的会话元数据处理——回复主题改写为Re: ... [a0-thread_id]由 dispatcher.py 的build_reply_subject完成、维护In-Reply-To与References头、把上一封来信正文以引用块形式附在回复末尾On previous message:。如果 Agent 绕过response工具自己发信这些线程维护逻辑就会失效收信方邮件客户端也无法把回信折叠进同一会话线程。3.break_loop的两档语义这是原提示词的核心分支规则也是提示词与拦截器代码耦合最紧的地方break_loop取值提示词约定的用途底层行为true停止工作等待用户回复拦截器不做内联发送循环结束process_chain_end 扩展 在链尾自动发信含最多 2 次重试常量MAX_SEND_RETRIES 2false仅用于任务中途的进度更新发完继续干拦截器立即调用send_email_reply内联发出进度邮件并把工具结果改写为更新已发送继续工作或错误提示同时强制response.break_loop False让 Agent 继续循环拦截器中的关键分支_50_email_response.py# 捕获附件供链尾process_chain_end或内联发送使用 attachments tool.args.get(attachments, []) if attachments: context.data[CTX_EMAIL_ATTACHMENTS] attachments # 检查 Agent 给的 break_loop 参数 agent_break tool.args.get(break_loop, True) if agent_break is False and response: await self._send_inline(context, tool, response)_send_inline发送成功后会向历史写入 fw.email.update_ok.md 的一句话——email update sent, continue working失败则写入 fw.email.update_error.md 并带上具体错误。这正对应提示词中break_loop false only for mid-task progress updates then keep working的承诺进度邮件发出后 Agent 不中断例如跑一个耗时任务时先回一句正在处理……然后继续执行最终在break_loop: true的收尾回复里交付结果。4. 附件规则attachments数组 多文件先打包原提示词规定附件只放文件路径include file paths in attachments array多个文件先 zip 成一个归档再作为单个附件multiple files zip first attach single archive。代码侧的执行路径是拦截器把attachments存进context.data[CTX_EMAIL_ATTACHMENTS]注意该键带下划线前缀在 dispatcher.py 中被标注为transient—consumed per-reply, not persisted即每次回复后即消耗、不跨重启持久化真正发信时handler.py 的_read_attachments_via_rfc通过runtime.call_development_function(read_attachment, path)进入执行运行时读取每个文件、base64 解码后交给 SMTP 层。多文件先 zip的建议与这一机制相吻合附件按路径逐个读取打包单个归档在 MIME 构造与网络传输上都更稳健也避免发信方对附件数量/总大小的限制。原提示词给出的两个调用示例原文档最后给出的两段 JSON 是 Agent 在实际循环中调用response工具的两种典型形态此处完整保留形态一中途进度更新break_loop: false无附件发完继续工作{ ... tool_name: response, tool_args: { text: working on it..., break_loop: false } }形态二最终交付break_loop: true带 zip 附件路径{ ... tool_name: response, tool_args: { text: Here is..., attachments: [ /path/file.zip ], break_loop: true } }两个示例恰好覆盖提示词的全部变量组合text正文、break_loop是否收尾、attachments可选的文件路径数组。从源码看_send_inline取正文时兼容text与message两个字段名tool.args.get(text, tool.args.get(message, ))但按提示词约定应使用text。发信链路的纵深内联与链尾双路径、失败重试结合源码可以把这份提示词约束的行为落成两条具体链路break_loop: false内联路径tool_execute_after 拦截器 直接await send_email_reply(...)成功/失败结果即时写回 Agent 历史循环不中断。break_loop: true链尾路径拦截器只负责把attachments暂存进上下文Agent 循环结束后process_chain_end 扩展 异步执行_send_reply从上下文日志中倒序提取最后一条type response的条目作为正文连同暂存的附件一起发送。失败时把错误注入回 Agent使用 fw.email.send_failed.md 模板提示上一条回复并未送达重试或改用其他途径若附件导致问题则去掉附件重试累计失败超过MAX_SEND_RETRIES2 次后放弃并写入错误日志。send_email_reply 内部还体现了几个与提示词互补的细节回复主题始终携带[a0-thread_id]标记使下一封来信能靠 dispatcher.py 的正则_THREAD_ID_RE走快速路径直接路由回同一会话而不必再消耗一次 dispatcher 模型调用SMTP 配置优先取 handler 的smtp_server/smtp_port缺省回落到imap_server端口默认 587。适用前提handler 配置上述一切以 default_config.yaml 中的handlers列表非空为前提。注释里给出的示例 handler 展示了完整参数面# - name: support # enabled: true # provider: gmail # account_type: imap # imap_server: imap.gmail.com # imap_port: 993 # smtp_server: smtp.gmail.com # smtp_port: 587 # username: # password: # poll_mode: seconds # poll_interval_seconds: 15 # poll_interval_cron: */2 * * * * # process_unread_days: 0 # sender_whitelist: [] # project: # dispatcher_model: utility # chat_model_preset: # dispatcher_instructions: # agent_instructions: 与本文提示词直接相关的是agent_instructions非空时会被追加为会话级自定义规则是基线契约 个性化规则分层设计的落点account_type支持imap与exchange两种拉取模式见 README 与 imap_client.py。插件元数据 plugin.yaml 则声明该插件配置位于external设置分区、且不支持按项目/按 Agent 拆分配置即 handler 是全局共享的。小结fw.email.system_context_reply.md全文虽短却是 Agent Zero 邮件通道中Agent 侧契约的核心它把response工具重新定义为邮件出口用break_loop的布尔值区分收尾等待与中途进度两种节奏并规范了附件以路径数组传递、多文件先归档的投递方式。插件的 system_prompt 注入器、response 拦截器 与 链尾自动发信扩展 则保证了这些提示词规则不是软性建议而是有对应执行路径与失败重试机制的硬约束。理解这条链路后读者既能解释邮件会话中 Agent 的行为模式也能在agent_instructions中安全地扩展自己的邮件交互规则。【免费下载链接】agent-zeroAgent Zero AI framework项目地址: https://gitcode.com/GitHub_Trending/ag/agent-zero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考