왜 버클 플러그인이 객체 파라미터를 전달하지 못하나요? 이 문제는 '인터페이스 수신되지 않음'과 비슷하지만, 공개 이슈에서 더 흔한 진실은 Coze(버튼)가 플러그인에 넘긴 레이어가 객체 매개변수를 드랍하거나 평평하게 만들었다는 점입니다. 그렇긴 해도, 플러그인 자체가 반드시 문제인 것은 아니지만, 문제는 워크플로우 입력, 노드 매핑, 또는 매개변수 구조의 표현식에 있을 수 있습니다.
일반적인 공개 사례는 플러그인이 'model_name' 요청 본문만 받고, 워크플로우에 명확히 'extra_params'가 있는 경우입니다. 이는 객체 매개변수가 링크의 특정 구간에서 잘려 나오는데, 이는 백엔드가 연결되어 있지 않아서가 아니라 프론트엔드가 전달되지 않기 때문입니다.
왜 객체 파라미터가 가장 쉽게 잃어버리는지
객체 매개변수는 문자열이나 숫자 같은 단순 타입보다 워크플로우에 문제를 일으킬 가능성이 더 높습니다. 왜냐하면 객체는 중첩된 구조에 의존하기 때문입니다. 객체를 문자열로 바꾸거나 서브필드를 분할하면, 플러그인 노드는 예상과 다른 콘텐츠를 받게 됩니다. 많은 사람들이 자신들이 '매핑'했다고 생각하지만, 실제로는 외부 필드만 매핑하고 있고, 그 안의 하위 속성들은 전혀 전달되지 않았습니다.
먼저 이 장소들을 살펴보겠습니다
- 워크플로우 시작 노드가 객체를 출력하는 건가요, 아니면 이미 문자열로 된 JSON 파일을 출력하나요?
- 플러그인 입력 매개변수가 단순히 평면 필드를 작성하는 대신 객체 타입을 명시적으로 선언하는지 여부도 중요합니다.
- 플러그인 실행 로그에서 실제로 보내진 몸체는 어떻게 보이나요?
공동체 내에서 보다 안정적인 접근 방식
객체 구조가 복잡하다면, 먼저 평탄화하고 여러 개의 명확한 필드로 나누고, 정상적으로 통과할 수 있는지 확인한 후 중첩된 객체를 복원하는 것을 고려하세요. 많은 경우, 링크를 먼저 실행하게 하는 것이 원래 객체 구조를 유지하려 애쓰는 것보다 시간을 절약합니다. 객체를 유지해야 한다면, 워크플로우 캔버스의 필드 이름뿐만 아니라 최종 요청 본문을 꼭 확인하세요.
즉, 플러그인이 객체 매개변수를 전달하지 못하면 플러그인이 이를 받아들이지 않을 가능성이 높고, 워크플로우가 원하는 방식으로 전송하지 않을 가능성이 큽니다.
한 문장 결론
버클 플러그인은 객체 매개변수를 전달할 수 없으며, 보통 먼저 워크플로우 입력 매핑을 확인한 후 매개변수가 문자열 상태인지 평평한지 확인합니다. 객체가 중앙에서 변형되면, 플러그인 쪽은 불완전한 데이터만 보게 됩니다.
