COHAO 共好

社区已经可以注册、发帖和回复，但“服务启动成功”不等于真实设备上的流程顺畅。这个任务邀请你用自己的浏览器完成一次小范围体验测试。 测试路径 未登录阅读首页、分类和一个主题。 注册一个账号；现阶段邮箱不是必填项。 创建一篇测试主题，正文至少写明设备和浏览器。 确认首篇内容进入审核提示，而不是悄悄消失。 审核通过后登录、退出、再次登录。 回复、搜索、收藏或关注一个主题。 尝试举报本任务，并确认能看到合理反馈。 回报问题时请写 测试时间与时区： 设备与屏幕尺寸： 操作系统： 浏览器与版本： 网络环境： 执行到哪一步： 期望看到什么： 实际看到什么： 是否可稳定复现： 截图或录屏：请先遮住账号、Cookie 和个人信息 不要为了测试发布攻击性、违法或大量重复内容，也不要扫描非公开端口。涉及安全漏洞时先通过管理员可见的举报说明最小影响，不在公开回复中放可直接利用的细节。 编辑部会公开更新已确认问题、修复版本和复测状态，不伪造测试人数或成功率。 任务发布：2026-08-15。AI 协助起草测试步骤，项目负责人复核。

COHAO 的第一个公共作品候选是《AI Agent 工具可靠性报告》。在比较任何工具前，我们先需要一份足够小、又能支持复现的数据结构。 本轮目标 共同评审下面这些字段，找出缺失、重复和无法稳定采集的部分。暂时不比较品牌，不要求跑大规模测试。 case_id: recorded_at: operator_type: human | agent | hybrid task_category: task_description: model_name: model_version_or_date: client_or_sdk_version: runtime_environment: region: input_reference: tool_permissions: forbidden_actions: timeout_seconds: max_retries: budget_limit: expected_result: actual_status: success | partial | failed | unknown | aborted output_reference: evidence_reference: tool_call_count: latency_ms: token_usage: api_cost: human_minutes: failure_stage: error_class: retry_safe: root_cause_status: verified | suspected | unknown recovery_action: remaining_risk: 参与方式 选择一个字段，说明它为什么必要或为什么应该删除。 提交一个脱敏的真实案例，看这份结构能否完整表达。 提议枚举值时，给出至少两个会被区分的实际例子。 检查哪些字段可能泄露密钥、个人信息或客户数据。 完成标准：形成 v0.2 字段表、每个字段的定义、一个最小示例和一份隐私检查清单。所有修改通过本主题公开记录。 任务发布：2026-08-15。COHAO 编辑部使用 AI 协助把现有报告章程转为可评论的数据结构，项目负责人复核。

COHAO 的长期设想是让贡献者和未来建设者共享社区创造的价值。但如果一开始就把每个动作换算成积分、价格和排名，成员很容易开始优化分数，而不是帮助别人。 创世期准备先做“影子贡献账本”：记录发生了什么，不公开实时财富估值，也不承诺兑换。 可能记录的贡献包括： 原创实践、失败复盘和评测。 复现、纠错、补充证据与版本维护。 高质量答疑、新人欢迎和问题整理。 翻译、编辑、主持、活动和文档维护。 安全报告、财务透明与公共基础设施。 我们需要一起回答： 怎样区分一次性输出和长期维护？ 无法公开的安全、照顾和协调劳动怎样被看见？ 纠错是否应与原创同等重要？ 如何防止互刷、拆分任务和低质量数量竞争？ 未来成员应保留多大比例，谁来代表他们？ 哪些贡献不应该被货币化？ 欢迎给出你见过的好制度和失败案例。这个主题讨论的是记录原则，不代表已经确定分配公式或收益承诺。 编辑说明：2026-08-15，COHAO 编辑部根据社区 5/95 价值共享蓝图提出问题；AI 协助起草，项目负责人复核。

AI 信息很多，但真正稀缺的是半年后仍有人愿意更新的内容。我们想知道：对正在开发、交付或评测 AI 系统的人来说，什么值得成为长期维护的公共知识？ 你可以从下面几类中选择，也可以提出新的类型： 会随版本变化的工具兼容表。 成本、延迟与稳定性基准。 常见失败案例与修复状态。 权限、隐私和安全检查表。 可复用的评测集与评分说明。 中文环境特有的部署、支付、数据或协作问题。 新人能完成的小型复现任务。 回复时最好说明： 谁会在什么任务里用到它。 现有资料为什么不够。 多久需要更新一次。 更新需要什么证据。 你愿意贡献一次、复核一次，还是长期维护一小部分。 我们不会用点赞数直接决定优先级。更重要的是问题是否重复出现、错误是否造成真实代价、内容能否复现，以及是否有人愿意承担维护。 编辑说明：2026-08-15，COHAO 编辑部发起的开放问题。AI 协助起草，项目负责人复核。

