This document is written based on FastGPT v4.17.0.
What Data Looks Like for This Category
Data for this category originates from private vulnerability reports, code repositories, CVE numbering bodies, and official release channels, and is updated per single vulnerability event. Core documents include security advisories, vulnerability reports, fix patches, and CVE application materials. Fields include vulnerability ID, impact scope, fix status, disclosure time, CVE identifier, and other related fields. This data is only accessible to project security response teams, maintainers, and compliant security researchers.
Constraints for Multi-turn Dialogue and Prompts
The data contains sensitive, undisclosed vulnerability details. Multi-turn dialogue must strictly isolate context across different vulnerability events to prevent information leaks. Data for a single vulnerability event follows a fixed update schedule. Use the chatId parameter to bind the dialogue flow for the corresponding event, ensuring context only links to the currently processed vulnerability. Core documents have mandatory fixed field requirements, so prompts must clearly specify the output format. Multi-turn dialogue can gradually guide users to supplement missing information such as vulnerability IDs and impact scopes. Scattered data from code repositories and CVE bodies must be integrated, with information verification and alignment completed during dialogue to ensure generated documents meet compliance standards.
Configuration Settings
| Configuration Item | Recommended Approach | Rationale |
|---|---|---|
chatId | Bind a unique identifier for the current vulnerability event, formatted as CVE ID + project name, assign a unique string per event | Ensure multi-turn dialogue context only associates with the current vulnerability event, avoid cross-event information confusion, and comply with private data isolation requirements |
messages | Limit the context window to the first 10 turns of dialogue + basic data for the current vulnerability, use a value of first 10 entries | Prevent excessive leakage of sensitive vulnerability information, while retaining sufficient dialogue history for context alignment |
variables | Preset 4-6 fixed field variables, including vulnerability ID, impact scope, fix status, and disclosure time | Enforce alignment with the fixed field requirements of business documents, ensuring output conforms to CVE application material formats |
| Maximum context length | 800–1200 tokens, calibrated via actual testing | Balance sensitive data storage and context integrity, adapt to the information volume of a single vulnerability event |
| Prompt triggering rules | Trigger in stages according to the vulnerability handling workflow: first collect vulnerability details, then assess impact, and finally generate documents | Align with standardized workflows for security vulnerability disclosure handling, guide multi-turn dialogue to complete document drafting step-by-step |
| Historical dialogue filtering | Only retain dialogue records under the current chatId | Strictly isolate dialogue data from different vulnerability events, comply with private data management requirements |
Three Common Misconfigurations
- Issue: After calling the API to initiate a dialogue, the
Humanfield is empty in the response record preview. Cause: The user's question content was not correctly passed to themessagesparameter, only the system prompt was passed, resulting in missing user input in the dialogue history. - Issue: After associating dialogue with
chatId, different users cannot view their own vulnerability handling history. Cause: ThechatIdwas not bound to the specific user's vulnerability handling permissions, only bound to the context by event dimension, resulting in failed permission isolation. - Issue: Generated CVE application materials do not meet format requirements, with missing fields or disordered order. Cause: No fixed field template was preset via the
variablesparameter, and multi-turn dialogue did not prompt users to supplement complete fields as required, resulting in non-standard output format.
How to Verify Proper Configuration
- Initiate a test dialogue, check that the
chatIdonly associates with the context of the current vulnerability event, with no historical information from other events. - Review the context configuration of the
messagesparameter, confirm that only dialogue records for the current vulnerability handling are retained, and the quantity matches the preset range. - Generate a test document, check that the output includes all required fields preset via the
variablesparameter, and the format matches business document requirements. - Call the API to retrieve dialogue records, confirm that only dialogue data under the current
chatIdcan be retrieved, with no cross-event or cross-user information.
The values provided here are common starting points, and should be evaluated against the reader's own samples.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-10-19.