Module contains utility functions for working with messages.
Some examples of what you can do with these functions include:
A type representing any defined Message or MessageChunk type.
Create a message with a link to the LangChain troubleshooting guide.
Format standard data content block to format expected by OpenAI.
"Standard data content block" can include old-style LangChain v0 blocks (URLContentBlock, Base64ContentBlock, IDContentBlock) or new ones.
Check if the provided content block is a data content block.
Returns True for both v0 (old-style) and v1 (new-style) multimodal data blocks.
Convert a tool-like object to an OpenAI tool schema.
Convert a sequence of messages to strings and concatenate them into one string.
Convert a sequence of messages from dicts to Message objects.
Convert a message chunk to a Message.
Convert a sequence of messages to a list of messages.
Filter messages based on name, type or id.
Merge consecutive Messages of the same type.
ToolMessage objects are not merged, as each has a distinct tool call id that
can't be merged.
Trim messages to be below a token count.
trim_messages can be used to reduce the size of a chat history to a specified
token or message count.
In either case, if passing the trimmed chat history back into a chat model directly, the resulting chat history should usually satisfy the following properties:
HumanMessage or (2) a SystemMessage
followed by a HumanMessage. To achieve this, set start_on='human'.
In addition, generally a ToolMessage can only appear after an AIMessage
that involved a tool call.strategy='last'.SystemMessage if it
was present in the original chat history since the SystemMessage includes
special instructions to the chat model. The SystemMessage is almost always
the first message in the history if present. To achieve this set the
include_system=True.The examples below show how to configure trim_messages to achieve a behavior
consistent with the above properties.
Convert LangChain messages into OpenAI message dicts.
Approximate the total number of tokens in messages.
The token count includes stringified message content, role, and (optionally) name.
Error codes.
Message from an AI.
An AIMessage is returned from a chat model as a response to a prompt.
This message represents the output of the model and consists of both the raw output as returned by the model and standardized fields (e.g., tool calls, usage metadata) added by the LangChain framework.
Message chunk from an AI (yielded when streaming).
Base abstract message class.
Messages are the inputs and outputs of a chat model.
Examples include HumanMessage,
AIMessage, and
SystemMessage.
Message chunk, which can be concatenated with other Message chunks.
Message that can be assigned an arbitrary speaker (i.e. role).
Chat Message chunk.
Message for passing the result of executing a tool back to a model.
FunctionMessage are an older version of the ToolMessage schema, and
do not contain the tool_call_id field.
The tool_call_id field is used to associate the tool call request with the
tool call response. Useful in situations where a chat model is able
to request multiple tool calls in parallel.
Function Message chunk.
Message from the user.
A HumanMessage is a message that is passed in from a user to the model.
Human Message chunk.
Message responsible for deleting other messages.
Message for priming AI behavior.
The system message is usually passed in as the first of a sequence of input messages.
System Message chunk.
Represents an AI's request to call a tool.
Message for passing the result of executing a tool back to a model.
ToolMessage objects contain the result of a tool invocation. Typically, the result
is encoded inside the content field.
tool_call_id is used to associate the tool call request with the tool call
response. Useful in situations where a chat model is able to request multiple tool
calls in parallel.
Tool Message chunk.
Abstract base class for interfacing with language models.
All language model wrappers inherited from BaseLanguageModel.
Base abstract class for inputs to any language model.
PromptValues can be converted to both LLM (pure text-generation) inputs and
chat model inputs.
Base class for all LangChain tools.
This abstract class defines the interface that all LangChain tools must implement.
Tools are components that can be called by agents to perform specific actions.
A type representing the various ways a message can be represented.
A unit of work that can be invoked, batched, streamed, transformed and composed.
invoke/ainvoke: Transforms a single input into an output.batch/abatch: Efficiently transforms multiple inputs into outputs.stream/astream: Streams output from a single input as it's produced.astream_log: Streams output and selected intermediate results from an
input.Built-in optimizations:
Batch: By default, batch runs invoke() in parallel using a thread pool executor. Override to optimize batching.
Async: Methods with 'a' prefix are asynchronous. By default, they execute
the sync counterpart using asyncio's thread pool.
Override for native async.
All methods accept an optional config argument, which can be used to configure execution, add tags and metadata for tracing and debugging etc.
Runnables expose schematic information about their input, output and config via
the input_schema property, the output_schema property and config_schema
method.
Runnable objects can be composed together to create chains in a declarative way.
Any chain constructed this way will automatically have sync, async, batch, and streaming support.
The main composition primitives are RunnableSequence and RunnableParallel.
RunnableSequence invokes a series of runnables sequentially, with
one Runnable's output serving as the next's input. Construct using
the | operator or by passing a list of runnables to RunnableSequence.
RunnableParallel invokes runnables concurrently, providing the same input
to each. Construct it using a dict literal within a sequence or by passing a
dict to RunnableParallel.
For example,
from langchain_core.runnables import RunnableLambda
# A RunnableSequence constructed using the `|` operator
sequence = RunnableLambda(lambda x: x + 1) | RunnableLambda(lambda x: x * 2)
sequence.invoke(1) # 4
sequence.batch([1, 2, 3]) # [4, 6, 8]
# A sequence that contains a RunnableParallel constructed using a dict literal
sequence = RunnableLambda(lambda x: x + 1) | {
"mul_2": RunnableLambda(lambda x: x * 2),
"mul_5": RunnableLambda(lambda x: x * 5),
}
sequence.invoke(1) # {'mul_2': 4, 'mul_5': 10}All Runnables expose additional methods that can be used to modify their
behavior (e.g., add a retry policy, add lifecycle listeners, make them
configurable, etc.).
These methods will work on any Runnable, including Runnable chains
constructed by composing other Runnables.
See the individual methods for details.
For example,
from langchain_core.runnables import RunnableLambda
import random
def add_one(x: int) -> int:
return x + 1
def buggy_double(y: int) -> int:
"""Buggy code that will fail 70% of the time"""
if random.random() > 0.3:
print('This code failed, and will probably be retried!') # noqa: T201
raise ValueError('Triggered buggy code')
return y * 2
sequence = (
RunnableLambda(add_one) |
RunnableLambda(buggy_double).with_retry( # Retry on failure
stop_after_attempt=10,
wait_exponential_jitter=False
)
)
print(sequence.input_schema.model_json_schema()) # Show inferred input schema
print(sequence.output_schema.model_json_schema()) # Show inferred output schema
print(sequence.invoke(2)) # invoke the sequence (note the retry above!!)As the chains get longer, it can be useful to be able to see intermediate results to debug and trace the chain.
You can set the global debug flag to True to enable debug output for all chains:
from langchain_core.globals import set_debug
set_debug(True)Alternatively, you can pass existing or custom callbacks to any given chain:
from langchain_core.tracers import ConsoleCallbackHandler
chain.invoke(..., config={"callbacks": [ConsoleCallbackHandler()]})For a UI (and much more) checkout LangSmith.