不要只说“Agent 不稳定”。请选一个你真实遇到、愿意公开讨论的失败，让其他人有机会复现它。 建议按下面格式回复： 任务想完成什么： 发生日期： 工具、模型和版本： 运行环境： 允许的工具与权限： 最小输入或触发条件： 期望结果： 实际结果： 是否每次发生： 错误日志或脱敏证据： 你已经试过什么： 哪些解释只是推测： 是否涉及隐私、生产或付费操作： 希望社区帮你复现、定位还是设计规避方案： 请不要贴密码、Cookie、Token、客户数据、未授权代码或能识别个人的信息。如果无法公开原始材料，可以构造一个最小脱敏样本，并说明它与真实环境的差异。 编辑部会从回复中选择边界清楚、可复现且有普遍价值的问题，协助整理成失败案例；不会把未发生的推测包装成结论。 编辑说明：2026-08-15，COHAO 编辑部发起的开放问题。AI 协助整理提问模板，项目负责人复核。

2025-01-20，DeepSeek 发布并开放 DeepSeek-R1 系列模型、论文与蒸馏模型权重。它让更多团队可以直接研究、部署和改造推理模型，而不只通过封闭 API 观察输出。 三个现实变化 推理过程研究门槛降低 开放模型与论文让研究者能够检查训练方法、复现实验、比较蒸馏效果，并在自己的评测集上研究推理能力与失败模式。 本地与私有部署选择增加 不同规模的蒸馏模型让团队可以在本地硬件上尝试推理工作负载。不过“能运行”不等于质量、速度和总成本适合生产，仍要用自己的任务评测。 模型能力不等于系统可靠性 更强推理仍可能产生错误事实、冗长过程、工具误用和提示注入风险。生产系统还需要权限、验证、状态管理、超时、成本控制和人工接管。 使用开放权重时要额外记录 模型具体变体、量化方式、推理引擎、上下文设置、采样参数、硬件与许可证。不同部署组合可能让同名模型表现明显不同。 一手来源： https://github.com/deepseek-ai/DeepSeek-R1 https://arxiv.org/abs/2501.12948 编辑说明：本文按 2025-01-20 的官方发布记录整理，并于 2026-08-15 核对仓库与论文页面。AI 协助起草，项目负责人复核。

2025-04-09，Google 公布 Agent2Agent（A2A）协议，目标是让不同厂商、不同框架构建的 Agent 能发现彼此能力、协商任务、交换消息并跟踪长期任务状态。 它面对的问题 当一个采购 Agent、供应商 Agent 和物流 Agent 来自不同系统时，单纯共享一个工具调用格式并不够。参与方需要知道对方能做什么、如何发送任务、任务是进行中还是等待输入，以及结果以什么形式返回。 A2A 引入 Agent Card、任务、消息和工件等概念，试图给跨 Agent 协作一个共同协议层。 与 MCP 的关系 可以粗略理解为：MCP 更关注 Agent 如何连接工具与上下文，A2A 更关注独立 Agent 之间如何协作。两者可能组合使用，但解决层次不同，也都不会自动处理业务授权和信任。 仍需工程回答的问题 怎样验证对方 Agent 的身份与组织关系。 怎样限制它能看到的任务和数据。 谁对跨 Agent 的错误决定负责。 长任务如何取消、超时、补偿和审计。 协议兼容是否真的意味着语义一致。 对 COHAO 来说，跨 Agent 协作是后续能力，不是创世期前置条件。先把单个受限工具和人工接管做好，再谈 Agent 之间自治。 一手来源： https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/ https://github.com/a2aproject/A2A https://a2a-protocol.org/ 编辑说明：本文按 2025-04-09 的公开发布解读，并于 2026-08-15 核对官方来源。AI 协助起草，项目负责人复核。

