Port pydantic_ai.Agent to using pydantic_graph

[dmontagu]

This is an attempt to move the pydantic_ai.Agent implementation to be based on pydantic_graph, so we can get all the various graph utility features "for free".

While I think we might want to change some of the behaviors, I have attempted to port the existing implementation to use pydantic_graph with the minimal set of external-facing changes possible.

[cloudflare-workers-and-pages]

Deploying pydantic-ai with    Cloudflare Pages

Latest commit:	2e37316
Status:	✅  Deploy successful!
Preview URL:	https://b595f6c9.pydantic-ai.pages.dev
Branch Preview URL:	https://dmontagu-graph-agent.pydantic-ai.pages.dev

View logs

[Finndersen]

Nice one, do the normal and stream variants of each node need to be seperate classes? Could a stream: bool attribute used to decide behaviour work? (Could factor out this behaviour into a StreamableNode or something)

[dmontagu]

Not in principle, but in practice we’re using different vendor APIs for streaming and non-streaming so it doesn’t get as much benefit from unifying the types as you might think. I’m planning to implement a stream_events API using the graph nodes next, which will better demonstrate how to have streaming with an iterator coexist with the usual run in a graph context.

[Finndersen]

Also, it would be nice if nodes could define & return abstractions/signatures of other nodes instead of concrete implementations/instances. Because currently this limits their flexibility and re-usability as building blocks.

Like for example each "node type" could have a signature (effectively an abstract base class kind of thing), and this is referenced by other nodes, but the actual implementations could be defined/overridden at runtime. So people could plug in their own implementations of these different nodes within the "agent" to customise it's behaviour as required

[Finndersen]

@dmontagu ok, I'm just on my phone so haven't looked in detail, but seems like there's still a bit of overlap in functionality, and to me I think it makes more sense to have a single node with a stream switch, since conceptually it is/does the same thing, just with a different approach.

I would've thought that streaming would require a different method API/signature?

[dmontagu]

It sounds to me like you want a way to override a node’s behavior; why can’t you just do that by subclassing the node and overriding the run method? If you intend for the node to be extensible in some way, you can include the ways you want it to be extended as methods called inside the run method, and subclasses can override just those methods.

[Finndersen]

But then the subclassed node won't be used in place of the original parent node by other nodes that already reference it.
Currently once a graph is made from a collection of nodes (like this agent implementation), it's effectively immutable and you can't extend/customise it by swapping out/overriding individual nodes in the graph.

This is because each node implementation contains both the node logic as well as the edge / next node configuration coupled together.
Sorry, this discussion isn't really relevant to this PR