What data this category includes
This category's data mainly comes from code repository commit records, coverage and test case execution reports generated by testing frameworks, requirement specification documents, and interface definition files. Data update frequency is daily or per code commit. Associated daily documents include structured test cases, Mock interface descriptions, and defect tracking tickets. Data fields include code changed lines, test case pass rate, coverage percentage, defect severity, and more. Field formats follow the specifications of their respective documents. There is no unified cross-document field standard. This category focuses on logic validation for small code units. It differs from full-link validation scenarios of integration testing.
What constraints do these characteristics impose on tool calling and plugins
Data sources are scattered and update frequency is high. Tool calling must support real-time pulling of the latest code snippets and test results. It must avoid using expired cached data. Associated daily documents have diverse formats. Plugins must adapt to different structures of test cases, defect tickets, and other files. They must accurately extract core review fields. Short update cycles require tool calling to trigger automatically after code commits. No manual startup is needed. The non-standardized nature of data fields requires tool calling parameter configurations to support flexible matching of different project document formats. It must adapt to diverse review needs.
Configuration Settings
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
toolChoice | auto | Adapts to FastGPT v4.17.0 automatic trigger logic. It automatically starts tool calling after code commits, no manual intervention required |
functionCall | ["Validate unit test cases", "Generate coverage reports"] | Matches the core review links of unit and component testing. It accurately calls corresponding tools to complete validation and report generation |
| Tool call trigger timing | Within 10 minutes after code commit | Adapts to the data update rhythm per commit. It ensures review results are synchronized with the latest code |
| Single tool call timeout duration | 300 seconds | Avoids call blocking caused by testing framework execution delays. It aligns with daily review waiting expectations |
| Number of tool return results to display | Top 3 core exceptions | Focuses on core review issues. It avoids excessive information interfering with review efficiency |
Three Common Configuration Mistakes
- Phenomenon: After tool calling returns results, the AI's automatically spliced review content cannot be closed separately. It is forcibly merged with tool results for display. Cause: The return filtering rules for the
toolChoiceparameter are not configured correctly. This causes tool output to be forcibly bound to the AI's native reply. - Phenomenon: The workflow orchestration interface only allows selecting a single model calling tool. It cannot configure multi-step intermediate result processing. Cause: Advanced step-by-step execution configuration for the workflow is not enabled. The output of intermediate steps is hidden by default.
- Phenomenon: Using a custom bound key to call a third-party tool returns an authentication failure. Cause: The access permission scope of the key is not correctly configured on the application configuration page. Or the key format does not meet the tool's verification requirements.
How to Confirm Correct Configuration
- Submit a piece of test code that includes boundary conditions. Trigger tool calling. Check that the returned results only include coverage and test case exception information generated by the testing framework. No extra AI native reply content is present.
- Enter the workflow orchestration page. Confirm that multiple tool calling nodes can be added. The output of intermediate nodes can be set to hide or display.
- After binding a custom key, initiate a tool calling test. Check that the returned results have no authentication failure prompts.
- View the tool calling logs. Confirm that the trigger timing matches the code commit time. The timeout duration matches the preset
300 secondsconfiguration.
The values given are common starting points and should be measured 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.