2025-03-11，OpenAI 在发布构建 Agent 的新工具时开源了 Agents SDK。它延续了较轻量的编排思路，把 Agent、工具、交接、Guardrails 和 Tracing 放到一个可组合的运行模型里。 值得关注的不是“又一个框架” 追踪成为一等能力 复杂 Agent 的问题通常不在最终一句回答，而在中间选了什么工具、传了什么参数、在哪一步失败。Tracing 让团队有机会把这些步骤转成调试和评测证据。 交接有明确结构 不同 Agent 可以各自承担窄职责，再通过 handoff 转移任务。它比让一个万能 Agent 拥有所有工具更容易限制上下文和权限，但交接本身仍需测试，不能把责任一起丢掉。 Guardrails 不是完整权限系统 输入输出检查可以降低明显错误，却不能替代后端认证、对象所有权、幂等和人工确认。真正的工具权限仍应由业务系统决定。 什么时候不需要 如果任务只是一次模型调用加一个只读查询，普通函数和清晰日志可能已经足够。框架的价值要由真实工作流、可观测性和维护成本证明，而不是由示例代码长度证明。 一手来源： https://openai.com/index/new-tools-for-building-agents/ https://github.com/openai/openai-agents-python https://openai.github.io/openai-agents-python/ 编辑说明：本文按 2025-03-11 的发布背景解读，并于 2026-08-15 核对官方来源。AI 协助起草，项目负责人复核。

2024-11-25，Anthropic 公布 Model Context Protocol（MCP），把它定义为连接 AI 助手与数据源、工具和开发环境的开放标准。它试图减少一种长期重复工作：每个模型应用都为每个外部系统单独写一套连接器。 它标准化了什么 服务端如何暴露资源、提示和工具。 客户端如何发现能力并发起调用。 本地进程和远程服务的连接方式。 工具描述、输入结构和结果返回的共同语言。 这使“支持某个数据源”更可能成为可复用的服务能力，而不是只存在于一个 Agent 框架里的私有适配器。 它没有自动解决什么 MCP 不会替你完成身份认证、对象所有权、租户隔离、高风险确认、幂等、审计和密钥管理。一个 MCP 工具即使协议完全正确，也可能拥有过宽权限，或被提示注入诱导执行错误动作。 对社区 Agent 的意义 COHAO 未来可以把“检查来源”“读取公开主题”“生成待审核草稿”等能力做成窄工具，并通过标准协议接入不同 Agent。但协议层之上仍要由后端确定身份、权限和操作范围；管理员、资金和角色修改不会因为使用 MCP 就变安全。 一手来源： https://www.anthropic.com/news/model-context-protocol https://modelcontextprotocol.io/ https://github.com/modelcontextprotocol 编辑说明：本文解读截至 2026-08-15，重点是协议边界，不代表对所有 MCP 实现的安全背书。AI 协助起草，项目负责人核验来源。

COHAO 原本已经有一个自研的创世申请工作台，但它不具备完整内容社区所需的账号、主题、回复、搜索、通知、举报和审核体验。继续从零开发，会把时间花在重复建设基础能力，而不是内容与关系。 因此我们选择 NodeBB 作为当前社区底座，并保留旧工作台、SQLite 数据、备份和发布目录作为回滚与运营资料。 当前采用的版本与部署 NodeBB v4.14.10，核验日期 2026-08-15。 PostgreSQL 单机数据库，NodeBB 单实例运行。 应用只监听服务器回环地址，由现有 Nginx 和 TLS 对外提供服务。 开放注册，不强制邮箱；新账号第一次内容进入人工审核。 暂时关闭私聊、私有群组和 ActivityPub，降低创世期审核面。 为什么适合现在 已有成熟的主题、回复、标签、搜索、书签、关注、通知、举报和审核队列。 Node.js 技术栈与现有项目接近，4 核、约 4GB 内存的服务器可以承载早期单实例。 REST API 和插件机制允许 Agent 以后通过窄接口辅助整理，但不需要给它数据库或管理员权限。 中文界面已经包含在官方发行版中。 当前限制 尚未配置 SMTP，所以邮件验证、通知和自助找回密码暂不可用。 首帖审核需要真人及时处理，不能靠 Agent 自动放行。 单实例适合创世期；扩容、多节点缓存和搜索增强要由真实负载触发。 选择成熟引擎不是把社区交给软件决定。栏目、文化、内容质量、权限和收入分配仍然由 COHAO 的公开制度负责。 参考： https://github.com/NodeBB/NodeBB/releases/tag/v4.14.10 https://docs.nodebb.org/ 编辑说明：2026-08-15，本文记录 COHAO 的真实技术选择；AI 协助起草，项目负责人复核。

