I am not completely clear on what sort of communication you are trying to protect, and what your threat model is.
Let's say that agent-in-place X posts to his controller whenever something of political significance happens in Foobarvia. A clever traffic analyst will notice that a certain key posts to alt.anonymous (or contributes to the pool, whatever it is) whenever something big happens in Foobarvia. Conclusions can be drawn -- there is a PGP-using spy in Foobarvia! By carefully limiting access to news tidbits, they can use process of elimination to find the spy. (In reality, it could be much more mundane -- every time Peggy Sue tells Mary Beth a secret, there is a post by the same keyid, etc.) However, if you use a public-key encryption scheme that doesn't store the key-id on the outside of the packet (or store it at all), then you are at liberty to identify the packets for decryption by the target recipient however you want. I've suggested an approach using tokens, which make all the messages from agent-in-place X unlinkable to one another (thus hindering the detection of the aforementioned pattern), while still allowing the recipient to sniff for them efficiently.
Are you worried about an attacker noticing that an anonymous ID is getting a lot of messages? If you are using PGP and a message pool, any attacker can decrypt all the messages, and see which correspond to which key, and therefor to which anonymous ID. The only way around this is to use private key crypto. If you are doing that, then you can also use a shared secret to generate a stream of one use message IDs.
Clearly this involves using something other than vanilla PGP, or running some post- and pre- processing to delete and then add back in the key-id. The mandatory external presence of the key-id has always been less than optimal, IMHO.