1. 这不是写个API调用那么简单为什么给知乎看山智能体加一个“提建议”的MCP Tool本质上是在重构用户反馈链路“给知乎看山智能体一个提交用户改进建议的MCP Tool”——这个标题乍看像一句技术需求描述但如果你在AI工程一线干过三年以上第一反应不会是“写个HTTP POST”而是立刻意识到这是一次对产品闭环能力的底层加固。我去年在某知识社区做智能体平台架构时就卡在这个环节上整整两个月。当时团队以为只要把“用户说‘这个回答太啰嗦’→智能体识别意图→调用后端接口”跑通就行结果上线后发现92%的用户反馈根本没被真正消化。不是模型没识别也不是接口没调通而是整个反馈路径缺乏结构化锚点用户一句话里混着吐槽、功能请求、错别字举报、内容质疑后端收到的是一团JSON blob运营同学得人工拆解、打标、分派平均响应周期超过72小时。而MCPModel Control Protocol协议的核心价值恰恰就在这里——它不只定义“怎么传数据”更强制约定“数据长什么样、谁负责哪一段、失败了怎么回滚”。所以这个Tool的本质不是给智能体加个按钮而是把散落在对话流里的用户声音变成可索引、可追踪、可归因、可度量的产品信号源。关键词里反复出现的“知乎看山”指向的是其内部已落地的智能体基础设施而“MCP”和“tool”并列出现说明社区开发者已经意识到单纯依赖LLM输出自由文本无法支撑严肃产品迭代。你不需要懂看山的私有API但必须理解MCP的三个刚性约束一是Payload Schema必须预注册不能靠模型自由发挥二是Action ID需全局唯一且带语义比如zhihu.kanshan.suggestion.v1.submit而非api/v1/feedback三是必须声明Side Effect范围这个Tool是否修改用户状态是否触发通知是否生成工单。这些不是开发规范而是产品契约。如果你正打算在Coze或Dify上复现类似功能跳过这一步后面所有自动化流程都会在灰度期崩塌。2. MCP Tool设计核心从“能用”到“可靠”的四层穿透式拆解2.1 协议层为什么必须用MCP而不是通用HTTP工具MCP协议不是又一个RESTful规范它的设计哲学根植于智能体协作的现实困境。我拿自己踩过的坑来说明早期我们用标准HTTP POST向内部反馈系统发数据字段全靠文档约定结果模型把“希望增加夜间模式”识别成{type: feature_request, target: theme, value: dark}而运营系统期待的是{category: ui, sub_category: theme, detail: {mode: night}}。两边都没错但数据在管道里就失效了。MCP通过三重机制解决这个问题第一Schema Registry强制校验。每个Tool在注册时必须提交OpenAPI 3.0格式的JSON Schema比如zhihu.kanshan.suggestion.v1.submit的输入Schema必须包含contentstring, required、suggestion_typeenum: [bug_report, feature_request, content_improvement, usability_issue]、reference_urlstring, format: uri, nullable等字段。服务端收到请求后先用该Schema做JSON Schema Validation不通过直接400返回附带具体错误路径如$.suggestion_type: value not in enum。这比前端表单校验更彻底——它堵死了模型幻觉生成非法字段的可能。第二Action ID语义化编码。MCP要求ID采用domain.service.resource.version.action格式比如zhihu.kanshan.suggestion.v1.submit。这个ID不是随便起的它直接映射到权限系统运维可以按zhihu.kanshan.*批量授权审计系统能按*.suggestion.*聚合统计甚至CI/CD流水线能根据v1自动触发对应版本的契约测试。我们曾因ID写成submit_suggestion_v1导致权限策略失效凌晨三点被告警叫醒排查。第三Side Effect声明不可省略。MCP要求每个Tool明确声明side_effects字段取值为[none, state_change, notification, external_call]的组合。比如这个提建议Tool必须声明[state_change, notification]因为提交后会创建工单状态变更并对应产品经理通知。这个声明不是摆设——智能体编排引擎会据此决定是否启用事务回滚如果notification发送失败整个操作必须原子性回退否则会出现“工单建了但没人知道”的诡异状态。而普通HTTP工具根本没有这个概念。提示不要试图绕过MCP Schema校验。有团队试过用LLM后处理把自由文本转成合规JSON结果模型把“字体太小”硬凑成{suggestion_type: usability_issue, detail: {element: font_size, current_value: 12px, expected_value: 14px}}但Schema里detail字段实际定义为string类型。校验失败后整个智能体流程卡死用户看到“系统繁忙”。正确做法是让模型只输出原始文本由Tool内部的轻量级规则引擎如正则关键词匹配做结构化提取再走Schema校验。2.2 工具层一个真正可用的MCP Tool长什么样子很多人以为MCP Tool就是个带特定Header的HTTP客户端这是巨大误解。一个生产级Tool必须包含五个不可分割的组件缺一不可1. 输入预处理器Input Normalizer作用把LLM输出的非结构化文本转换成符合Schema的中间表示。我们不用大模型做这步而是用确定性规则。例如检测到“bug”、“错别字”、“显示异常”等词 →suggestion_type bug_report检测到“增加”、“支持”、“能不能”等词 →suggestion_type feature_request提取URL用https?://[^\s]正则捕获过滤掉短链接如t.cn保留原始长链接截断超长文本content字段限制500字符超出部分用...后续内容已截断标记并记录原始长度供后台分析2. Schema校验器Validator作用执行JSON Schema Validation。我们用jsonschema库Python或ajvJS但关键在于错误处理——不能简单抛异常。必须把校验失败信息转成用户可读提示比如{error: suggestion_type必须是以下之一bug_report, feature_request, content_improvement, usability_issue, field: suggestion_type, suggested_values: [bug_report]}。这个提示会原样返回给智能体让它重新生成。3. 业务逻辑执行器Executor作用调用真实后端API。这里的关键是幂等性设计。我们给每次请求生成idempotency_key sha256(user_id timestamp content[:100])作为HTTP HeaderX-Idempotency-Key发送。后端收到后先查Redis缓存若存在相同key的响应则直接返回缓存结果避免重复创建工单。实测下来用户连续点击两次“提交建议”只会生成一个工单。4. 响应后处理器Response Enricher作用把后端原始响应包装成MCP标准格式。MCP要求响应必须包含tool_use_id对应请求中的ID、result成功时的结构化数据、error失败时的标准化错误码。我们额外注入tracking_id关联工单号、estimated_resolution_time基于历史数据预测的处理时长如“预计2个工作日内回复”这些字段虽非MCP强制但极大提升用户体验。5. 监控埋点器Telemetry Injector作用在关键节点打点。不只是记录“成功/失败”更要捕获preprocess_duration_ms预处理耗时判断规则引擎是否过载validation_errors校验失败的具体字段和原因发现模型常把“夜间模式”错标为content_improvementidempotency_hit_rate幂等性缓存命中率低于80%说明用户重复提交严重backend_latency_p95_ms后端响应P95延迟超过1s需告警这五个组件必须打包成一个独立服务我们用FastAPI不能分散在智能体代码里。否则当看山平台升级MCP版本时你得改几十个智能体的代码而集中式Tool只需升级自身所有调用方自动受益。2.3 看山平台适配如何让Tool真正融入知乎的智能体生态知乎看山不是黑盒它的智能体调度器Orchestrator有明确的Tool注册机制。要让我们的Tool被识别必须完成三步第一步注册Tool元数据向看山管理后台提交JSON配置关键字段包括{ tool_id: zhihu.kanshan.suggestion.v1.submit, name: 提交用户改进建议, description: 将用户对内容、功能或体验的改进建议结构化提交至产品团队, input_schema: { $ref: https://kanshan.zhihu.com/schema/suggestion-v1.json }, output_schema: { $ref: https://kanshan.zhihu.com/schema/suggestion-response-v1.json }, endpoint: https://mcp-suggestion-prod.zhihu.com/submit, authentication: { type: bearer_token, scope: kanshan.suggestion.write } }注意input_schema和output_schema必须是公开可访问的HTTPS URL且内容需通过看山的Schema校验服务。我们曾因schema文件里用了$id相对引用导致注册失败改成绝对URL才解决。第二步配置权限策略在看山RBAC系统中为该Tool分配最小权限kanshan.suggestion.write仅允许写入建议不能读取历史工单kanshan.user.read仅允许读取当前用户基础信息用于生成user_id明确拒绝kanshan.admin.*等高危权限第三步接入智能体工作流在看山的可视化编排界面中把Tool拖入流程图关键配置触发条件设置为intent submit_suggestion而非模糊的关键词匹配。这意味着智能体必须先调用意图识别Tool确认用户真实意图是“提建议”才能进入此步骤。失败重试配置为max_retries1, backoff_seconds2。重试不是为了扛住网络抖动而是给模型第二次机会——第一次可能因上下文不足识别错误重试时带上更完整的对话历史。超时控制设为timeout_seconds8。看山规定Tool响应必须≤10秒我们留2秒缓冲。实测8秒内完成率99.97%超时基本发生在网络分区时此时看山会自动降级为“建议已收到稍后处理”的友好提示。注意不要在Tool里做用户身份二次校验。看山在调用前已通过JWT验证用户身份并在请求Header中透传X-Zhihu-User-ID。你在Tool里再查一遍数据库只会增加延迟和失败点。信任平台专注做好本职——结构化提交。3. 实操全流程从零部署一个可上线的MCP Suggestion Tool3.1 环境准备与依赖安装我们选择Python 3.10作为运行时核心依赖只有四个全部来自PyPI官方源无任何第三方镜像风险fastapi0.115.0提供高性能Web框架自带OpenAPI文档uvicorn0.32.0ASGI服务器支持热重载jsonschema4.23.0权威JSON Schema校验库redis5.0.1用于幂等性缓存可选但强烈推荐安装命令一行搞定pip install fastapi uvicorn jsonschema redis为什么不用Flask因为FastAPI的Pydantic模型天然支持Schema校验且异步IO性能更适合MCP这种高并发低延迟场景。我们压测过同等硬件下FastAPI处理1000QPS时平均延迟32msFlask为87ms。差出来的55ms在智能体对话中就是用户感知的“卡顿”。项目结构严格遵循生产规范mcp-suggestion-tool/ ├── main.py # FastAPI应用入口 ├── schemas/ # Schema定义目录 │ ├── input.json # 输入Schema符合MCP要求 │ └── output.json # 输出Schema ├── processors/ # 业务逻辑模块 │ ├── normalizer.py # 输入预处理器 │ ├── validator.py # Schema校验器 │ └── executor.py # 业务执行器 ├── utils/ # 工具函数 │ └── telemetry.py # 监控埋点 └── tests/ # 单元测试必须覆盖所有分支 └── test_normalizer.py提示schemas/input.json必须严格遵循MCP v1.2规范。我们从看山文档下载了官方Schema模板只修改了properties部分其他如$schema、$id等元字段保持原样。任何改动都可能导致注册失败。3.2 核心代码实现聚焦可复用的模式输入预处理器processors/normalizer.pyimport re from typing import Dict, Any def normalize_input(raw_text: str, user_id: str, reference_url: str None) - Dict[str, Any]: 将LLM输出的原始文本转换为符合MCP Schema的结构化数据 规则优先级关键词匹配 正则提取 默认兜底 # 初始化默认值 result { content: raw_text[:500], # 强制截断 suggestion_type: usability_issue, reference_url: reference_url } # 步骤1关键词分类 bug_keywords [bug, 错别字, 显示异常, 崩溃, 闪退, 加载失败] feature_keywords [增加, 支持, 能不能, 希望有, 建议添加] text_lower raw_text.lower() if any(kw in text_lower for kw in bug_keywords): result[suggestion_type] bug_report elif any(kw in text_lower for kw in feature_keywords): result[suggestion_type] feature_request # 其他类型暂不细分由后续人工标注 # 步骤2URL提取增强版 if not reference_url: urls re.findall(rhttps?://[^\s], raw_text) # 过滤短链接保留第一个有效长链接 for url in urls: if len(url) 20 and not re.match(rhttps?://t\.cn/, url): result[reference_url] url break # 步骤3内容清洗 result[content] re.sub(r\s, , result[content]).strip() if len(result[content]) 500: result[content] result[content][:497] ... return result这个函数的设计哲学是“确定性优先”。不用LLM因为规则足够覆盖95%场景不追求100%准确因为MCP的Schema校验会兜底重点是快——实测平均耗时1.2ms比调用一次小型LLM快200倍。Schema校验器processors/validator.pyimport json from jsonschema import validate, ValidationError from jsonschema.validators import Draft202012Validator from pathlib import Path # 预加载Schema避免每次请求都读文件 INPUT_SCHEMA json.loads(Path(schemas/input.json).read_text()) def validate_input(data: dict) - tuple[bool, str]: 执行JSON Schema校验返回(是否通过, 错误信息) 错误信息格式化为用户可读文本 try: validate(instancedata, schemaINPUT_SCHEMA, clsDraft202012Validator) return True, except ValidationError as e: # 提取最顶层的错误路径和消息 error_path ..join(str(p) for p in e.absolute_path) or root # 构造友好提示 if suggestion_type in error_path and enum in str(e): return False, fsuggestion_type必须是以下之一bug_report, feature_request, content_improvement, usability_issue elif content in error_path and maxLength in str(e): return False, 建议内容不能超过500个字符 else: return False, f{error_path}字段不符合要求{e.message}关键点在于错误信息的翻译。原始ValidationError的e.message是技术语言如night_mode is not one of [bug_report, feature_request]我们把它转成用户能懂的话。这个转换逻辑必须维护否则智能体会把原始错误丢给用户体验极差。业务执行器processors/executor.pyimport hashlib import time import requests from redis import Redis from typing import Dict, Any # Redis连接生产环境用连接池 redis_client Redis(hostlocalhost, port6379, db0, decode_responsesTrue) def execute_suggestion(data: dict, user_id: str) - Dict[str, Any]: 调用后端API提交建议确保幂等性 # 步骤1生成幂等性Key idempotency_key hashlib.sha256( f{user_id}_{int(time.time())}_{data[content][:100]}.encode() ).hexdigest() # 步骤2检查缓存 cache_key fidempotency:{idempotency_key} cached_result redis_client.get(cache_key) if cached_result: return json.loads(cached_result) # 步骤3构造请求 payload { user_id: user_id, content: data[content], suggestion_type: data[suggestion_type], reference_url: data.get(reference_url), source: kanshan_mcp_tool } # 步骤4调用后端带超时和重试 try: response requests.post( https://api.zhihu.com/kanshan/suggestions, jsonpayload, headers{ Authorization: Bearer YOUR_BACKEND_TOKEN, X-Idempotency-Key: idempotency_key }, timeout(3, 8) # connect3s, read8s ) response.raise_for_status() # 步骤5缓存成功响应 backend_result response.json() redis_client.setex(cache_key, 3600, json.dumps(backend_result)) # 缓存1小时 return { tool_use_id: temp_id, # 实际由看山注入 result: { tracking_id: backend_result.get(ticket_id, UNK), estimated_resolution_time: 2个工作日 } } except requests.exceptions.Timeout: return {error: 后端服务暂时不可用请稍后再试} except requests.exceptions.RequestException as e: return {error: f提交失败{str(e)}}这里展示了生产级容错连接超时3秒防网络抖动读取超时8秒防后端慢SQL缓存1小时平衡一致性与性能。X-Idempotency-Key是后端识别幂等性的关键必须和缓存Key一致。3.3 FastAPI主应用main.pyfrom fastapi import FastAPI, HTTPException, Request, status from pydantic import BaseModel from typing import Dict, Any import json import time from processors.normalizer import normalize_input from processors.validator import validate_input from processors.executor import execute_suggestion from utils.telemetry import log_telemetry app FastAPI( titleZhihu Kanshan Suggestion MCP Tool, description为知乎看山智能体提供结构化建议提交能力, version1.0.0 ) class SuggestionRequest(BaseModel): MCP要求的输入结构字段名必须与Schema完全一致 content: str suggestion_type: str reference_url: str None app.post(/submit, response_modelDict[str, Any]) async def submit_suggestion(request: Request, payload: SuggestionRequest): start_time time.time() # 1. 提取用户ID从看山透传的Header user_id request.headers.get(X-Zhihu-User-ID) if not user_id: raise HTTPException(status_codestatus.HTTP_400_BAD_REQUEST, detail缺少用户标识) # 2. 输入预处理 normalized normalize_input(payload.content, user_id, payload.reference_url) # 3. Schema校验 is_valid, error_msg validate_input(normalized) if not is_valid: log_telemetry(validation_failed, {error: error_msg, user_id: user_id}) raise HTTPException(status_codestatus.HTTP_400_BAD_REQUEST, detailerror_msg) # 4. 执行业务逻辑 try: result execute_suggestion(normalized, user_id) except Exception as e: log_telemetry(execution_failed, {error: str(e), user_id: user_id}) raise HTTPException(status_codestatus.HTTP_500_INTERNAL_SERVER_ERROR, detail系统内部错误) # 5. 记录成功指标 duration time.time() - start_time log_telemetry(success, { duration_ms: int(duration * 1000), suggestion_type: normalized[suggestion_type], user_id: user_id }) return result if __name__ __main__: import uvicorn uvicorn.run(main:app, host0.0.0.0, port8000, reloadTrue)这个主应用体现了MCP Tool的精髓极简接口只有一个/submit端点严格依赖看山注入的HeaderX-Zhihu-User-ID所有错误都转化为标准HTTP状态码。reloadTrue仅用于开发生产环境必须关闭。3.4 本地测试与上线验证测试不是可选项而是上线前的生死线。我们用pytest写三类测试单元测试test_normalizer.py验证预处理器对各种输入的鲁棒性def test_normalize_bug_report(): result normalize_input(文章里有个错别字‘的’写成了‘地’, u123) assert result[suggestion_type] bug_report assert len(result[content]) 500 def test_normalize_long_text(): long_text a * 600 result normalize_input(long_text, u123) assert result[content].endswith(...) assert len(result[content]) 500集成测试test_end_to_end.py启动本地FastAPI模拟看山调用def test_full_flow(): client TestClient(app) response client.post(/submit, json{ content: 希望增加夜间模式, suggestion_type: feature_request }, headers{X-Zhihu-User-ID: u123}) assert response.status_code 200 data response.json() assert result in data assert tracking_id in data[result]混沌测试chaos_test.py故意制造故障验证容错def test_redis_down(): # 临时停用Redis验证降级逻辑 with patch(processors.executor.redis_client) as mock_redis: mock_redis.get.return_value None mock_redis.setex.side_effect ConnectionError(Redis down) result execute_suggestion({content: test}, u123) assert error in result # 应该返回错误而非崩溃上线前必须完成在看山沙箱环境注册Tool获取tool_id用真实用户Token调用一次确认JWT解析正常模拟100QPS压力测试监控CPU、内存、Redis连接数检查看山后台的Tool调用日志确认tool_use_id被正确记录我们曾因忘记在沙箱环境配置X-Zhihu-User-IDHeader导致上线后所有请求400紧急回滚。教训是沙箱测试必须100%模拟生产Header。4. 真实问题排查手册我在知乎看山项目中踩过的7个深坑4.1 问题1MCP注册成功但智能体调用时返回404现象Tool在看山管理后台显示“已激活”但智能体流程走到这一步就报HTTP 404 Not Found。排查路径检查FastAPI日志tail -f logs/uwsgi.log | grep 404发现请求路径是/v1/submit而非/submit查看看山文档MCP Tool注册时endpoint字段必须是完整URL且路径要与代码中app.post(/submit)完全一致。我们注册时填了https://mcp-suggestion-prod.zhihu.com漏掉了/submit后缀修复在管理后台更新endpoint为https://mcp-suggestion-prod.zhihu.com/submit实操心得看山的Endpoint校验是字符串精确匹配不支持路径前缀匹配。注册前务必用curl手动测试curl -X POST https://your-endpoint.com/submit -H X-Zhihu-User-ID: test -d {}4.2 问题2用户提交后后台收到重复工单现象同一用户连续点击两次“提交”后端创建了两个相同工单。根因分析检查幂等性Key生成逻辑发现用了time.time()两次请求时间戳不同Key就不同查看Redis缓存redis-cli keys idempotency:*发现大量不同Key审计后端日志确认X-Idempotency-KeyHeader确实不同解决方案改用确定性Keysha256(user_id content[:100] suggestion_v1)增加缓存TTL从1小时改为24小时覆盖用户可能的重复操作窗口注意不要用user_id timestamp因为timestamp是变化的。幂等性Key必须只依赖不变量user_id、content、版本号。4.3 问题3Schema校验通过但后端API返回422 Unprocessable Entity现象Tool返回200但result为空后端日志显示Validation failed: reference_url is not a valid URI深度排查抓包看Tool发出的请求发现reference_url字段值为https://zhuanlan.zhihu.com/p/123456?utm_sourcecopy带查询参数检查后端Schema要求format: uri但某些URI校验库对带?的URL判定为无效对比MCP官方测试用例发现他们用的uri格式定义宽松允许查询参数修复在预处理器中清理URLurl.split(?)[0]只保留基础路径或联系后端团队放宽uri校验规则推荐前者避免跨团队协调4.4 问题4智能体流程卡在Tool节点无任何日志现象看山后台显示“正在执行Tool”但Tool服务器无任何访问日志CPU/内存正常。终极定位检查看山网络策略发现生产环境只允许访问*.zhihu.com域名而我们的Tool域名是mcp-suggestion-prod.example.comDNS解析nslookup mcp-suggestion-prod.example.com返回空证实域名未加入白名单解决向看山运维申请域名白名单或迁移至mcp-suggestion-prod.zhihu.com子域名需DNS配置提示看山的网络隔离非常严格。上线前必须确认Tool域名在zhihu.com域下或已加入白名单。这是最容易被忽略的基建问题。4.5 问题5用户反馈“提交成功”但运营后台看不到新工单现象Tool返回{result: {tracking_id: TKT-12345}}但运营系统无此工单。链路追踪查看Tool日志确认execute_suggestion函数执行成功返回了tracking_id检查后端API响应发现返回{ticket_id: TKT-12345, status: queued}但运营系统只拉取status: created的数据对接运营团队确认他们的ETL任务每5分钟同步一次且过滤条件为status IN (created, assigned)根本原因后端状态机设计与运营系统期望不一致。queued状态不被采集。修复修改后端逻辑创建工单时直接设为created状态或修改ETL脚本增加queued状态支持需评估影响4.6 问题6MCP Tool在看山沙箱能用生产环境报401 Unauthorized现象沙箱一切正常生产环境调用返回401Header中Authorization字段存在。关键发现沙箱Token有效期30天生产Token有效期7天且生产Token已过期看山Token刷新机制需要定期调用/auth/refresh接口但我们没实现解决方案在Tool启动时用Refresh Token换取新Access Token设置定时任务每6小时刷新一次预留1小时缓冲增加Token失效的重试逻辑当401时自动刷新Token并重试请求4.7 问题7用户提交含中文标点的建议后端存储乱码现象content字段存入数据库后。变成，。Ａ？。溯源检查FastAPI请求解析默认使用utf-8没问题检查requests.post编码jsonpayload自动序列化为UTF-8检查后端数据库MySQL表字符集为latin1非utf8mb4修复后端DBA执行ALTER TABLE suggestions CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci在Tool中增加编码检测if not payload[content].isprintable(): ...提前预警实操心得中文乱码问题90%出在数据库层而非应用层。上线前必须确认所有链路应用→网络→数据库的字符集统一为utf8mb4。5. 效果验证与持续优化如何证明这个Tool真的有价值5.1 量化指标设计不止看成功率更要看产品影响力上线后我们盯住五个核心指标它们共同构成Tool健康度仪表盘指标名称计算公式健康阈值业务意义端到端成功率成功响应数 / 总调用数≥99.5%反映系统稳定性低于99%需立即告警平均处理时长Σ(响应时间) / 成功请求数≤1200ms用户感知流畅度超过2s用户会放弃建议采纳率被产品团队采纳的建议数 / 总提交数≥15%衡量建议质量低于10%说明预处理规则需优化工单闭环率已解决工单数 / 创建工单总数≥85%反映后端流程效率低说明运营人力不足用户复访率7日内再次提交建议的用户数 / 首次提交用户数≥25%衡量用户信任度高说明体验好这些指标不是摆设。我们每天晨会看仪表盘当“建议采纳率”连续3天低于12%时立刻启动根因分析发现模型常把“这个回答太啰嗦”识别为content_improvement但运营团队更关注usability_issue。于是调整预处理器规则增加usability_issue的触发权重一周后采纳率回升至18%。5.2 用户反馈闭环让Tool自己进化我们没把Tool当成一次性项目而是设计了自学习机制Step1收集失败案例当Schema校验失败时不只返回错误还把原始输入、错误原因、时间戳写入failed_suggestions表CREATE TABLE failed_suggestions ( id BIGINT PRIMARY KEY AUTO_INCREMENT, raw_content TEXT NOT NULL, error_reason VARCHAR(255) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, resolved BOOLEAN DEFAULT FALSE );Step2人工标注队列运营同学每天查看failed_suggestions对raw_content