RAG 项目常常一开始就选择向量数据库，但很多知识库问题其实来自分段、权限、版本和答案评测，而不是缺少一种更强的检索算法。 三种路径 关键词检索 适合错误码、型号、文件名、专有名词和精确短语。优点是可解释、成本低；缺点是对同义表达和自然语言问题不够敏感。 向量检索 适合语义相近但用词不同的内容。优点是召回更灵活；缺点是可能召回“主题相近但答案不对”的片段，也需要嵌入版本、索引和阈值管理。 混合检索 把关键词与向量结果合并，再用规则或重排模型排序。通常更稳，但系统复杂度、延迟和调试成本更高。 先做这四件事 建立真实问题集，并标注应该命中的文档和答案。 给文档加版本、生效时间、所有者、权限和来源元数据。 设计分段，使每个片段足够独立，又保留标题和上下文。 分别测召回、最终答案和拒答，不用“找到了相似内容”代替正确回答。 一个实用默认值 从关键词检索加少量语义召回开始；只有真实问题集证明召回不足时，再增加复杂重排。任何检索都必须在查询前做权限过滤或在可靠的安全边界内过滤，不能先把不该看的内容交给模型再要求它忘记。 编辑说明：2026-08-15，COHAO 编辑部依据 RAG 工程通用实践整理；AI 协助起草，项目负责人复核。

本地模型和托管 API 经常被写成价值观选择，实际系统更适合按任务和数据分层。 维度 本地模型 托管 API 混合架构 数据控制 可完全留在自有环境 取决于服务条款与配置 敏感任务本地，其余托管 前期投入 硬件、部署和运维较高 接入快，按用量付费 需要路由与两套运维 峰值弹性 受本地容量限制 通常更容易扩缩 可把峰值溢出到托管端 模型更新 自己决定升级节奏 能力更新快但可能变化 需要持续兼容性评测 故障类型 显存、驱动、量化与容量 限流、网络、区域与服务变化 路由错误和结果不一致增加 先按任务分类 固定格式抽取、分类和低风险批处理，可能适合本地小模型。 复杂推理、图像或最新能力，可能适合托管 API。 含高敏感数据且不能脱敏的任务，应先满足数据和合规边界，再比较质量。 关键业务不应只看平均质量，还要测试超时、限流、降级和人工接管。 混合架构最容易被低估的成本 同一任务在不同模型间的行为、格式和安全边界可能不一致。路由器需要版本化策略、回归评测、结果标记和失败回退，不能只依据“哪个便宜”随机切换。 结论不是三选一，而是给每类任务找到可解释的执行路径，并保留替换能力。 编辑说明：2026-08-15，本文是架构比较框架，不代表对任何具体服务的价格或能力作实时断言。AI 协助起草，项目负责人复核。

“哪个 Agent 框架最好”通常不是一个能脱离任务回答的问题。先把下面八个问题写清楚，候选范围往往会自动缩小。 任务是一次性编排还是长期状态机？ 一次调用几个工具与运行数小时、可暂停恢复的任务，需要的基础设施不同。 哪些动作有副作用？ 只读检索和付款、删除、公开发布不能使用同一权限模型。 是否需要人工确认与接管？ 确认必须能绑定对象和版本，并在恢复后继续。 状态保存在哪里？ Prompt、内存、数据库和事件日志分别承担什么角色。 怎样测试？ 能否替换模型、模拟工具超时、固定随机性并运行回归集。 怎样观测？ 是否记录每步输入摘要、工具调用、延迟、成本、错误和最终责任人。 部署约束是什么？ 语言、云、本地、数据边界、并发、冷启动和团队已有能力。 退出成本多大？ 工作流、工具协议和业务状态是否被锁在框架私有格式中。 一个保守的选择顺序 先用普通函数和明确状态完成单步工具调用。 确实需要循环、分支和恢复时，再引入图或工作流框架。 需要跨系统、跨团队协作时，优先使用开放接口封装工具与消息，不把业务对象塞进框架内部状态。 评测框架时，用同一组真实任务比较完成率、人工接管、重复执行、调试时间和迁移难度。演示代码短不等于生产总成本低。 编辑说明：2026-08-15，本文提供中立选型维度，不构成对某个具体框架的当前排名。AI 协助起草，项目负责人复核。

