@autobe/agent 0.30.3 → 0.30.4-dev.20260324

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,52 +1,52 @@
1
- import { IAgenticaHistoryJson } from "@agentica/core";
2
- import { IAutoBeTypeScriptCompileResult } from "@autobe/interface";
3
- import { v7 } from "uuid";
4
-
5
- import { AutoBeSystemPromptConstant } from "../../constants/AutoBeSystemPromptConstant";
6
- import { IAutoBeTestWriteResult } from "./structures/IAutoBeTestWriteResult";
7
-
8
- export const transformTestCorrectHistories = (
9
- // ctx: AutoBeContext<Model>,
10
- written: IAutoBeTestWriteResult,
11
- failure: IAutoBeTypeScriptCompileResult.IFailure,
12
- ): Array<
13
- IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage
14
- > => {
15
- return [
16
- {
17
- id: v7(),
18
- created_at: new Date().toISOString(),
19
- type: "systemMessage",
20
- text: AutoBeSystemPromptConstant.TEST_WRITE,
21
- },
22
- {
23
- id: v7(),
24
- created_at: new Date().toISOString(),
25
- type: "assistantMessage",
26
- text: [
27
- "## Original Code",
28
- "## `AutoBeTest.IFunction` data",
29
- "```json",
30
- JSON.stringify(written.file.function),
31
- "```",
32
- "## Generated TypeScript Code",
33
- "```typescript",
34
- written.file.content,
35
- "```",
36
- "",
37
- "## Compile Errors",
38
- "Fix the compilation error in the provided code.",
39
- "",
40
- "```json",
41
- JSON.stringify(failure.diagnostics),
42
- "```",
43
- ].join("\n"),
44
- },
45
- {
46
- id: v7(),
47
- created_at: new Date().toISOString(),
48
- type: "systemMessage",
49
- text: AutoBeSystemPromptConstant.TEST_CORRECT,
50
- },
51
- ];
52
- };
1
+ import { IAgenticaHistoryJson } from "@agentica/core";
2
+ import { IAutoBeTypeScriptCompileResult } from "@autobe/interface";
3
+ import { v7 } from "uuid";
4
+
5
+ import { AutoBeSystemPromptConstant } from "../../constants/AutoBeSystemPromptConstant";
6
+ import { IAutoBeTestWriteResult } from "./structures/IAutoBeTestWriteResult";
7
+
8
+ export const transformTestCorrectHistories = (
9
+ // ctx: AutoBeContext<Model>,
10
+ written: IAutoBeTestWriteResult,
11
+ failure: IAutoBeTypeScriptCompileResult.IFailure,
12
+ ): Array<
13
+ IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage
14
+ > => {
15
+ return [
16
+ {
17
+ id: v7(),
18
+ created_at: new Date().toISOString(),
19
+ type: "systemMessage",
20
+ text: AutoBeSystemPromptConstant.TEST_WRITE,
21
+ },
22
+ {
23
+ id: v7(),
24
+ created_at: new Date().toISOString(),
25
+ type: "assistantMessage",
26
+ text: [
27
+ "## Original Code",
28
+ "## `AutoBeTest.IFunction` data",
29
+ "```json",
30
+ JSON.stringify(written.file.function),
31
+ "```",
32
+ "## Generated TypeScript Code",
33
+ "```typescript",
34
+ written.file.content,
35
+ "```",
36
+ "",
37
+ "## Compile Errors",
38
+ "Fix the compilation error in the provided code.",
39
+ "",
40
+ "```json",
41
+ JSON.stringify(failure.diagnostics),
42
+ "```",
43
+ ].join("\n"),
44
+ },
45
+ {
46
+ id: v7(),
47
+ created_at: new Date().toISOString(),
48
+ type: "systemMessage",
49
+ text: AutoBeSystemPromptConstant.TEST_CORRECT,
50
+ },
51
+ ];
52
+ };
@@ -1,113 +1,127 @@
1
- import OpenAI from "openai";
2
-
3
- /**
4
- * Interface representing AI vendor configuration for the AutoBeAgent.
5
- *
6
- * Defines the connection parameters and settings required to integrate with AI
7
- * service providers that power the vibe coding pipeline. While utilizing the
8
- * OpenAI SDK as the connection interface, this configuration supports various
9
- * LLM vendors beyond OpenAI through flexible endpoint and authentication
10
- * configuration, enabling integration with Claude, DeepSeek, Meta Llama, and
11
- * other providers that follow OpenAI-compatible API patterns.
12
- *
13
- * The vendor configuration determines the AI capabilities available throughout
14
- * the entire automated development workflow, from requirements analysis and
15
- * database design through API specification, testing, and final implementation.
16
- * Different vendors may offer varying performance characteristics, cost
17
- * structures, and feature support that can be optimized for specific vibe
18
- * coding needs.
19
- *
20
- * Concurrent request management is built-in to prevent API rate limiting and
21
- * optimize resource utilization across multiple development phases and parallel
22
- * operations within the vibe coding pipeline.
23
- *
24
- * @author Samchon
25
- */
26
- export interface IAutoBeVendor {
27
- /**
28
- * OpenAI SDK instance configured for the target AI vendor.
29
- *
30
- * Provides the API connection interface used by the AutoBeAgent to
31
- * communicate with AI services. While this uses the OpenAI SDK, it can be
32
- * configured to connect with various LLM providers by setting the appropriate
33
- * `baseURL` and authentication credentials. The SDK serves as a universal
34
- * connector that abstracts the underlying API communication protocols.
35
- *
36
- * For non-OpenAI vendors, configure the SDK with the vendor's API endpoint
37
- * and authentication requirements to enable seamless integration with the
38
- * vibe coding system.
39
- */
40
- api: OpenAI;
41
-
42
- /**
43
- * Specific model identifier to use for AI operations.
44
- *
45
- * Specifies the exact model name or identifier that should be used for vibe
46
- * coding tasks. Supports both official OpenAI chat models and custom model
47
- * identifiers for third-party hosting services, cloud providers, or
48
- * alternative LLM vendors. The model choice significantly impacts the
49
- * quality, performance, and cost of the automated development process.
50
- *
51
- * Examples include "gpt-4", "gpt-3.5-turbo" for OpenAI, or vendor-specific
52
- * identifiers like "claude-3-sonnet", "deepseek-chat-v3", "llama3.3-70b" when
53
- * using alternative providers through compatible APIs.
54
- */
55
- model: OpenAI.ChatModel | ({} & string);
56
-
57
- /**
58
- * Optional request configuration for API calls.
59
- *
60
- * Additional request options that will be applied to all API calls made
61
- * through the OpenAI SDK. This can include custom headers, timeouts, retry
62
- * policies, or other HTTP client configuration that may be required for
63
- * specific vendor integrations or enterprise environments.
64
- *
65
- * These options provide fine-grained control over the API communication
66
- * behavior and can be used to optimize performance or meet specific
67
- * infrastructure requirements.
68
- */
69
- options?: OpenAI.RequestOptions | undefined;
70
-
71
- /**
72
- * Maximum number of concurrent API requests allowed.
73
- *
74
- * Controls the concurrency level for AI API calls to prevent rate limiting,
75
- * manage resource consumption, and optimize system performance. The vibe
76
- * coding pipeline may make multiple parallel requests during development
77
- * phases, and this setting ensures controlled resource utilization.
78
- *
79
- * A reasonable default provides balanced performance while respecting typical
80
- * API rate limits. Lower values reduce resource consumption but may slow
81
- * development progress, while higher values can improve performance but risk
82
- * hitting rate limits or overwhelming the AI service.
83
- *
84
- * Set to undefined to disable concurrency limiting, allowing unlimited
85
- * parallel requests (use with caution based on your API limits and
86
- * infrastructure capacity).
87
- *
88
- * @default 16
89
- */
90
- semaphore?: number | undefined;
91
-
92
- /**
93
- * Indicates whether this vendor/model supports explicit tool choice control.
94
- *
95
- * When set to `true`, the agent may pass the `tool_choice` parameter with a
96
- * value of `"required"` (or other explicit values) for models that implement
97
- * OpenAI-style tool calling. This allows the agent to force the model to call
98
- * one of the provided tools when appropriate.
99
- *
100
- * When set to `false`, the agent will avoid sending `tool_choice` in a way
101
- * that forces tool invocation, and will instead rely on the model's default
102
- * behavior or omit tool-choice configuration entirely. This should be used
103
- * for vendors or models that do not understand, partially implement, or are
104
- * unstable with the `tool_choice` parameter.
105
- *
106
- * This flag is necessary so that a single agent implementation can work
107
- * across multiple vendors and models with differing levels of tool-calling
108
- * support, without causing API errors or unexpected behavior.
109
- *
110
- * @default true
111
- */
112
- useToolChoice?: boolean;
113
- }
1
+ import OpenAI from "openai";
2
+
3
+ /**
4
+ * Interface representing AI vendor configuration for the AutoBeAgent.
5
+ *
6
+ * Defines the connection parameters and settings required to integrate with AI
7
+ * service providers that power the vibe coding pipeline. While utilizing the
8
+ * OpenAI SDK as the connection interface, this configuration supports various
9
+ * LLM vendors beyond OpenAI through flexible endpoint and authentication
10
+ * configuration, enabling integration with Claude, DeepSeek, Meta Llama, and
11
+ * other providers that follow OpenAI-compatible API patterns.
12
+ *
13
+ * The vendor configuration determines the AI capabilities available throughout
14
+ * the entire automated development workflow, from requirements analysis and
15
+ * database design through API specification, testing, and final implementation.
16
+ * Different vendors may offer varying performance characteristics, cost
17
+ * structures, and feature support that can be optimized for specific vibe
18
+ * coding needs.
19
+ *
20
+ * Concurrent request management is built-in to prevent API rate limiting and
21
+ * optimize resource utilization across multiple development phases and parallel
22
+ * operations within the vibe coding pipeline.
23
+ *
24
+ * @author Samchon
25
+ */
26
+ export interface IAutoBeVendor {
27
+ /**
28
+ * OpenAI SDK instance configured for the target AI vendor.
29
+ *
30
+ * Provides the API connection interface used by the AutoBeAgent to
31
+ * communicate with AI services. While this uses the OpenAI SDK, it can be
32
+ * configured to connect with various LLM providers by setting the appropriate
33
+ * `baseURL` and authentication credentials. The SDK serves as a universal
34
+ * connector that abstracts the underlying API communication protocols.
35
+ *
36
+ * For non-OpenAI vendors, configure the SDK with the vendor's API endpoint
37
+ * and authentication requirements to enable seamless integration with the
38
+ * vibe coding system.
39
+ */
40
+ api: OpenAI;
41
+
42
+ /**
43
+ * Specific model identifier to use for AI operations.
44
+ *
45
+ * Specifies the exact model name or identifier that should be used for vibe
46
+ * coding tasks. Supports both official OpenAI chat models and custom model
47
+ * identifiers for third-party hosting services, cloud providers, or
48
+ * alternative LLM vendors. The model choice significantly impacts the
49
+ * quality, performance, and cost of the automated development process.
50
+ *
51
+ * Examples include "gpt-4", "gpt-3.5-turbo" for OpenAI, or vendor-specific
52
+ * identifiers like "claude-3-sonnet", "deepseek-chat-v3", "llama3.3-70b" when
53
+ * using alternative providers through compatible APIs.
54
+ */
55
+ model: OpenAI.ChatModel | ({} & string);
56
+
57
+ /**
58
+ * Optional human-readable label for this vendor/model configuration.
59
+ *
60
+ * This is a display or grouping name that is distinct from the underlying
61
+ * `model` identifier, and is intended for use in logs, UIs, selection menus,
62
+ * or archive views where a more descriptive name is helpful (for example,
63
+ * "Primary GPT-4", "Fast Drafting Model", or "Internal Llama Cluster").
64
+ *
65
+ * When omitted, callers should fall back to displaying or logging the `model`
66
+ * value itself, or another sensible default derived from the model
67
+ * identifier.
68
+ */
69
+ label?: string | undefined;
70
+
71
+ /**
72
+ * Optional request configuration for API calls.
73
+ *
74
+ * Additional request options that will be applied to all API calls made
75
+ * through the OpenAI SDK. This can include custom headers, timeouts, retry
76
+ * policies, or other HTTP client configuration that may be required for
77
+ * specific vendor integrations or enterprise environments.
78
+ *
79
+ * These options provide fine-grained control over the API communication
80
+ * behavior and can be used to optimize performance or meet specific
81
+ * infrastructure requirements.
82
+ */
83
+ options?: OpenAI.RequestOptions | undefined;
84
+
85
+ /**
86
+ * Maximum number of concurrent API requests allowed.
87
+ *
88
+ * Controls the concurrency level for AI API calls to prevent rate limiting,
89
+ * manage resource consumption, and optimize system performance. The vibe
90
+ * coding pipeline may make multiple parallel requests during development
91
+ * phases, and this setting ensures controlled resource utilization.
92
+ *
93
+ * A reasonable default provides balanced performance while respecting typical
94
+ * API rate limits. Lower values reduce resource consumption but may slow
95
+ * development progress, while higher values can improve performance but risk
96
+ * hitting rate limits or overwhelming the AI service.
97
+ *
98
+ * Set to undefined to disable concurrency limiting, allowing unlimited
99
+ * parallel requests (use with caution based on your API limits and
100
+ * infrastructure capacity).
101
+ *
102
+ * @default 16
103
+ */
104
+ semaphore?: number | undefined;
105
+
106
+ /**
107
+ * Indicates whether this vendor/model supports explicit tool choice control.
108
+ *
109
+ * When set to `true`, the agent may pass the `tool_choice` parameter with a
110
+ * value of `"required"` (or other explicit values) for models that implement
111
+ * OpenAI-style tool calling. This allows the agent to force the model to call
112
+ * one of the provided tools when appropriate.
113
+ *
114
+ * When set to `false`, the agent will avoid sending `tool_choice` in a way
115
+ * that forces tool invocation, and will instead rely on the model's default
116
+ * behavior or omit tool-choice configuration entirely. This should be used
117
+ * for vendors or models that do not understand, partially implement, or are
118
+ * unstable with the `tool_choice` parameter.
119
+ *
120
+ * This flag is necessary so that a single agent implementation can work
121
+ * across multiple vendors and models with differing levels of tool-calling
122
+ * support, without causing API errors or unexpected behavior.
123
+ *
124
+ * @default true
125
+ */
126
+ useToolChoice?: boolean;
127
+ }