Cozeのワークフローでは、「無効な文字」が報告された場合<' looking for beginning of value`，很多人第一反应是模型坏了，其实大概率不是。公开 issue 里，这种错误通常意味着接口本来应该返回 JSON，结果却返回了一个网页，比如 404 页面、登录页，或者反向代理吐出来的 HTML。换句话说，程序在等数据，却收到了网页。
公式のオープンソース版を見ているなら、リポジトリアドレス はまだcoze-dev/coze-studioです。 公式のREADMEおよび開発ノートでは、モデル構成、APIエントリ、ワークフロー実行環境をまず整合させる必要があると強調されており、そうでなければ実行時に爆発的に拡大する可能性が高いとされています。
なぜこの誤りは「モデル問題」と非常に似ているのか
なぜなら、ワークフローノードが動作しているときに、そのノードがモデルや外部インターフェースを呼び出しているときによく発生するからです。 しかし、本当の誤りキーワードは「」です。<`'，这说明返回内容开头是 HTML 标签而不是 JSON。也就是说，你要查的不是“模型会不会说话”，而是“接口到底回了什么”。
最も一般的な理由
- ベースURLが不一致で、インターフェースがAPIではなくウェブページに届いています。
- パスに「/v1」や追加のプロキシ層が欠けているため、リクエストが誤ったアドレスに転送されてしまいます。
- ゲートウェイやNginxはエラーページを返しますが、フロントエンドはそれをインターフェース応答として解析します。
コミュニティでよく使われている調査方法
最も効果的な方法は、推測するのではなく、実際の反応を直接見ることです。 「curl」やブラウザのウェブパネルを使って、インターフェースがJSONを返すかどうかを確認できます。 最初からHTMLだった場合、問題は基本的にアドレス、プロキシ、認証のジャンプに固定されています。 オープンの問題では、誰かが似たような状況に直面し、最終的にサードパーティのOpenAPIのリクエストパスが不一致していたか、プロキシ層がウェブページの内容を返してしまったことを発見しました。
ワークフローを段階的に構築する場合は、まず最小限のテストが問題ないことを確認したインターフェースを使い、その後徐々に他のノードを追加していくことが推奨されます。 こうすることで、エラーが報告された時点で、どのレイヤーがJSONをHTMLに変換したかをすぐに知ることができます。
一文の結論
「無効文字」<'` 不是“模型语法错误”，而是接口响应不对。先查地址、代理和返回内容，往往比改工作流节点更快。