空社区最让人焦虑，于是很容易想到一个办法：让 AI 一次生成几百篇帖子，再让多个账号互相回复，先把页面填满。 这会同时制造三个假象：好像已经有人使用，好像内容经过讨论，好像社区已经形成共识。新用户一旦发现这些互动不是人发生的，信任损失比看到一个安静的新社区更难修复。 批量内容为什么救不了冷启动 它回答的是编辑部想象的问题，不是成员正在付出成本的问题。 没有人对结果负责，错误和过期内容很快堆积。 回复数量上升，但真实关系、答疑和共同工作没有增加。 数据指标失真，团队无法判断哪些内容真的有价值。 COHAO 采用的替代方案 编辑部只发布数量有限、来源透明的种子内容。 所有种子帖标记 AI 协助与人工复核，不伪装普通成员。 留出明确问题和公开任务，让真实参与从纠错、复现和补充开始。 统计真实用户、有效回复、被解决的问题和持续维护，不把编辑部批量输出算作社区活跃。 社区可以从内容开始，但内容必须给真人留下位置，而不是提前替真人把所有话都说完。 编辑说明：2026-08-15，本文说明 COHAO 的冷启动选择，不声称存在已经发生的批量造假事件。AI 协助起草，项目负责人复核。

密钥一旦进入对话、终端回显、日志、截图或错误上报，之后把那一行删除并不等于风险消失。它可能已经被同步到备份、日志平台、浏览器历史、剪贴板、会话记录或第三方监控。 常见入口 在命令行参数里直接传密码，随后被进程列表或 shell 历史记录。 为了排查问题打印完整环境变量或请求头。 把真实配置文件贴给 Agent，让模型“帮忙看看”。 错误处理把 Cookie、Authorization 或数据库 URL 一并记录。 截图里出现二维码、Token、邮箱验证码或管理地址。 发现后应该做什么 立即撤销或轮换密钥，不把“已经删除”当作补救完成。 查清它出现在哪些系统、备份和人员可见范围内。 检查密钥使用日志与异常访问。 修复产生泄露的日志、调试和工具接口。 记录事件时间线，但在事件记录中也不要再次复制秘密。 预防比清理便宜 使用受限环境文件、密钥管理服务、标准输入或短期凭据；日志默认脱敏；Agent 工具只接收业务参数，不接收原始密钥。生产凭据不进入仓库、文档和聊天。 编辑说明：2026-08-15，COHAO 编辑部根据生产运维通用原则整理；AI 协助起草，项目负责人复核。

把后台管理员账号直接交给 Agent，看起来可以少写很多工具接口：模型想查什么就查，想改什么就改。但一旦出现误删、越权或提示注入，系统很难回答三个基本问题：谁授权的、允许到哪里、怎样撤销。 这种设计会失去什么 对象边界：管理员通常能看到所有租户和用户，模型只靠提示词区分不了所有权。 动作边界：查看、编辑、封禁、退款和改权限被压缩成同一个高权限会话。 责任边界：日志只显示管理员账号，无法区分用户意图、模型决策和工具执行。 故障边界：凭据泄露或插件被污染时，影响范围是整个系统。 更窄的替代方案 为每类允许动作建立专门工具，例如“读取本人订单状态”“为本人草稿生成摘要”“提交待审核的退款申请”。后端从认证会话派生用户与站点，检查对象所有权，限制字段，记录确认和幂等键。 模型不应该拥有数据库、管理员面板、角色修改、钱包或密钥管理入口。即使未来 Agent 更聪明，这些边界也不会过时，因为它们解决的是责任与权限问题，不是语言理解问题。 编辑说明：2026-08-15，本文是上线前威胁建模，不声称 COHAO 已发生该事故。AI 协助起草，项目负责人复核。

下面不是虚构事故，而是一种需要在上线前主动防住的常见失败模式。 假设 Agent 调用“发布文章”工具，外部服务已经收到请求并成功创建文章，但响应在返回途中超时。Agent 只看到超时，于是再次调用，最终产生两篇完全相同的文章。 为什么普通重试策略失效 超时表达的是结果未知，不是执行失败。 创建、付款、发送、删除等写操作通常不是天然幂等。 模型可能把“再试一次”理解为最合理的恢复动作。 如果日志只记录返回结果，没有记录提交前状态，就很难判断第一次是否发生。 应该怎么设计 每次业务动作由后端生成稳定幂等键。 工具先写入 pending 状态，再发送外部请求。 超时进入 unknown，随后用查询接口或外部请求标识核验。 只有后端确认第一次未发生，才允许重新执行。 如果无法查询，就转人工，不让 Agent无限重试。 验收测试 测试时故意在“外部已成功、响应未返回”的位置断网，验证系统只产生一个对象，并且最终能从 unknown 收敛到 succeeded 或人工处理。 编辑说明：2026-08-15，COHAO 编辑部将通用分布式系统风险转化为 Agent 工具调用检查项；AI 协助起草，项目负责人复核。

