English | 中文
这个页面专门展示 agent 在“已经做完决策之后”,应该把什么样的最小出站对象交还给 MailCLI。
重点不是教 MIME。
重点是让开发者快速看懂三种最常见的出站边界:
- 简短确认回复
- 稍复杂的支持型回复
- 全新发起的一封邮件
- ack-reply.draft.json
- ack-reply.mime.txt
- minimal-reply.reply.json
- minimal-reply.mime.txt
- support-followup.reply.json
- support-followup.mime.txt
- release-update.draft.json
- release-update.mime.txt
这些固定 MIME 文件对运行时生成的 Message-ID 和 multipart boundary 做了归一化处理,方便阅读和版本管理。
当 agent 已经选中了本地消息或 thread,只需要回一条安全、简短的确认时,使用这个模式。
草稿边界:
{
"account": "fixtures",
"from": { "address": "support@nono.im" },
"to": [{ "address": "billing@example.com", "name": "Billing Team" }],
"body_text": "Thanks, we received the invoice notification and queued it for processing.",
"reply_to_id": "invoice.eml"
}编译命令:
mailcli reply --config examples/config/fixtures-dir.yaml --account fixtures --dry-run examples/artifacts/outbound-patterns/ack-reply.draft.json这个形态的价值:
reply_to_id允许 MailCLI 回抓原邮件并自动推导线程头- 当
to省略时,MailCLI 也可以从原邮件里补默认回复收件人 - agent 不需要自己拼
In-Reply-To或References - 它非常适合零网络 demo 和本地检索闭环
当 agent 已经决定要回复哪封邮件,而且你希望把 reply draft 压缩到最小边界时,使用这个模式。
草稿边界:
{
"account": "fixtures",
"body_text": "Thanks, we received the invoice notification and queued it for processing.",
"reply_to_id": "invoice.eml"
}编译命令:
mailcli reply --config examples/config/fixtures-dir.yaml --account fixtures --dry-run examples/artifacts/outbound-patterns/minimal-reply.reply.json这个形态的价值:
- 当账户配置本身已经代表发信身份时,MailCLI 可以从 account 自动补
from.address - MailCLI 可以从原邮件里自动推导默认回复收件人
- 这是 agent 产出确认型回复时最小、最稳的 handoff 形式
当上游系统已经知道原始 Message-ID,而 agent 需要返回一条更完整的支持回复时,使用这个模式。
草稿边界:
{
"from": { "name": "Nono Support", "address": "support@nono.im" },
"to": [{ "address": "sender@example.com", "name": "Example Sender" }],
"subject": "Re: Plaintext message",
"body_text": "Hi,\n\nWe checked your request and need one detail before we can proceed:\n\n- workspace name\n- expected delivery date\n\nYou can reply directly to this thread.\n\nOriginal request received and queued.",
"body_md": "Hi,\n\nWe checked your request and need one detail before we can proceed:\n\n- workspace name\n- expected delivery date\n\nYou can reply directly to this thread.\n\n> Original request received and queued.",
"reply_to_message_id": "<plain-123@example.com>",
"references": ["<plain-123@example.com>"]
}编译命令:
mailcli reply --dry-run examples/artifacts/outbound-patterns/support-followup.reply.json这个形态的价值:
reply_to_message_id让草稿在无法重新抓取原邮件时仍然可用- 显式
references能跨 transport 保持 thread 连续性 body_md保留 richer 结构,而body_text提供稳妥的纯文本回退
当 agent 不是在回复现有线程,而是在主动发起一封新邮件时,使用这个模式。
草稿边界:
{
"from": { "name": "MailCLI Bot", "address": "updates@mailcli.dev" },
"to": [{ "address": "team@example.com", "name": "MailCLI Contributors" }],
"subject": "Weekly parser status",
"body_text": "Weekly parser status\n\nWe shipped three improvements:\n1. Better thread examples\n2. Safer zero-network onboarding\n3. Cleaner outbound MIME docs\n\nArea / Status\nParser fixtures / Stable\nThread examples / Expanded\nDriver docs / Ready for review\n\nExamples index: https://github.com/nonozone/MailCli/tree/main/docs/en/examples/README.md",
"body_md": "## Weekly parser status\n\nWe shipped three improvements:\n\n1. Better thread examples\n2. Safer zero-network onboarding\n3. Cleaner outbound MIME docs\n\n| Area | Status |\n| --- | --- |\n| Parser fixtures | Stable |\n| Thread examples | Expanded |\n| Driver docs | Ready for review |\n\nRead the [examples index](https://github.com/nonozone/MailCli/tree/main/docs/en/examples/README.md) for runnable flows."
}编译命令:
mailcli send --dry-run examples/artifacts/outbound-patterns/release-update.draft.json这个形态的价值:
- agent 停留在意图层,不需要手写 MIME
- MailCLI 可以自动输出
multipart/alternative - 这是状态通知、摘要汇总和自动化报告的基础模式
- 当 MailCLI 已经能访问原邮件时,优先用
reply_to_id。 - 当 account 配置应该负责发件人身份,且原邮件应该负责回复路由时,优先用极简
reply_to_id形态。 - 当 thread 元数据来自其他系统、需要保持可移植性时,用
reply_to_message_id加references。 - 当你要发起一个全新会话,不需要任何回复头时,用
DraftMessage。