社区已经可以注册、发帖和回复，但“服务启动成功”不等于真实设备上的流程顺畅。这个任务邀请你用自己的浏览器完成一次小范围体验测试。
测试时间与时区：
设备与屏幕尺寸：
操作系统：
浏览器与版本：
网络环境：
执行到哪一步：
期望看到什么：
实际看到什么：
是否可稳定复现：
截图或录屏：请先遮住账号、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 观察输出。
开放模型与论文让研究者能够检查训练方法、复现实验、比较蒸馏效果，并在自己的评测集上研究推理能力与失败模式。
不同规模的蒸馏模型让团队可以在本地硬件上尝试推理工作负载。不过“能运行”不等于质量、速度和总成本适合生产，仍要用自己的任务评测。
更强推理仍可能产生错误事实、冗长过程、工具误用和提示注入风险。生产系统还需要权限、验证、状态管理、超时、成本控制和人工接管。
模型具体变体、量化方式、推理引擎、上下文设置、采样参数、硬件与许可证。不同部署组合可能让同名模型表现明显不同。
一手来源：
编辑说明：本文按 2025-01-20 的官方发布记录整理，并于 2026-08-15 核对仓库与论文页面。AI 协助起草，项目负责人复核。
2025-04-09，Google 公布 Agent2Agent（A2A）协议，目标是让不同厂商、不同框架构建的 Agent 能发现彼此能力、协商任务、交换消息并跟踪长期任务状态。
当一个采购 Agent、供应商 Agent 和物流 Agent 来自不同系统时，单纯共享一个工具调用格式并不够。参与方需要知道对方能做什么、如何发送任务、任务是进行中还是等待输入，以及结果以什么形式返回。
A2A 引入 Agent Card、任务、消息和工件等概念，试图给跨 Agent 协作一个共同协议层。
可以粗略理解为：MCP 更关注 Agent 如何连接工具与上下文，A2A 更关注独立 Agent 之间如何协作。两者可能组合使用，但解决层次不同，也都不会自动处理业务授权和信任。
对 COHAO 来说，跨 Agent 协作是后续能力，不是创世期前置条件。先把单个受限工具和人工接管做好，再谈 Agent 之间自治。
一手来源：
编辑说明：本文按 2025-04-09 的公开发布解读，并于 2026-08-15 核对官方来源。AI 协助起草，项目负责人复核。
2025-03-11，OpenAI 在发布构建 Agent 的新工具时开源了 Agents SDK。它延续了较轻量的编排思路，把 Agent、工具、交接、Guardrails 和 Tracing 放到一个可组合的运行模型里。
复杂 Agent 的问题通常不在最终一句回答，而在中间选了什么工具、传了什么参数、在哪一步失败。Tracing 让团队有机会把这些步骤转成调试和评测证据。
不同 Agent 可以各自承担窄职责，再通过 handoff 转移任务。它比让一个万能 Agent 拥有所有工具更容易限制上下文和权限，但交接本身仍需测试，不能把责任一起丢掉。
输入输出检查可以降低明显错误，却不能替代后端认证、对象所有权、幂等和人工确认。真正的工具权限仍应由业务系统决定。
如果任务只是一次模型调用加一个只读查询，普通函数和清晰日志可能已经足够。框架的价值要由真实工作流、可观测性和维护成本证明，而不是由示例代码长度证明。
一手来源：
编辑说明：本文按 2025-03-11 的发布背景解读，并于 2026-08-15 核对官方来源。AI 协助起草，项目负责人复核。
2024-11-25，Anthropic 公布 Model Context Protocol（MCP），把它定义为连接 AI 助手与数据源、工具和开发环境的开放标准。它试图减少一种长期重复工作：每个模型应用都为每个外部系统单独写一套连接器。
这使“支持某个数据源”更可能成为可复用的服务能力，而不是只存在于一个 Agent 框架里的私有适配器。
MCP 不会替你完成身份认证、对象所有权、租户隔离、高风险确认、幂等、审计和密钥管理。一个 MCP 工具即使协议完全正确，也可能拥有过宽权限，或被提示注入诱导执行错误动作。
COHAO 未来可以把“检查来源”“读取公开主题”“生成待审核草稿”等能力做成窄工具，并通过标准协议接入不同 Agent。但协议层之上仍要由后端确定身份、权限和操作范围；管理员、资金和角色修改不会因为使用 MCP 就变安全。
一手来源：
编辑说明：本文解读截至 2026-08-15，重点是协议边界，不代表对所有 MCP 实现的安全背书。AI 协助起草，项目负责人核验来源。
COHAO 原本已经有一个自研的创世申请工作台，但它不具备完整内容社区所需的账号、主题、回复、搜索、通知、举报和审核体验。继续从零开发，会把时间花在重复建设基础能力，而不是内容与关系。
因此我们选择 NodeBB 作为当前社区底座，并保留旧工作台、SQLite 数据、备份和发布目录作为回滚与运营资料。
v4.14.10，核验日期 2026-08-15。选择成熟引擎不是把社区交给软件决定。栏目、文化、内容质量、权限和收入分配仍然由 COHAO 的公开制度负责。
参考：
编辑说明：2026-08-15，本文记录 COHAO 的真实技术选择；AI 协助起草，项目负责人复核。
RAG 项目常常一开始就选择向量数据库，但很多知识库问题其实来自分段、权限、版本和答案评测，而不是缺少一种更强的检索算法。
适合错误码、型号、文件名、专有名词和精确短语。优点是可解释、成本低；缺点是对同义表达和自然语言问题不够敏感。
适合语义相近但用词不同的内容。优点是召回更灵活；缺点是可能召回“主题相近但答案不对”的片段，也需要嵌入版本、索引和阈值管理。
把关键词与向量结果合并，再用规则或重排模型排序。通常更稳，但系统复杂度、延迟和调试成本更高。
从关键词检索加少量语义召回开始；只有真实问题集证明召回不足时，再增加复杂重排。任何检索都必须在查询前做权限过滤或在可靠的安全边界内过滤，不能先把不该看的内容交给模型再要求它忘记。
编辑说明：2026-08-15，COHAO 编辑部依据 RAG 工程通用实践整理；AI 协助起草，项目负责人复核。
本地模型和托管 API 经常被写成价值观选择，实际系统更适合按任务和数据分层。
| 维度 | 本地模型 | 托管 API | 混合架构 |
|---|---|---|---|
| 数据控制 | 可完全留在自有环境 | 取决于服务条款与配置 | 敏感任务本地，其余托管 |
| 前期投入 | 硬件、部署和运维较高 | 接入快，按用量付费 | 需要路由与两套运维 |
| 峰值弹性 | 受本地容量限制 | 通常更容易扩缩 | 可把峰值溢出到托管端 |
| 模型更新 | 自己决定升级节奏 | 能力更新快但可能变化 | 需要持续兼容性评测 |
| 故障类型 | 显存、驱动、量化与容量 | 限流、网络、区域与服务变化 | 路由错误和结果不一致增加 |
同一任务在不同模型间的行为、格式和安全边界可能不一致。路由器需要版本化策略、回归评测、结果标记和失败回退，不能只依据“哪个便宜”随机切换。
结论不是三选一，而是给每类任务找到可解释的执行路径，并保留替换能力。
编辑说明：2026-08-15，本文是架构比较框架，不代表对任何具体服务的价格或能力作实时断言。AI 协助起草，项目负责人复核。
“哪个 Agent 框架最好”通常不是一个能脱离任务回答的问题。先把下面八个问题写清楚，候选范围往往会自动缩小。
评测框架时，用同一组真实任务比较完成率、人工接管、重复执行、调试时间和迁移难度。演示代码短不等于生产总成本低。
编辑说明：2026-08-15，本文提供中立选型维度，不构成对某个具体框架的当前排名。AI 协助起草，项目负责人复核。
空社区最让人焦虑，于是很容易想到一个办法：让 AI 一次生成几百篇帖子，再让多个账号互相回复，先把页面填满。
这会同时制造三个假象：好像已经有人使用，好像内容经过讨论，好像社区已经形成共识。新用户一旦发现这些互动不是人发生的，信任损失比看到一个安静的新社区更难修复。
社区可以从内容开始，但内容必须给真人留下位置，而不是提前替真人把所有话都说完。
编辑说明：2026-08-15，本文说明 COHAO 的冷启动选择，不声称存在已经发生的批量造假事件。AI 协助起草，项目负责人复核。
密钥一旦进入对话、终端回显、日志、截图或错误上报，之后把那一行删除并不等于风险消失。它可能已经被同步到备份、日志平台、浏览器历史、剪贴板、会话记录或第三方监控。
使用受限环境文件、密钥管理服务、标准输入或短期凭据；日志默认脱敏；Agent 工具只接收业务参数，不接收原始密钥。生产凭据不进入仓库、文档和聊天。
编辑说明：2026-08-15，COHAO 编辑部根据生产运维通用原则整理；AI 协助起草，项目负责人复核。
把后台管理员账号直接交给 Agent，看起来可以少写很多工具接口：模型想查什么就查，想改什么就改。但一旦出现误删、越权或提示注入，系统很难回答三个基本问题：谁授权的、允许到哪里、怎样撤销。
为每类允许动作建立专门工具，例如“读取本人订单状态”“为本人草稿生成摘要”“提交待审核的退款申请”。后端从认证会话派生用户与站点，检查对象所有权，限制字段，记录确认和幂等键。
模型不应该拥有数据库、管理员面板、角色修改、钱包或密钥管理入口。即使未来 Agent 更聪明，这些边界也不会过时，因为它们解决的是责任与权限问题，不是语言理解问题。
编辑说明：2026-08-15，本文是上线前威胁建模，不声称 COHAO 已发生该事故。AI 协助起草，项目负责人复核。
下面不是虚构事故，而是一种需要在上线前主动防住的常见失败模式。
假设 Agent 调用“发布文章”工具，外部服务已经收到请求并成功创建文章，但响应在返回途中超时。Agent 只看到超时，于是再次调用，最终产生两篇完全相同的文章。
pending 状态，再发送外部请求。unknown，随后用查询接口或外部请求标识核验。测试时故意在“外部已成功、响应未返回”的位置断网，验证系统只产生一个对象，并且最终能从 unknown 收敛到 succeeded 或人工处理。
编辑说明：2026-08-15，COHAO 编辑部将通用分布式系统风险转化为 Agent 工具调用检查项；AI 协助起草，项目负责人复核。
这是一条真实的项目复盘。我们在为 COHAO 创世方案补研究依据时，曾经根据搜索结果摘要组装论文引用。摘要看起来支持结论，但进一步核对后发现，部分论文编号、标题和主张范围并不对应。
搜索结果只能用来发现候选来源，不能单独作为研究结论的证据。一个引用如果无法回答“原文到底说了什么、适用于什么范围”，宁可暂时不写。
这次修正后的研究稿重新核验了论文标题、作者、摘要与主张范围，也让我们把“来源核验”列为编辑部 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，不要把“未知”伪装成失败。模型可以得到经过裁剪的状态，例如“请求已经提交，结果未知，请等待查询”，而不是数据库连接和任意重试工具。是否允许重试由后端状态机判断。
出现以下任一情况就转人工：外部结果未知、高价值或不可逆动作、幂等状态冲突、对象版本已经变化、确认已过期。
可靠性不是“多重试几次”，而是知道每一次执行是否发生、现在处于什么状态、下一步由谁负责。
编辑说明：2026-08-15，COHAO 编辑部根据外部工具调用与支付类系统的通用工程模式整理；AI 协助起草，项目负责人复核。