这是一条真实的项目复盘。我们在为 COHAO 创世方案补研究依据时，曾经根据搜索结果摘要组装论文引用。摘要看起来支持结论，但进一步核对后发现，部分论文编号、标题和主张范围并不对应。 失败是怎么发生的 搜索摘要截断了原文，只保留最像答案的一段。 相近主题的论文被混在一起，标题、作者、编号和结论发生错配。 二手页面把相关性写成因果性，计划稿又把它当成原论文主张。 引用格式正确，让错误显得比普通文字更可信。 修复流程 通过论文主页、DOI、Crossref 或 arXiv API核对标题、作者、日期和标识符。 阅读摘要和与主张直接相关的段落，不根据搜索摘要扩张结论。 把“论文发现”“作者讨论”“我们的推断”分开写。 对每个引用保留主张到来源的映射，自动检查正文引用与参考文献是否一一对应。 后续规则 搜索结果只能用来发现候选来源，不能单独作为研究结论的证据。一个引用如果无法回答“原文到底说了什么、适用于什么范围”，宁可暂时不写。 这次修正后的研究稿重新核验了论文标题、作者、摘要与主张范围，也让我们把“来源核验”列为编辑部 Agent 可以协助、但必须由人负责的流程。 编辑说明：复盘事件发生于 COHAO 方案研究阶段，本文于 2026-08-15 整理。AI 协助结构化，项目负责人核对事实。

长任务最危险的并不总是模型能力不足，而是目标、事实和边界在几十次工具调用后悄悄漂移。一个好的检查点应该让任务被打断后可以继续，也让人能发现它正在回答旧问题。 三份持续更新的状态 事实表 只记录已经验证的事实、证据位置和时间。易变化的信息带日期；不确定内容明确标记为假设。 决策表 记录已经确认的选择、否决项、理由和生效范围。新消息与旧决定冲突时，先停下来处理冲突。 执行表 每个步骤只有 pending、in_progress、completed 三种状态，并写出验收证据。任何时刻最多一个主要步骤处于进行中。 什么时候建立检查点 完成一个可独立验收的阶段后。 即将进行不可逆或高风险操作前。 工具返回异常、环境发生变化或用户追加要求后。 上下文将被压缩、任务将转交或运行时间较长时。 停止条件比“继续努力”更重要 提前定义预算、最长运行时间、最大重试次数、允许修改的对象和必须转人工的事件。检查点不是为了让 Agent 永远运行，而是为了让它知道何时应该停。 编辑说明：2026-08-15，COHAO 编辑部基于长任务执行和社区建设记录整理；AI 协助起草，项目负责人复核。

Agent 调用外部工具时，网络超时只说明“没有收到结果”，不说明“操作没有发生”。如果收到超时就盲目重试，可能重复付款、重复发帖、重复发信或重复创建资源。 最小幂等设计 在业务层生成幂等键，例如 actor + action + object + confirmed_version 的稳定摘要。 工具执行前记录 pending，并以唯一约束保证同一个键只能创建一次。 外部系统支持幂等键时，把同一个键传给它；不支持时，在本地状态机中保存外部请求标识。 超时后先查询状态，不立即再次执行。 结果进入 succeeded、failed、unknown 或 needs_review，不要把“未知”伪装成失败。 为无法原子回滚的动作准备补偿，例如撤销草稿、退款申请或人工复核单。 Agent 应该看到什么 模型可以得到经过裁剪的状态，例如“请求已经提交，结果未知，请等待查询”，而不是数据库连接和任意重试工具。是否允许重试由后端状态机判断。 一个简单的停止条件 出现以下任一情况就转人工：外部结果未知、高价值或不可逆动作、幂等状态冲突、对象版本已经变化、确认已过期。 可靠性不是“多重试几次”，而是知道每一次执行是否发生、现在处于什么状态、下一步由谁负责。 编辑说明：2026-08-15，COHAO 编辑部根据外部工具调用与支付类系统的通用工程模式整理；AI 协助起草，项目负责人复核。