add PythonCodeStructuredTool

[YamonBot]

This draft involves receiving Langchains structed tool 'Code' types as inputs and creating a structured tool.

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
langflow	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 26, 2024 5:31am

[YamonBot]

https://github.com/langflow-ai/langflow/issues/1719

[YamonBot]

Although it's different from the initial setup, the method implemented now seems likely to become compatible with tools written in Langchain, so I have only made improvements to the definition method of StructuredTool.

[YamonBot]

Code exam

class CalculatorInput(BaseModel):
    a: int = Field(description="first number")
    b: int = Field(description="second number")

def multiply(a: int, b: int) -> int:
    """Multiply two numbers."""
    return a * b

calculator = StructuredTool.from_function(
    func=multiply,
    name="Calculator",
    description="multiply numbers",
    args_schema=CalculatorInput,
    return_direct=True,
    # coroutine= ... <- you can specify an async method if desired as well
)

[YamonBot]

This component uses the Code field and employs exec, so providing Code through Tweaks at the API endpoint could lead to dangerous behaviors. Consequently, the Langflow code must be modified to prevent input via Tweaks for fields of the Code type.

[ogabrielluiz]

So, do you think we should or shouldn't allow code to be passed through tweaks?

[YamonBot]

그렇다면 코드가 수정을 통해 전달되도록 허용해야 한다고 생각하시나요, 아니면 허용해서는 안 된다고 생각하시나요?

I believe Langflow has created a very revolutionary type called "Code," so it should not be allowed by default in API calls (to prevent it from being exposed and potentially stolen). However, it might be beneficial to decide on the permissibility of this feature in the future detailed editing of Flow, including remote builds. When I wrote this, I may have lacked a complete understanding of Langflow, as it seems that the Flow, after the build process, is already exposed, rendering my suggestion possibly unnecessary.

[YamonBot]

In a similar case, the AutoGPT project uses an env file to manage the following settings:

## RESTRICT_TO_WORKSPACE - Restrict file operations to the workspace in the directory ./data/agents/<agent_id>/workspace (Default: True)
# RESTRICT_TO_WORKSPACE=True

## DISABLED_COMMANDS - The comma-separated list of commands that are disabled (Default: None)
# DISABLED_COMMANDS=

This setup restricts agents to operate only within a specific directory when managing files.

################################################################################
### SHELL EXECUTION
################################################################################

## SHELL_COMMAND_CONTROL - Whether to use an "allowlist" or "denylist" to determine what shell commands can be executed (Default: denylist)
# SHELL_COMMAND_CONTROL=denylist

## ONLY if SHELL_COMMAND_CONTROL is set to denylist:
## SHELL_DENYLIST - List of shell commands that ARE NOT allowed to be executed by AutoGPT (Default: sudo, su)
# SHELL_DENYLIST=sudo,su

## ONLY if SHELL_COMMAND_CONTROL is set to allowlist:
## SHELL_ALLOWLIST - List of shell commands that ARE allowed to be executed by AutoGPT (Default: None)
# SHELL_ALLOWLIST=

These settings also allow for the restriction of executable shell commands by agents.

It seems like a good idea to refer to this design for improvements.

Similarly, it seems like a good idea to define constraints for the Code field using utils.